pluggable_ui

variaas · 2009-03-20 14:17:10

Ok guys, this is a great day. After playing around with the new theming capabilities, I got around to checking out all the work around pluggable_ui(). This is probably something the core devs are still working on, but if what we have now is any indication, this is going to be amazing! Using the same callback system we use right now to create new admin plugins, we can override parts of the admin ui. I did a quick screenshot of what it would look like if you removed every pluggable_ui element in Content->Write.

You can see there are still a couple elements still there, but it’s pretty much empty. I want to point out the table structure is still there, so you won’t be removing that with this functionality. I see this helping remove the need of javascript for some admin plugins.

Here’s a couple plugin ideas:

Customized Write Tab – if you’re using custom fields, you can have a plugin that brings those fields into the center column.
Granular controls over uploads – you can now control who upload images and files

What else could we do with this new functionality?

Bloke · 2009-03-20 14:31:22

It is indeed marvellous.

I touched on this earlier but something I’d be keen to see is a custom field ordering plugin. No longer listed 1 -> 10 but in a customisable order for disorganised people who add an extra CF as an afterthought and wished they’d not used up 1-7 already.

Combined with per-section custom fields and the kind of cf extension mechanism that jm proposed, the pluggable UI could open up custom fields big style.

Last edited by Bloke (2009-03-20 14:31:50)

etc · 2015-04-23 14:36:17

I have played a little with pluggable_ui, and got a question. Say, there are two article edit plugins that insert some stuff before “Status” input:

register_callback('abc_status', 'article_ui', 'status');
...
function abc_status($event, $step, $data) {
...
	return 'abc_stuff'.n.$data;
}

and

register_callback('def_status', 'article_ui', 'status');
...
function def_status($event, $step, $data) {
...
	return 'def_stuff'.n.$data;
}

The problem is, “Status” input will be rendered twice if both plugins are active. Or am I missing something?

Bloke · 2015-04-23 14:57:37

etc wrote #290212:

“Status” input will be rendered twice if both plugins are active.

It’s a limitation of Txp’s callback chaining. Or rather, its lack thereof. Hooks don’t pass content on, they add to what’s there and have no knowledge of what came before or what’s going after. See Gocom’s response to this question which explains it better than I can.

Of course, if you can find a better way of implementing callbacks — preferably backwards compatible as far as possible — then please send us a pull request. It’s something I’d love to address.

etc · 2015-04-23 16:02:27

Bloke wrote #290214:

Of course, if you can find a better way of implementing callbacks — preferably backwards compatible as far as possible — then please send us a pull request. It’s something I’d love to address.

Looks too naive?

function pluggable_ui($event, $element, $default = '')
{
    global $plugin_callback, $production_status;

    if (!is_array($plugin_callback)) {
        return $default;
    }

    // Any payload parameters?
    $argv = func_get_args();
    $argv = (count($argv) > 3) ? array_slice($argv, 3) : array();
    $return_value = $default;

    foreach ($plugin_callback as $c) {
        if ($c['event'] == $event && (empty($c['step']) || $c['step'] == $element) && empty($c['pre'])) {
            if (is_callable($c['function'])) {
                $return_value = call_user_func_array($c['function'], array('event' => $event, 'step' => $element, 'data' => $return_value) + $argv);
            } elseif ($production_status == 'debug') {
                trigger_error(gTxt('unknown_callback_function', array('{function}' => callback_tostring($c['function']))), E_USER_WARNING);
            }
        }
    }

    return $return_value;
}

It passes the output of every plugin as default to the next one. Tested on 4.6, seems to work, and mostly bw-compatible.

Bloke · 2015-04-23 22:53:57

etc wrote #290215:

It passes the output of every plugin as default to the next one.

Wow. Well that should certainly do the trick, thanks. I’ll test it when I get a chance, but I’d also like some feedback from other folk if at all possible. Anyone willing to give this a shot and report?

gomedia · 2018-01-16 05:49:18

In 4.7.0’s HISTORY.txt, there’s this entry:

Changed: pluggable_ui() behaves more intelligently when chaining.

Does it address the issue discussed is this thread?

etc · 2018-01-16 10:12:18

Hi Adi,

this issue was fixed in 4.6, but the fix was inconsistent with some plugins when default is empty. This inconsistency is now removed in 4.7 that runs in some “hybrid” mode, though I don’t remember the details. If you get any weird results, please report.

gomedia · 2018-01-16 11:31:55

Will do. Thanks.

Textpattern CMS

Textpattern CMS support forum

#1 2009-03-20 14:17:10

pluggable_ui

#2 2009-03-20 14:31:22

Re: pluggable_ui

#3 2015-04-23 14:36:17

Re: pluggable_ui

#4 2015-04-23 14:57:37

Re: pluggable_ui

etc wrote #290212:

#5 2015-04-23 16:02:27

Re: pluggable_ui

Bloke wrote #290214:

#6 2015-04-23 22:53:57

Re: pluggable_ui

etc wrote #290215:

#7 2018-01-16 05:49:18

Re: pluggable_ui

#8 2018-01-16 10:12:18

Re: pluggable_ui

#9 2018-01-16 11:31:55

Re: pluggable_ui

Board footer