Plugin integration with core panels

Bloke · 2021-04-21 10:31:25

Textpattern 4.8.6 is shaping up nicely. One thing we’ve done is add a few callbacks into the Diagnostics panel which allows plugins such as rss_admin_db_manager to hook directly into this panel instead of occupying its own panel suite in the Extensions area. Functionally it’s not much different and, in this case, doesn’t save much plugin code because each sub-panel is being created from scratch anyway. But I’ve always been conscious of it greedily adding three panels to the Extensions menu, which seems excessive. From 4.8.6 this is a lot neater, tucked away in the Diagnostics low/high dropdown where it makes more sense.

Taking this concept further, I’m keen to explore methods for allowing plugins to take a more involved approach to integration with core panels. That does have the possibility of cutting down on a lot of unnecessary/duplicate code.

Over the last few days I’ve been playing with the same kind of idea on the Users panel, and intend to push the changes to 4.8.6 because, visually and functionally, nothing changes. What this does, however, is add a bunch of panel-level callbacks at key places:

steps, just like the Diagnostics panel, so plugins can add their own sandboxed callbacks directly
a hook point for altering the database columns that are fetched and displayed in the table
a hook to alter the tables that are queried (including JOINs)
a hook for intercepting the buttons displayed in the control panel area above the table
a pluggable_ui() hook raised on each table row

Coupled with the ability to alter the existing search parameters (as you can already) this equates to being able to seamlessly extend what is displayed in the table. Core handles the rest – column options, search criteria, and so forth. I’ve tested it out with smd_user_manager (work still underway) and I’ve cut the plugin code from 110KB down to 80KB. No duplication. It just slots into place if you have privileges to view the extra bits and pieces. If not, core carries on as if the plugin wasn’t there.

Yes, the extra callbacks – especially one per data row – could be deemed computationally expensive, but Oleg made a lovely change recently in 4.8.6 that optimised the callback storage so it’s potentially much faster to find and serve the correct ones. I wanted to piggyback on that work as soon as I could before we let 4.8.6 out the door. So far, it’s beautiful.

Plugins can already extend the User Edit panel (smd_bio does this) but the new features outlined above mean that smd_bio could in theory allow you to arbitrarily add columns to the main Users list panel too. That would expose them to become searchable/sortable if you wish – pretty much for free, built into core. Now, I say in theory because I haven’t tested how this works if multiple plugins want to join the party. Since they can mess with the query that builds up the panel, it’ll be up to each plugin to remain as well-behaved and unobtrusive as it can. In other words: don’t trash the data passed in, but add to it carefully.

It’s not really much different to now – plugins can chain and affect output from other plugins, it’s just that with this change it’s going to be more ingrained at the panel building level, instead of you having to recreate the entire panel in your own code. If I get a chance, I’m going to play with combining the output of smd_user_manager and smd_bio to add a few bio columns to the Users list panel alongside the existing core data.

This change is deliberately focused on adding content to the Users panel HTML table. Although you could remove core columns from the query, the row data will always try to be displayed at present so if you did that, your table would be smashed up and you’d see error messages everywhere.

With a few small changes, it’s possible to be more clever: only output the column data if it’s present, and alter the pluggable_ui() callback in each row so that it passes the current HTML (<td>...</td><td>...</td>) to plugins as well. That would allow plugins to scrape the output at the DOM level and edit bits to radically alter what core exposes. I’m not sure if that’s a good idea, so I’ve crippled this behaviour on purpose for now to discourage it. But if we think it has value, the option is there in future.

The scope of the changes I’m planning in the next day or so are deliberately limited to a single panel. That’s why I’m testing the waters here in 4.8.6: the Users panel is tucked out of the way for most people.

But if this concept works, and plugins can be chained sensibly, then imagine what it would do for the Content>Articles panel. A plugin could radically alter the columns, rows and searchability of the Article data. Cut down what row content certain roles see. Expand the article column data and actually show that data in the table and allow people to filter/sort by it.

I’ve wanted this kind of thing for ages, yet we never had the infrastructure to explore it in an unobtrusive, meaningful way. Now we do. So if this works, expect some exciting possibilities for plugins in future, starting with the Users panel.

Bloke · 2021-04-22 14:27:41

I’ve just tested this with smd_user_manager and smd_bio co-existing. I cheated with smd_bio, added a couple of columns for social media handles and hard-coded them in the plugin to add them to the users panel. It worked! They popped up alongside the smd_user_manager asset counts and were searchable/filterable.

So I’ve pushed the commits 1 and 2 which enable this feature. Please would people thoroughly test the Users panel in the 4.8.6-dev branch: filter, sort, search, change pass, new accounts, etc, etc. just to check that nothing has gone awry.

If nothing seems any different then I’m happy. But please state anything that goes wonky here. Thank you.

Last edited by Bloke (2021-04-22 14:28:33)

Textpattern CMS

Textpattern CMS support forum

#1 2021-04-21 10:31:25

Plugin integration with core panels

#2 2021-04-22 14:27:41

Re: Plugin integration with core panels

Board footer