Callback for saving own new fields

Bloke · Today 07:33:35

Ah yes, that’s true about the pre/post in this case. Sorry, I didn’t take account of the actual callback name article_submit, d’oh.

The ampersand treats the passed value by reference. So, rather than making a local copy of the variable and working on that, which gets destroyed when the function exits (barring any return), it operates on the external variable directly.

Unless a callback explicitly assigns whatever you return to its own (or another) variable, returning something from a callback function will do nothing. In those cases, an ampersand usually works better.

So, you can usually return something from these callbacks:

$some_variable = callback_event($evt, $stp, $data);

But you would use an ampersand on your received variable in your function signature if the callback was one of these:

callback_event($evt, $stp, $data);
callback_event_ref($evt, $stp, $data);

Annoyingly there’s no way to know which is which, without looking at the code, so one of the things I’d like to do is adopt a solid naming convention to make it obvious from the callback event/step/pre which type it is.

Generally though, if it’s a callback_event_ref then you need to use an ampersand. As you found, your variable name doesn’t need to match the external one: that’s your reference copy, like a pointer to the external variable you’re manipulating.

Hope that helps.

jakob · Today 08:45:43

Bloke wrote #342899:

Hope that helps.

Thanks, it does, and explains why nothing was happening. Feel (a bit) wiser today for it :-)

I’ll try and remember this post for future attempts, but the callback_event_ref is at least a hint.

Unless a callback explicitly assigns whatever you return to its own (or another) variable, returning something from a callback function will do nothing. In those cases, an ampersand usually works better.

BTW: Does that mean I don’t need the return statement at the end of the plugin code either?

——

What I quite like about this method is it sidesteps the retrieve-from-db › modify › replace in db stuff I’ve done up to now, and my run-ins with not borking async saving. My typical use cases up to now have been:

Give site users a couple more textile-like options for things like spacers, (fancier) horizontal rules, sections, etc. to stop them doing self-made workarounds with transparent full stops etc. that then show up in rss readers etc.
Add a div wrapper around tables (or other wide content) for horizontal scrolling on mobile view (rather than doing that later with js)

Another future use case is…

Twice in recent projects I’ve needed to restructure the output of the body tag after the event, e.g. to insert wrapper divs or sections around blocks that need to belong together or be kept apart without requiring the authors to insert any special formatting in the body field.

For those cases I have some home-made plugins that use DomDocument to split and recombine the DOM nodes with wrappers in the required constellation (I’ve not yet identified a good abstractable pattern to make it into a more general plugin). Currently those are custom tags wrapped around <txp:body /> which I guess could get inefficient with heavier use. Making that run on the new article_submit callback after textile processing would reduce server load by presaving the reformatted output on post/save.

Bloke · Today 09:29:33

jakob wrote #342900:

Does that mean I don’t need the return statement at the end of the plugin code either?

Correct.

Textpattern CMS

Textpattern CMS support forum

#16 Today 07:33:35

Re: Callback for saving own new fields

#17 Today 08:45:43

Re: Callback for saving own new fields

Bloke wrote #342899:

#18 Today 09:29:33

Re: Callback for saving own new fields

jakob wrote #342900:

Board footer