Making your plugins 4.7-aware

NicolasGraph · 2018-07-13 08:40:20

etc wrote #313011:

I guess the same convention applies that for the tags: you should prefix them, but you don’t have to. The parser does not care, fwiw.

Thanks Oleg, that what I thought… but in fact what I’m trying to figure is how to avoid clashes in my own plugin tags.

Anyway, In my case I guess I can, for example add a cookie global dedicated attribute to txp:oui_cookie to replace of the name attribute like so <article::id cookie="id" />.

Wouldn’t it be useful to add a variable global dedicated attribute to txp:variable in the same way?

Last edited by NicolasGraph (2018-07-13 08:41:50)

NicolasGraph · 2018-07-13 09:49:46

…also, did you think about a case where a bloody plugin dev like me would try to register something like if_cookie as a global attribute? The following code would display a video player if the cookie named cookies-consent is set: <oui::vimeo play="279236253" if_cookie="cookies-consent" />.

It seems to work if the condition is true but, while nothing is displayed when the condition is false, I get this error:

Tag error: <oui::vimeo play="279236253" if_cookie="cookies-consent" /> ->  Warning: Invalid argument supplied for foreach() while parsing form default on page archive

textpattern/lib/txplib_publish.php:471 processTags()
textpattern/publish/taghandlers.php:2812 parse()
body()
textpattern/vendors/Textpattern/Tag/Registry.php:116 call_user_func()
textpattern/lib/txplib_publish.php:547 Textpattern\Tag\Registry->process()
textpattern/lib/txplib_publish.php:471 processTags()
textpattern/lib/txplib_misc.php:4364 parse()
textpattern/publish.php:938 parse_form()
textpattern/publish.php:971 doArticle()
textpattern/publish.php:732 parseArticles()

Last edited by NicolasGraph (2018-07-13 11:26:29)

etc · 2018-07-14 08:52:21

Salut Nicolas,

I’m not sure about how you want to achieve it. I’ve tried the following “plugin”

Txp::get('\Textpattern\Tag\Registry')->registerAttr('if_test');

function if_test($atts, $thing = null) {
    return gps('test') ? $thing : 'nothing';
}

and it seems to work fine. An important thing to know is that the global attributes are currently {post}-processed. When you call something like

<txp:body if_test />

the workflow is the following:

body() function is called and parses the articles body;
the result is passed as $thing to if_test() along with if_test attribute itself;
if_test() decides what to do with it and outputs the result.

My internet connection is very poor atm, I can not download and test oui_player, sorry.

NicolasGraph · 2018-07-14 11:38:44

Merci Oleg,
No worry about your connection, I will take a fresh look on my issue on Monday and I will come back with my own minimal test case if I can’t fix because it is not part of an official release of my plug-in yet.

Bon weekend.

Last edited by NicolasGraph (2018-07-14 11:39:32)

NicolasGraph · 2018-07-16 11:33:26

Hi, thanks to your example Oleg, I understood what was wrong with my own test.
Here is the kind of thing I tried:

<oui::if_gps name="test">
    <txp:body />
</oui::if_gps>

or…

<txp:body if_gps="test" />

with this plugin code:

Txp::get('\Textpattern\Tag\Registry')->registerAttr('oui_if_gps', 'if_gps');

function oui_if_gps($atts, $thing = null) {
    extract(lAtts(array(
        'name'   => '',
        'if_gps' => '',
    ), $atts));

    $name or $name = $if_gps;
    $out = gps($name) ? true : false;

    return parse($thing, $out);
}

This tag could be called by its own, with maybe more attributes/options but the if_gps attribute here is a global alias for name. It allows to peform simplest tests without the need to add the oui_if_gps tag.

Because the tag could be used by its own as a container, I uses return parse($thing, $out);, however, its triggers an error when $out is false.
Doing return $out ? $thing : ''; does work but it would not parse potential else contents.

In my case I could check if the tag was used through the global attribute to conditionate the return, but it could be a problem if the global attribute wouldn’t have its own name I guess.
I don’t know if the parser should manage this kind of use or not, or if, has I aked before, there should be a convention about global attributes to name them differently than others; in which case checking the use of a global attribute could seem alright.

Edit: I can’t remember how I should highlight the code in the forum; is it sticked anywhere ? bc(prism language-php).. does not work.

Last edited by NicolasGraph (2018-07-16 15:23:04)

michaelkpate · 2018-07-16 13:40:54

NicolasGraph wrote #313030:

Edit: I can’t remember how I should highlight the code in the forum; is it sticked anywhere ? bc(prism language-php).. does not work.

You want to use “bc..” followed by the language the code is in: html, php, etc.

NicolasGraph · 2018-07-16 15:19:09

michaelkpate wrote #313034:

You want to use “bc..” followed by the language the code is in: html, php, etc.

The more obvious it is, the less I remember… Thanks Michael !

etc · 2018-07-16 16:34:48

NicolasGraph wrote #313030:

Because the tag could be used by its own as a container, I uses return parse($thing, $out), however, its triggers an error when $out is false.

Thanks, this error is weird, will investigate.

Doing return $out ? $thing : ''; does work but it would not parse potential else contents.

You can not make global attributes work this way atm, because the $thing they get is generally already parsed (by the tag) and does not contain <txp:else /> anymore. We could (will?) introduce {pre}parsing global attributes, but, in this case, there would be an ambiguity re the false part in, say

<txp:if_something if_something_else>...<txp:else />...</txp:if_something>

In my case I could check if the tag was used through the global attribute to conditionate the return, but it could be a problem if the global attribute wouldn’t have its own name I guess.
I don’t know if the parser should manage this kind of use or not, or if, has I aked before, there should be a convention about global attributes to name them differently than others; in which case checking the use of a global attribute could seem alright.

When the parser processes global attributes, $pretext['_txp_atts'] is set to true. You can check it, though this may change one day.

NicolasGraph · 2018-07-17 06:56:12

etc wrote #313037:

Thanks, this error is weird, will investigate.

Ok, thanks.

You can not make global attributes work this way atm, because the $thing they get is generally already parsed (by the tag) and does not contain <txp:else /> anymore. We could (will?) introduce _pre_parsing global attributes, but, in this case, there would be an ambiguity re the false part in, say

Yes, I understand, I was just saying that return $out ? $thing : ''; would obviously not work if used through the tag with a potential else clause. I don’t try to use any else clause through the global attribute.

When the parser processes global attributes, $pretext['_txp_atts'] is set to true. You can check it, though this may change one day.

Noted.

Textpattern CMS

Textpattern CMS support forum

#25 2018-07-13 08:40:20

Re: Making your plugins 4.7-aware

etc wrote #313011:

#26 2018-07-13 09:49:46

Re: Making your plugins 4.7-aware

#27 2018-07-14 08:52:21

Re: Making your plugins 4.7-aware

#28 2018-07-14 11:38:44

Re: Making your plugins 4.7-aware

#29 2018-07-16 11:33:26

Re: Making your plugins 4.7-aware

#30 2018-07-16 13:40:54

Re: Making your plugins 4.7-aware

NicolasGraph wrote #313030:

#31 2018-07-16 15:19:09

Re: Making your plugins 4.7-aware

michaelkpate wrote #313034:

#32 2018-07-16 16:34:48

Re: Making your plugins 4.7-aware

NicolasGraph wrote #313030:

#33 2018-07-17 06:56:12

Re: Making your plugins 4.7-aware

etc wrote #313037:

Board footer