Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 2011-11-25 17:37:16

MarcoK
Plugin Author
From: Como
Registered: 2006-10-17
Posts: 248
Website

Plugin Callback and Order problem

Hi at all.

I’m doing a Plugin that work with pluggable_ui and categories step().
I have a trouble because i have installed also a smd_write_cat that put a input file after category select.

return $dflt.$catbox;

Where $dflt is the default content.

Now my plugin print only a sting instead of content,

function mck_change_cat($event, $step, $data, $rec){
 return 'I have change categories!';
}
but under this string however appears the categories selects called by smd_write_cat. If i disable this plugin the result is as I want. I have tried to order my plugin as 4 so i think my code was processed before smd_write_cat (order 5) but nothing is changed.

Is normally or there is something wrong

How can I keep the categories change affected even after the smd plugin?

Offline

#2 2011-11-25 20:08:30

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: Plugin Callback and Order problem

MarcoK wrote:

I have tried to order my plugin as 4 so i think my code was processed before smd_write_cat (order 5) but nothing is changed.

Very odd. I would expect the callbacks to fire in plugin load order. My plugin only appends to whatever is there already, so if yours has altered the category selects then mine should just add to whatever is returned from your plugin.

Must admit I’ve never tried chaining plugins this way. Perhaps it’s a bug, unless someone else can fathom out a reason why it would behave this way.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#3 2011-11-25 21:00:06

Gocom
Developer Emeritus
From: Helsinki, Finland
Registered: 2006-07-14
Posts: 4,533
Website

Re: Plugin Callback and Order problem

Bloke wrote:

Very odd. I would expect the callbacks to fire in plugin load order. My plugin only appends to whatever is there already, so if yours has altered the category selects then mine should just add to whatever is returned from your plugin.

That seems what is designed to happen. Hooks can only replace the default content, not content added by other hooked functions. Content returned by hooks is always added to the existing content added by other hooks, and modifications are not passed from a hook to other.

If I understood MarcoK correctly, he wants the opposite. As I read it, he to want to modify the default content, and pass the modified default content to other hooked functions (i.e. smd_write_cat). Which unfortunately is not supported.

The default content the plugins get from the callback is what was originally there. As smd_write_cat returns the default content in addition of added functionality, the changes MarcoK have no effect. The fields he removed will just come back.

Last edited by Gocom (2011-11-25 21:07:46)

Offline

#4 2011-11-26 09:05:58

MarcoK
Plugin Author
From: Como
Registered: 2006-10-17
Posts: 248
Website

Re: Plugin Callback and Order problem

Bloke wrote:

… My plugin only appends to whatever is there already, so if yours has altered the category selects then mine should just add to whatever is returned from your plugin.

This is what I thought would happen.

Hum… ok, so… Dev can use this ‘bug’ and resolv it on TXP 5 no? Is an Idea…

My only solution is insert a jquery script that modify category’s select

Offline

#5 2011-11-26 20:39:19

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: Plugin Callback and Order problem

Gocom wrote:

Hooks can only replace the default content, not content added by other hooked functions

Shame. We should probably look into ways to chain things in future then. Granted it opens up some glaring problems if Plugin 1 removes some content that Plugin 2 relies upon, but if we handle it carefully it might be possible. Maybe some configuration option or a per-plugin switch that admins can use.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#6 2015-07-20 12:58:46

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

Re: Plugin Callback and Order problem

I’ve done a pull request proposed here.

Bloke wrote #255048:

Granted it opens up some glaring problems if Plugin 1 removes some content that Plugin 2 relies upon

would like to see meaningful examples here, does anyone installs Plugin 1 to remove some element, and then Plugin 2 to bring it back?

Offline

#7 2015-07-20 18:37:58

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: Plugin Callback and Order problem

etc wrote #293541:

does anyone installs Plugin 1 to remove some element, and then Plugin 2 to bring it back?

Unlikely. I meant if Plugin 1 hooked into, say, the sort-and-display’s Section callback and replaced the dropdown with nothing (because they relocated it elsewhere) then Plugin 2 tried to change the section Names to Titles in the dropdown. Plugin 2 would fail unless the order of execution was altered.

But it’s probably no worse than now: the example above under today’s callback chain would result in two Section dropdowns, which would break any other plugins, such as per-Section category selectors that had JS which relied on the DOM id.

Neither system is perfect but I prefer your chaining Pull Request (haven’t tried it yet, but I like the idea). The only way to get the best of both worlds would be if we could implement your patch and additionally offer some way to permit an override for site designers to alter the manner in which Plugin A and Plugin B can chain if they clash. Probably quite tricky to achieve!


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#8 2015-07-20 22:11:18

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

Re: Plugin Callback and Order problem

Bloke wrote #293553:

Plugin 2 would fail unless the order of execution was altered.

Nothing stops the admin from doing so, isn’t that what this order is for?

The only way to get the best of both worlds would be if we could implement your patch and additionally offer some way to permit an override for site designers to alter the manner in which Plugin A and Plugin B can chain if they clash. Probably quite tricky to achieve!

We could imagine something for new plugins, but ensuring the bw compatibility looks tricky, indeed.

Offline

#9 2015-07-20 22:27:33

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: Plugin Callback and Order problem

etc wrote #293563:

Nothing stops the admin from doing so, isn’t that what this order is for?

Absolutely! As long as the admin is able to figure out why the two don’t work together in the first place.

Whichever system is in use — the proposed improvement or the original — has advantages and drawbacks and potential end user confusion when things clash.

So, on that note, is there some convention we can adopt so that plugins have a better chance of playing better together? Something we can implement and/or document/advise as part of this patch that helps people find out what’s going on and diagnose it easily? Maybe some good practices (e.g. don’t rename DOM elements!) that will help plugins co-operate better?

This might be something that makss’ trace enhancements can help with (haven’t got round to trying it out yet, sadly, but I will). If that showed that two or more plugins are hooked into the same callback and shows which order they’re in, it might lend itself to a rapid resolution.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#10 2015-07-21 10:34:11

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

Re: Plugin Callback and Order problem

Bloke wrote #293565:

Whichever system is in use — the proposed improvement or the original — has advantages and drawbacks and potential end user confusion when things clash.

Yes, but the proposed one solves few “real life” problems (OP, my own experience). Sure, it creates potential clashes, but they seem purely hypothetical atm. Now, if someone finds an example of two plugins that would clash, I’ll adapt or remove the pull request, no problem.

So, on that note, is there some convention we can adopt so that plugins have a better chance of playing better together? Something we can implement and/or document/advise as part of this patch that helps people find out what’s going on and diagnose it easily? Maybe some good practices (e.g. don’t rename DOM elements!) that will help plugins co-operate better?

I think, if the rules are clear, it’s up to plugin authors to play well and document possible issues. But again, what issues?

Offline

Board footer

Powered by FluxBB