Queries about the 4.8 plugin regime

Bloke · 2021-06-22 14:30:45

etc wrote #330610:

I was thinking of renaming them to, say, .inc instead of .php, but this requires a massive code rewrite.

Shame. That’d be a neat solution.

gomedia · 2021-06-23 07:44:02

I know I’ve banged on about this before but the Textpattern upgrade process has always been fiddly and potentially problematic.

During upgrade, I’ve got it engraved on my brain NOT to copy the distribution files, images & textpattern directories into the website root folder – for fear of splatting my files, images and config.php.

Copying the contents of textpattern was less of a problem, until the plugins directory arrived … now I have to stay awake for that part of the operation too!

etc · 2021-06-23 08:27:24

gomedia wrote #330626:

Copying the contents of textpattern was less of a problem, until the plugins directory arrived … now I have to stay awake for that part of the operation too!

Mea culpa, sorry. In 4.8.8 it will be possible to set the plugins directory in config.php, and I hope that in 4.9 we will move all user data out of textpattern directory.

Right now you can remove the definition of PLUGINPATH from constants.php and set it in config.php as desired. You should then move the existing plugins to the new directory. Upgrading to 4.8.8 shouldn’t make any problem.

phiw13 · 2021-06-24 05:45:45

etc wrote #330627:

Mea culpa, sorry. In 4.8.8 it will be possible to set the plugins directory in config.php, […].

That sounds good. Like gomedia, I often worry about blowing away [something important]™ when updating a Textpattern install. Can you confirm, this would be the correct syntax (store the plugins in foldername at the root of the domain)?

define('PLUGINPATH', '/foldername/')

etc · 2021-06-24 06:47:22

phiw13 wrote #330642:

Can you confirm, this would be the correct syntax (store the plugins in foldername at the root of the domain)?

define('PLUGINPATH', '/foldername/')...

I have tested txpath.'/../foldername' which seems to work, but not any further. Please share your findings :-) Note that in pre 4.8.8 you need to comment out this definition in constants.php, otherwise there would be a conflict.

phiw13 · 2021-06-24 07:27:03

etc wrote #330644:

I have tested txpath.'/../foldername' which seems to work, but not any further. Please share your findings :-) Note that in pre 4.8.8 you need to comment out this definition in constants.php, otherwise there would be a conflict.

Thank you, I’ll try to spend some quality time with a local 4.8.8 install tomorrow and report back if anything goes wrong.

phiw13 · 2021-06-25 02:09:40

phiw13 wrote #330647:

Thank you, I’ll try to spend some quality time with a local 4.8.8 install tomorrow and report back if anything goes wrong.

OK some testing on the local play ground (TXP4.8.8-dev PHP 8.07, MySQL8.022).

That went pretty well with the syntax you suggested txpath.'/../foldername'. I tried first my original idea but that returned errors (one for each installed plugin). After changing that, everything is fine, plugins work – both on the public side and the admin. side.

Neat improvement.

phiw13 · 2021-06-25 02:09:40

phiw13 wrote #330647:

Thank you, I’ll try to spend some quality time with a local 4.8.8 install tomorrow and report back if anything goes wrong.

OK some testing on the local play ground (TXP4.8.8-dev PHP 8.07, MySQL8.022).

That went pretty well with the syntax you suggested txpath.'/../foldername'. I tried first my original idea but that returned errors (one for each installed plugin). After changing that, everything is fine, plugins work – both on the public side and the admin. side.

Neat improvement.

etc · 2021-06-25 09:59:30

Thanks for testing. Still unsure how plugins must be stored: in a central place or per theme. Themes are fun like Pandora boxes.

Bloke · 2021-06-25 10:46:22

I think plugins could co-exist, to a degree, with a little tweaking. But the details might make it a no-go. A series of thoughts/ideas:

An optional /plugins dir in a theme’s area could house plugins exactly like we do with system-wide ones. One plugin per subdir.
Tweak the Admin>Plugins panel so it has a Theme selector at the top. If it’s set to the empty entry (or one labelled: ‘global’ or ‘system’) then the plugins shown are those stored in the central location (governed by the pref/config.php entry). Otherwise it filters them to only show the ones in the current theme.
Tweak the plugin loading system so that public plugins are loaded by theme first and if they don’t exist, fall back on the system plugin area. That gives the ability to try upgraded plugins in a dev theme to see the effect before pushing them system-wide (if you want).
It might be nice to indicate on the Plugins panel if there’s more than one in the chain. e.g. if you’re on the system list and there’s a plugin of the same name installed in a theme, show an indicator. And vice versa if you’re displaying the plugins in a theme.

Admin plugins – not sure. Would it be too confusing to have them loaded based on the current working theme first, with system fallback? If you change working theme, you’d potentially change plugin version or lose access to it if there’s no fallback in the system dir.

Performance-wise, again, not sure. Might be unworkable.

When installing a plugin, it’d go in the area governed by the currently selected theme in the dropdown on the Plugins panel. We just need skin/dev_skin columns in the plugin table.

Multi-edit options could permit moving or duplicating plugins from one theme to another or deploying one ‘live’ to the system area, a bit like we do with deploying theme assets.

If you push a theme live then it of course automatically puts any of the theme’s installed plugins to the live site, by virtue of the fact the in-force theme in the current public section is checked first for plugins before falling back.

That means if you isolate a theme to a given section and install a plugin in that theme, you can test it in just that section. Same if you put a section in the development lane. Very handy.

Another option would be to allow different versions of the same plugin to be installed in a single area. And then simply assign a plugin ‘version’ to a theme instead. If a theme is installed that has a /plugins directory, they could be pulled into the system-wide plugins dir and the version numbers associated with the theme so the system knows which one to load first when it encounters a theme.

I’m sure there’s lots I’ve not thought about. This might be totally impossible and need a rethink. Just throwing it out for discussion while I think about it.

The main problem is going to be plugins that use their own tables or dirs for data storage. And their own prefs. They won’t have any notion of which ‘version’ or physical plugin is in force so any changes to the configuration will affect them all. That’s also an issue if a plugin has a different table structure between versions.

Not sure there’s an answer to that! It’ll just break the older version once the newer is installed unless we can somehow automatically namespace the tables (per plugin version) on a user’s behalf. Essentially, when accessing safe_*, look at the plugin version and get data from the plugin table/pref associated with that version.

That won’t help anyone who’s hard-coded table access of course, but we can only go so far to provide infrastructure. It’d be up to plugin authors to start using the tools so they become theme-aware.

Last edited by Bloke (2021-06-25 10:57:22)

etc · 2021-06-25 11:02:02

Bloke wrote #330679:

I think plugins could co-exist, to a degree, with a little tweaking. But the details might make it a no-go.

The devil is in the details, sure. If we continue this way, we should also allow for theme prefs, language strings and so on…

Out of curiosity, does someone use multiple themes in production?

Bloke · 2021-06-25 11:14:05

I do!

Textpattern CMS

Textpattern CMS support forum

#13 2021-06-22 14:30:45

Re: Queries about the 4.8 plugin regime

etc wrote #330610:

#14 2021-06-23 07:44:02

Re: Queries about the 4.8 plugin regime

#15 2021-06-23 08:27:24

Re: Queries about the 4.8 plugin regime

gomedia wrote #330626:

#16 2021-06-24 05:45:45

Re: Queries about the 4.8 plugin regime

etc wrote #330627:

#17 2021-06-24 06:47:22

Re: Queries about the 4.8 plugin regime

phiw13 wrote #330642:

#18 2021-06-24 07:27:03

Re: Queries about the 4.8 plugin regime

etc wrote #330644:

#19 2021-06-25 02:09:40

Re: Queries about the 4.8 plugin regime

phiw13 wrote #330647:

#20 2021-06-25 02:09:40

Re: Queries about the 4.8 plugin regime

phiw13 wrote #330647:

#21 2021-06-25 09:59:30

Re: Queries about the 4.8 plugin regime

#22 2021-06-25 10:46:22

Re: Queries about the 4.8 plugin regime

#23 2021-06-25 11:02:02

Re: Queries about the 4.8 plugin regime

Bloke wrote #330679:

#24 2021-06-25 11:14:05

Re: Queries about the 4.8 plugin regime

Board footer