pluggable_ui and positioning of an extra field?

jakob · 2016-03-09 17:47:08

I’m experimenting with a self-written plugin adding an extra custom field to the links panel. I’m using this:

register_callback(array($this, 'ui'), 'link_ui', 'extend_detail_form');

to successfully add the extra field to the link edit panel. The new field appears right at the end. Can I also influence at what position it appears, e.g. make it appear before the description textarea? and if so, how?

Related question:
I borrowed heavily from wet_profile but couldn’t get the function lifestyle install routine analog to wet’s function to work correctly, even with Jukka’s pointer in the issues. Is that no longer the correct way to do things?

I was successful by splitting it into two routines:

register_callback(array($this, 'install'), 'plugin_lifecycle.jcr_link_custom', 'installed');
register_callback(array($this, 'uninstall'), 'plugin_lifecycle.jcr_link_custom', 'deleted');

with corresponding separate functions for install() and uninstall(). If I do that, is the “installed” and “deleted” third parameter still necessary in the register_callback function?

Bloke · 2016-03-09 21:58:48

jakob wrote #298198:

Can I also influence at what position it appears, e.g. make it appear before the description textarea? and if so, how?

Short answer: no. The output you return pops up in the place on the page where the callback fires.

Longer answer: yes, but you have to return some jQuery to reposition it.

Note that in some callbacks (e.g. those on the Write panel), the ‘default’ 3rd parameter passed to your callback function contains a copy of the markup that is going to be placed on the page unless you return something, so in those cases you can also do regex search/replace to alter the output of the default markup and return your own. But, again, you’re stuck with positioning it in the place where pluggable_ui() fires unless you use some client-side code to shift it. In the case of the extend_detail callbacks, no such 3rd parameter exists because there is no default content: it’s a place for you to add your own.

Alternatively, hook into the main page callback — the main event / step shown in the URL bar — and try to tinker with the output that way before the buffer is flushed to the screen (e.g. through search/replace of the buffer). MLP does this, and it’s prone to considerable breakage under new Txp versions, but you might be lucky.

couldn’t get the function lifestyle… to work correctly

Odd, it should work as long as your plugin has set the necessary flags in the plugin template to tell the system that it should listen for lifecycle events. But I don’t know why Robert has a third parameter to his lifecycle plugin. There are only two official parameters passed in: $event (plugin_lifecycle.jcr_link_custom) and $step (installed). It is usually sufficient to switch() on the second $step parameter to determine which event fired. I must be missing something.

I was successful by splitting it into two routines… If I do that, is the “installed” and “deleted” third parameter still necessary in the register_callback function?

Yes. They direct the callback to the correct routine based on the event that’s fired. Without it, both functions would get called on all four lifecycle events. Think about it this way: the fact you call your method ‘install’ is purely arbitrary. You could redefine your method: function bananaHammock($evt, $stp) { ... } so your callback would thus be:

register_callback(array($this, 'bananaHammock'), 'plugin_lifecycle.jcr_link_custom', 'installed');

Without the ‘installed’ bit, the system wouldn’t know which lifecycle event (step) to listen out for. So your function would get called for all of them.

Does that make sense?

jakob · 2016-03-09 22:33:27

Bloke wrote #298200:

Short answer: no. The output you return pops up in the place on the page where the callback fires.

Longer answer: yes, but you have to return some jQuery to reposition it.

Okay, that makes sense. I wondered if there was some kind of position variable one could take advantage of like n the prefs pane. I’m not up to scratch with output buffering, but pleased enough to have put together two mini plugins for link panel and file panel custom fields, two things I find crop up every now and then in different projects.

Does that make sense?

Yes, it does. I’ll leave it as two separate install and deinstall routines for now.

wet · 2016-03-10 06:50:18

Bloke wrote #298200:

But I don’t know why Robert has a third parameter to his lifecycle plugin.

PEBKAC. Thanks, fixed.

jakob · 2016-03-10 09:40:29

Thanks Robert for updating the sample plugin and adding comments. All very useful.

BTW: There’s a small typo in the name of the lifecycle function that prevents it working, once repaired all is okay.

wet · 2016-03-10 10:55:38

jakob wrote #298208:

BTW: There’s a small typo in the name of the lifecycle function

Mine? Yours?

etc · 2016-03-10 12:50:45

jakob wrote #298198:

The new field appears right at the end. Can I also influence at what position it appears, e.g. make it appear before the description textarea? and if so, how?

Have you thought of CSS display:flex and order properties? That’s not very robust re adding new elements, but could work if things are under your own control.

jakob · 2016-03-10 13:24:48

wet wrote #298209:

Mine? Yours?

Here function public static function lifecyle needs to be public static function lifecycle (second c missing). It took me a while to see that too.

Textpattern CMS

Textpattern CMS support forum

#1 2016-03-09 17:47:08