Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Queries about the 4.8 plugin regime
etc wrote #330677:
Still unsure how plugins must be stored: in a central place or per theme. Themes are fun like Pandora boxes.
Most (that is 99.9% of the plugins I use) are not there for a particular theme (by whatever definition of a theme) but for managing and publishing content. Things like managing image thumbnails(that one…), adding meta-data fields (adi_file_tab, jcr_*_custom_field), speeding up (?) content rendering (etc_cache) and the like.
etc wrote #330680:
Out of curiosity, does someone use multiple themes in production?
not me!
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Offline
Re: Queries about the 4.8 plugin regime
etc wrote #330686:
Do they need concurrent plugins/prefs/etc?
Not usually, nope.
Thinking again, this concept of linking plugins to themes as only really handy when bundling a theme up for distribution. Upon installation, it doesn’t really matter if they are installed to a central area. The only issue is that if there are existing plugins they might clobber them, which has the potential to affect the in-use (live) theme even if you’re installing a (dev) theme to try out.
Plus, bundling plugins is fine but in five years’ time when someone downloads an old theme and things have moved in, it’s not really helpful. More useful than bundling physical plugins is providing links to the central repo of plugins (maybe in the manifest), so that they can be installed on-the-fly if that version is still available for download there.
I still keep coming back to a ‘preview’ step for themes. You go to install a theme (from disk) and it pops up a panel showing you what it’s going to do:
- add (N) Pages/Forms
- add (M) Styles
- install prefs abc_whatnot and abc_something_else and change comment status to On by default
- add Sections a, b, c (if they don’t already exist)
- add these articles/images
- install these plugins (with versions)
and so on.
So it presents you with a report just like it does on the Plugins panel and a Proceed or Cancel button. But crucially it adds checkboxes next to all the supplemental components. You can’t opt out of pages/forms/styles or theme prefs, but global prefs, plugins, and content you could untick if you wished.
If there’s a clash detected in the preview step, a plugin could even be unchecked by default. Or maybe it’s left checked and a warning issued alongside it in the pre-installation report so you know that proceeding will potentially affect your current site. But the plugin process then remains unchanged from today: one central set to govern the site. Simpler. Less error prone.
Nothing to stop you manually installing the plugin later or going through the theme update process and requesting to trigger the preview step again. I think by default it shouldn’t ask you on update, else it slows down the process of importing from disk during theme development.
On reflection, I think that is actually more beneficial to end users than bundling plugins in the theme itself, because then all we need to do is allow people to choose which assets get exported to disk or included in the manifest during development, ready to be zipped up and distributed. Whether that’s done in a core plugin (like smd_admin_themes does) or built in is a discussion we can have in future.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Queries about the 4.8 plugin regime
Yep, that sounds like a plan. If I only knew how Composer works… We could maybe borrow some of its features. And the manifest could be used on uninstall too, asking the user which changes should be reverted. Or even core could keep traces of all changes (wish I knew how Git works…)
Well, we seem to agree on a central storage idea, that makes progressive enhancements easier.
Offline
Re: Queries about the 4.8 plugin regime
etc wrote #330696:
Yep, that sounds like a plan. If I only knew how Composer works… We could maybe borrow some of its features.
Hah, me too. Damn voodoo, that thing :)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline