Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Textpattern themes: a plan
philwareham wrote #291645:
If there was a future rah_flat type plugin that allowed flat files with the ability to also edit in the control panel, that would be my top choice for a theme system. i.e.:
+10000000000000000000000000000000000000001, with that folder structure. That’s pretty much what I listed in my reply to johnstephens above.
We should shoot for that as a long-term goal, maybe even design rah_flat out. I mean, primarily its use is to sync files with the DB isn’t it? Without the DB being involved, is the plugin even needed? Or does it offer other stuff besides?
Last edited by Bloke (2015-06-18 11:46:55)
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: Textpattern themes: a plan
philwareham wrote #291645:
If there was a future rah_flat type plugin that allowed flat files with the ability to also edit in the control panel, that would be my top choice for a theme system. i.e.:
Have a theme directory in the root, within that the theme’s directory itself, within that a specific expected directory structure to store pages/forms/css/(theme)images/js/prefs
That would be beautiful. Allows versioning, allows natural browser caching (i.e. CSS and JS as flat files if desired), easy switching between themes. Lovely stuff.
How would this work exactly? If I edit a form in the Txp UI, are changes saved in the Txp base only or also in the flat files (not sure it’s even possible)?
Have a theme directory in the root, within that the theme’s directory itself, within that a specific expected directory structure to store pages/forms/css/(theme)images/js/prefs
Good. In my themes I use /img for for non content images. It can’t be counfounded with /images.
Last edited by NicolasGraph (2015-06-18 12:03:25)
Offline
Re: Textpattern themes: a plan
NicolasGraph wrote #291648:
How would this work exactly. If I edit a form in the Txp UI, are changes saved in the Txp base only or also in the flat files?
I guess it would have to mirror the flat file in the database, which some sort of check for changes or a way to sync the two if changes are made outside of control panel (like rah_flat does with the public callback hook URL). Not being a programmer I have no idea if that is even workable – it’s just my dream theme setup.
If database is not needed to store this stuff, then that would also be preferred choice, but I fear that might be a wish too far.
Offline
Re: Textpattern themes: a plan
Bloke wrote #291646:
True, but if you wanted to edit a plugin from a different theme, you might have to go back to the Pages/Forms/Stylesheets panel, select a new theme, then come back to the Admin->Plugins panel just so you can see them. Unexpected hoops.
Ok for a select list and/or we could also have three parts on the same page:
- Independant plugins;
- current theme dependant plugins;
- other theme dependant plugins.
Last edited by NicolasGraph (2015-06-18 12:02:05)
Offline
Re: Textpattern themes: a plan
Hi Stef,
Watch out for those ghostly voices ;)
My idea was to provide a mechanism for a newbie to get up and going on TXP quickly by picking from a collection of themes. Freely available HTML templates litter the web, and these templates can be converted to use txp:tags in an afternoon. Simple themes don’t require plugins, and a README would point the user towards any config changes they would need to make. Images and Javascript files, if needed, would remain in the directory tree under the themes directory.
Now if someone has an e-commerce theme they want to sell and it includes the kitchen sink of plugins and preference changes, then they should just package up a complete Textpattern installation if that’s the case.
Simple, baby steps would be preferable than trying to match what somebody like WordPress does, oh the horror!
This was my initial idea for themes: Textpattern Themes
Note the plugins directory, it was to include the hcg_templates plugin that they would need to install to get going. Packaging up plugins with a theme is a bad idea, especially if a theme is packaged up and then sits on a shelf for a period of time and Textpattern is upgraded and plugins are upgraded, you get the quality control dilemma. README: Dear new TxPerson, in order for your theme to work , you need to install txp_floating_menu_with_glitter from the TXP plugins repository.
K.I.S.S.
Edit: The forum thread that started it all, I can’t believe it was 8 years ago.
Last edited by hcgtv (2015-06-18 12:07:24)
We Love TXP . TXP Themes . TXP Tags . TXP Planet . TXP Make
Offline
Re: Textpattern themes: a plan
hcgtv wrote #291651:
Note the plugins directory, it was to include the hcg_templates plugin that they would need to install to get going. Packaging up plugins with a theme is a bad idea, especially if a theme is packaged up and then sits on a shelf for a period of time and Textpattern is upgraded and plugins are upgraded, you get the quality control dilemma. README: Dear new TxPerson, in order for your theme to work , you need to install txp_floating_menu_with_glitter from the TXP plugins repository.
Packaging is a way to be sure plugins versions work with the theme, no?
Last edited by NicolasGraph (2015-06-18 12:12:35)
Offline
Re: Textpattern themes: a plan
hcgtv wrote #291651:
My idea was to provide a mechanism for a newbie to get up and going on TXP quickly…
This would be OK by me in the short term – get the directory structure agreed now with a basic import mechanism – lays the groundwork for a more complex solution in the future post 4.6 (which has enough unfinished features already as it is).
Plugins are a real problem, and one that WordPress hasn’t really solved satisfactorily themselves even with all their collective knowledge and skills.
Offline
Re: Textpattern themes: a plan
hcgtv wrote #291651:
Simple themes don’t require plugins, and a README would point the user towards any config changes they would need to make.
Smart and simple. Do people read READMEs? ;-)
Now if someone has an e-commerce theme they want to sell and it includes the kitchen sink of plugins and preference changes, then they should just package up a complete Textpattern installation if that’s the case.
I concur. To do otherwise is a minefield.
Packaging up plugins with a theme is a bad idea
Yes and no. Yes, because of the potential rot you cite. But no if the goal is to get people up and running quickly with a theme. If a template uses a plugin tag then installing the template without it and hitting refresh on the public site will potentially generate a truckload of missing tag errors. And if they do visit the currently ghastly .org site to find the author’s site has gone away and there’s no local cached copy, it’s no fun and a round trip to the forum. Damned if you do, damned if you don’t *sigh*.
This probably needs considering alongside a better plugin upgrade mechanism which is something gaekwad and I chatted about recently. At least if a plugin is bundled with a theme and it’s out of date, a quick trip to the Admin->Plugins panel will show the offending monster in the closet and permit kicking off a simple upgrade procedure to restore balance… assuming the newer version hasn’t made any backwards-incompatible changes with the tags used in the theme.
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: Textpattern themes: a plan
Bloke wrote #291654:
This probably needs considering alongside a better plugin upgrade mechanism which is something gaekwad and I chatted about recently. At least if a plugin is bundled with a theme and it’s out of date, a quick trip to the Admin—>Plugins panel will show the offending monster in the closet and permit kicking off a simple upgrade procedure to restore balance.
Composer or Git tags could solve this maybe – but that would rely on plugin authors actually using Composer and/or Git.
Offline
Re: Textpattern themes: a plan
philwareham wrote #291656:
Composer or Git tags could solve this maybe – but that would rely on plugin authors actually using Composer and/or Git.
I’m fully on board with git. Composer less so, but that’s due to not having used it much. Is it unrealistic to expect / demand users use such a system to author their Txp plugins so we get the benefit?
I can’t see git going away any time soon, but eggs… basket…
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: Textpattern themes: a plan
NicolasGraph wrote #291652:
Packaging is a way to be sure plugins versions work with the theme, no?
Assuming Txp core hasn’t altered in the meantime. Though not exactly plugin related, remember the <txp:sitename> / <txp:site_name> debacle with early themes?
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: Textpattern themes: a plan
hcgtv wrote #291651:
The forum thread that started it all, I can’t believe it was 8 years ago.
Yeah, there’s glacial and then there’s Textpattern. Mañana.
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