Plugin Callback and Order problem

MarcoK · 2011-11-25 17:37:16

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?

Bloke · 2011-11-25 20:08:30

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.

Gocom · 2011-11-25 21:00:06

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)

MarcoK · 2011-11-26 09:05:58

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

Bloke · 2011-11-26 20:39:19

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.

etc · 2015-07-20 12:58:46

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?

Bloke · 2015-07-20 18:37:58

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!

etc · 2015-07-20 22:11:18

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.

Bloke · 2015-07-20 22:27:33

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.

etc · 2015-07-21 10:34:11

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?

Textpattern CMS

Textpattern CMS support forum

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