Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Textpattern themes: a plan
Bloke wrote #291637:
Gotcha. The concept above uses a dropdown on the Pages/Forms/Stylesheets panels, so does away with the need for rvm_privileged or any theme-based switching logic, which is why I thought maybe
<txp:if_theme>wasn’t perhaps necessary.Let’s take an example. If you set up two themes,
GoldfishandHalibuton the Presentation->Themes panel, you set one as the master, public theme. Let’s chooseGoldfish, since it’s first and represents your current site.You’d see those in the select list on each of the existing Presentation panels. Say you go to Presentation->Pages and pick
Halibut, your list of Pages changes to those which are assigned to that theme (if any). You create them, edit them, do whatever you like with them. Your existing site still showsGoldfish. But, behind the scenes, the act of choosingHalibutsets a pref or something, just for you. If you go to the Presentation->Forms (or Stylesheets) panel,Halibutwill be selected so you can continue to work on that theme until you change your mind. It’d work in a similar way that Txp remembers which twisty panels you’ve opened/closed.If you then click
View site, Txp will first of all see the masterGoldfishsetting, but before it does anything will check for the pref linked to your account. In this case, it’ll go “Aha, I can see you’re working on theHalibuttheme” so it’ll show your site using those Pages/Forms/Stylesheets instead. Thus you can preview it, because you’re logged in.When ready to go live, you visit Presentation->Themes and change the master theme to
Halibut. Everyone will then see that theme. You can of course log in and switch your preview back toGolfishor another theme you started calledShark. When you refresh the public site you see whichever theme you were last working on.Does that make sense as a workflow? Or is there a better way?
Sounds perfect!!!!!!!!!
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: Textpattern themes: a plan
The whole thing would have to be handled as flat files in my opinion. I think the whole database thing for handling forms/pages/css/js is a outdated model of Textpattern that I would not be keen on keeping.
Some sort of supersized version of rah_flat with some directory standards locked in place. I can’t see it working well any other way.
I can provide Bootstrap, Foundation framework-based themes, plus one or two of my own, if that becomes a reality.
Offline
Re: Textpattern themes: a plan
philwareham wrote #291639:
The whole thing would have to be handled as flat files in my opinion.
Why? That’s a massive upheaval for limited gain. The same issues regarding prefs and plugins being on/off and not allowed (by PHP) to be duplicated affects the filesystem in exactly the same way as it does the DB. So we might as well support both, since it’s little extra code either way. Additional content such as Bootstrap and Foundation files can still be bundled as assets in the theme for others to tweak / compile in their own filesystems if they wish. The only downside to the DB model is you can’t “compile” stuff without a plugin, if that’s your bag.
Long term, if you’re intent on phasing out the Presentation panels entirely, well, that’s something you’ll have to fight me for :-) Although mildly off-topic, here’s my workflow when I want to tweak a template on my site:
- Visit Presentation->Pages.
- Make changes.
- Save.
And I have the added benefit that adi_form_links helps me jump straight to any associated template files for editing.
Under a filesystem-based approach I’d need to:
- Open local copy (assuming I have one, if not, download it first).
- Make changes.
- Start FTP / file transfer / SSH shell program.
- Connect / log in.
- Navigate to correct local and remote directories.
- Upload file.
For client projects where I have a local mirror for development, flat files make way more sense since it’s their site and changes can be documented in the VCS. But for my own site which doesn’t matter a jot, I’m willing to take the risk of editing it live and for that purpose the admin interface is waaay faster.
Maybe I need to invest in learning some automatic syncing tools so editing any files on my local copy automatically transmits changes when I signal I’m “done”. The only way I can think of is post-commit hooks, which are fine if I cared about versioning my crappy site and jumping through git hoops, but I don’t.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Textpattern themes: a plan
Bloke wrote #291640:
Why? That’s a massive upheaval for limited gain.
How are we going to store theme CSS, images and JavaScript. In the database? I hope not. WordPress uses flat files for themes still with the option of editing them directly within the control panel – is that not possible for us too?
CSS would also need to have variables injected into it in order to change colours, fonts and suchlike. How would that be handled? Possibly SassPHP or Sass.js I guess could work.
Offline
Re: Textpattern themes: a plan
philwareham wrote #291641:
How are we going to store theme CSS, images and JavaScript. In the database?
Images and JS in the filesystem since they don’t have a Txp analog (well, images do, but they’re for content, not presentation). So it’s kind of a hybrid approach. If you clicked import from the Presentation->Themes panel, you’re issuing an admin-side request so the implication is that anything that can be stored in the DB should be. That’s Pages, Forms, Stylesheets and Plugins. Everything else goes in the theme-specific folder, which is in a well-known location and the theme uses anyway.
If, however, you shun the admin-side and unzip the theme in its entirety into the theme-specific folder, the future, theme-aware version of rah_flat would take over and sync everything for you.
WordPress uses flat files for themes still with the option of editing them directly within the control panel – is that not possible for us too?
Absolutely. I misunderstood, sorry. I thought you were advocating removing the admin-side editing process entirely. Moving lock-stock to flat files is more changes than I wanted to make right now with this proposal, but I’d love to get shut of the DB wherever possible, if only for speed reasons. It means backups require both a database and a file system component to be distributed / copied when transferring sites, but you need them both anyway if you have images and files on the site, so a theme folder isn’t that much hardship to add into the mix.
If it turns out that the only way to realise themes is to bypass the DB entirely, then yay! The only reason I wanted to try and do it step by step was because we’d need to change every tag and internal routine that called the DB for template-related content to a different function that read the filesystem. And that’s potentially a lot of work, before we even begin to think about themes on top of that.
CSS would also need to have variables injected into it in order to change colours, fonts and suchlike.
Yeah, that’s a pain. But it’s a pain if editing via the admin-side, whether or not the resulting code is stored in the filesystem or the DB. The only way you can realise that (without a plugin or bundling SASS in core somehow and forcing people to use it) is to edit files outside of Txp in your text editor and compile them, or permit some form of variable injection in the CSS rendering step. Inventive solutions welcome.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Textpattern themes: a plan
Long english treads reading/replying is a hard work for me but I hang on! ‘Hope I’m in…
Bloke wrote #291635:
In what capacity is this theme-related? L10n strings that are used in prefs to control public-side theme usage are going to be handled by smd_prefset. And plugins handle their own strings. So what strings are theme-specific such that they need bundling with a theme?
For exemple, in the theme I’m working on, I’m using smd_lately to display a list of popular articles and I want to display a title like ‘Your favourite articles’. I could hard code it but it’s not the good way for translations…
Images I mentioned in my reply to johnstephens, as I forgot them in the OP.
Maybe. But there are differences that manifest themselves in UI workflow issues:
** (simplest) All plugins still run and are loaded for all themes where their permissions and type apply. Some will be admin-side, some public, some both.
** (more complicated) Change theload_plugins()function to only load plugins that match the current theme, plus any that are NOT assigned to any theme (i.e. the global ones).
Harder is probably better… Maybe we could have two different tables on the Plugins page (or two parts in the existing table with a visual separator) the top one with independant plugins and the second one with the current theme dependant plugins. We wouldn’t need a select menu to switch because it is not necessary to display plugins used by themes you are not using.
OK, I’m not entirely convinced yet (I think this is plugin territory), but let’s explore that anyway. Some prefs, yes. I hadn’t thought of things like comments display modes that do affect the front-end, so that will need thinking about. Good catch. So, firstly, how do you propose this be done in a standard way that make sense for hundreds or thousands of different themes?
About the prefs, on my side I think it would be probably good to have something like smd_prefset in the core. But for other Txp configurations, even if my vision of a theme is cloth to the Sacripant point of view, I think it also depends of the designer work. it is probably better to write a good documentation to let the user know how the theme modify his site and let him do these changes if he is ok.
Yes. Txp will not parse Stylesheets so you’re out of luck there. smd_styles will permit it, but as you say, it’ll be slower. Re-compilation via SASS when you change a pref is possible if SASS is installed on the server.
I learn everyday. Thanks Stef.
That’s up to the plugin, but my guess is that since the directory scheme / zip file structure would be largely based on rah_flat’s mechanism (with just the added “layer” for the theme name), it should be fairly easy to modify the plugin to work seamlessly with themes.
Yes it is totally plugin dependant; I just thought about it…
Offline
Offline
Re: Textpattern themes: a plan
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.
Offline
Re: Textpattern themes: a plan
NicolasGraph wrote #291643:
I want to display a title like ‘Your favourite articles’. I could hard code it but it’s not the good way for translations…
Good example, thanks. I can now see how custom textpack strings could be beneficial as they can be included in templates via txp:text which will automatically reflect the site language. Including .textpack files in the theme package and have them inserted on installation ought to be easy.
Maybe we could have two different tables on the Plugins page (or two parts in the existing table with a visual separator) the top one with independant plugins and the second one with the current theme dependant plugins.
I agree the more difficult approach is better, and that’s one way to visualise it, yeah.
We wouldn’t need a select menu to switch because it is not necessary to display plugins used by themes you are not using.
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.
The fundamental thing is finding a way to visually indicate that a plugin is in two or more installed themes, and allowing people to alter that list.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire 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.:
+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.
Hire 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