Textpattern CMS support forum

You are not logged in. Register | Login | Help

#21 2018-03-17 13:34:51

etc
Developer
Registered: 2010-11-11
Posts: 3,069
Website

Re: Making your plugins 4.7-aware

Uli, are you sure you have the latest greatest dev? We had this error in the first beta, but it should be patched now.


etc_[ query | search | pagination | date | tree | cache ]

Offline

#22 2018-03-17 14:22:28

uli
Moderator
From: Cologne
Registered: 2006-08-15
Posts: 4,169

Re: Making your plugins 4.7-aware

etc wrote #310076:

Uli, are you sure you have the latest greatest dev? We had this error in the first beta, but it should be patched now.

I just downloaded and installed the beta yesterday. Now with the latest nightly the errors are gone. Thanks!


In bad weather I never leave home without wet_plugout, smd_where_used and adi_form_links

Offline

#23 2018-07-13 07:48:17

NicolasGraph
Plugin Author
From: France
Registered: 2008-07-24
Posts: 860
Website

Re: Making your plugins 4.7-aware

Hi, I’m wondering if there is a kind a good practice or convention for naming plugin related global attributes? I know the txp- prefix is reserved but how should we avoid clashes between two plugins with same global attribute names?
Thanks.

Last edited by NicolasGraph (2018-07-13 07:51:43)


Nicolas
Follow me on Twitter and GitHub!
Multiple edits are usually to correct my frenglish…

Offline

#24 2018-07-13 08:28:05

etc
Developer
Registered: 2010-11-11
Posts: 3,069
Website

Re: Making your plugins 4.7-aware

NicolasGraph wrote #313010:

Hi, I’m wondering if there is a kind a good practice or convention for naming plugin related global attributes? I know the txp- prefix is reserved but how should we avoid clashes between two plugins with same global attribute names?

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.


etc_[ query | search | pagination | date | tree | cache ]

Offline

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

NicolasGraph
Plugin Author
From: France
Registered: 2008-07-24
Posts: 860
Website

Re: Making your plugins 4.7-aware

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)


Nicolas
Follow me on Twitter and GitHub!
Multiple edits are usually to correct my frenglish…

Offline

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

NicolasGraph
Plugin Author
From: France
Registered: 2008-07-24
Posts: 860
Website

Re: Making your plugins 4.7-aware

…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)


Nicolas
Follow me on Twitter and GitHub!
Multiple edits are usually to correct my frenglish…

Offline

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

etc
Developer
Registered: 2010-11-11
Posts: 3,069
Website

Re: Making your plugins 4.7-aware

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:

  1. body() function is called and parses the articles body;
  2. the result is passed as $thing to if_test() along with if_test attribute itself;
  3. 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.


etc_[ query | search | pagination | date | tree | cache ]

Offline

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

NicolasGraph
Plugin Author
From: France
Registered: 2008-07-24
Posts: 860
Website

Re: Making your plugins 4.7-aware

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)


Nicolas
Follow me on Twitter and GitHub!
Multiple edits are usually to correct my frenglish…

Offline

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

NicolasGraph
Plugin Author
From: France
Registered: 2008-07-24
Posts: 860
Website

Re: Making your plugins 4.7-aware

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)


Nicolas
Follow me on Twitter and GitHub!
Multiple edits are usually to correct my frenglish…

Offline

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

michaelkpate
Moderator
From: Avon Park, FL
Registered: 2004-02-24
Posts: 1,131
Website

Re: Making your plugins 4.7-aware

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.

Offline

Board footer

Powered by FluxBB