Textpattern themes: a plan

Bloke · 2015-06-18 09:01:44

NicolasGraph wrote #291628:

Textpack

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?

Images I mentioned in my reply to johnstephens, as I forgot them in the OP.

[Plugins panel] Would it be possible to have the same theme structure than the pages and forms.

Maybe. But there are differences that manifest themselves in UI workflow issues:

Pages, Forms and Stylesheets have one copy per theme. That is, any given page can only be assigned to a single theme. From a database viewpoint, it’s a one-to-one mapping. If you select a theme from the dropdown and hit Create new [Page|Form|Stylesheet] then you get a new resource in the currently selected theme. Duplications can be easily catered for too, using the dot notation I mentioned in the OP.
Plugins, however, by their very nature have to be shared across themes. Therefore, having a dropdown at the top is fine to show only those plugins that are for the currently selected theme, but you need a way to define which plugins are in use for each theme. Plus a mechanism for allowing one plugin to be associated with more than one theme (and depicting that visually). The many-to-one DB structure behind the scenes isn’t hard to do, it’s how you define things from the UI I’m concerned about. I can’t think of a nice method to assign and display it all without confusion/clutter.
Some plugins will be theme independent (workflow plugins such as rah_flat for instance) and these will always be “visible” no matter which theme is currently being worked upon, but should not be packaged with the theme at export time. So they need to be differentiated somehow, visually at least.
Unlike with Pages/Forms/Stylesheets which can be ‘switched in and out’ based on selecting a theme, plugins will not be turned on and off (enabled/disabled) when a theme is selected. There are, however, two approaches we can choose from here:
- (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 the load_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).

I think prefs are really linked to themes and if Textpattern gives a way to load different themes it should propose a native way to manage their prefs.

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?

I thought to use txp:variables in styles… slows the css loading isn’t it?

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. Changes can either be reflected in the disk-based or DB-based Sheets (or both). That’s likely to be plugin time, not core as we probably won’t be permitted to distribute SASS with Txp! Dunno.

If we have an official path to load themes it would be nice to see rah_flat scanning this path and displaying a select list to switch as you want to make it in the Presentation tab.

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.

Bloke · 2015-06-18 09:24:41

sacripant wrote #291633:

if you really want to offer specialized and professional theme, your proposal seems too low.

Maybe, maybe not. It’s all about separation of concerns. A lot of what you talk about is admin-related so an admin theme is more appropriate. I think we’re considering two entirely distinct use cases, that have some crossover:

A method to skin existing content with a fresh coat of paint (my OP).
A method to load Txp up from scratch with a spanking new theme, content, admin skin, workflow, yahde yahde (your proposal).

Your idea is great. But it’ll wreak havoc on a site if you already have content installed. How can it add articles to your existing site without potentially destroying your existing stuff? How can it add or alter custom fields? Let’s imagine your clothes website uses custom_1 to hold a Price field and you have 500 articles “for sale”, if you install a theme that has custom_1 defined as colour, and custom_2 is Price, your site is going to break simply by installing the theme. It’s incompatible with the notion of a theme in this case.

I think we need to draw the line on what exactly a theme is, and set the ground rules. That’s what this thread is about and why I started it. The line is blurred of course between admin and public side. Plugins and some pref settings (I hadn’t thought about those, thanks for mentioning it) do play a role. Comment settings, for sure. But things like Textile on/off for articles, the site name, slogan, URL, production status, etc, have nothing whatsoever to do with themes in this context. Custom fields too (currently set up as prefs, but in future they’ll be entirely separate) have no role in what I proposed. They’re content related.

Plugin configuration is a thorny issue. From a workflow perspective you might like to offer adi_matrix or, as you say, smd_tabber tabs. But if you already have those installed and set up for your existing content, installing a public theme shouldn’t trample on all your hard work.

That’s why I’m interested in setting out what we consider a theme to be and, more importantly, what it is not.

If out of all this, a super duper sed_cleaner-style plugin sprouts up which hooks into the initial setup routines of Textpattern and allows you to install and configure a baseline for the type of site you want to make, that’d be brilliant. It’d be like admin theme + public theme + settings + plugins + content all rolled into one. No reason it couldn’t utilise a similar folder structures to that proposed above — an extension of it — and we should definitely consider the possible structure as this takes shape so it can be extended in that manner. But I’d hesitate to call that a “theme”.

Perhaps we need a new name for that kind of thing to differentiate it from the comparatively simplistic skinning exercise I proposed at the top of the thread? Or a new name for Bert’s ‘collection’ proposal outlined in the OP to make it clear that it’s a coat of paint, not an entire eco-system like you propose. I just wouldn’t want the support calls and negative publicity when someone installs a “theme” to try it out and finds it trashes their site by tinkering with content!

Bloke · 2015-06-18 09:41:05

colak wrote #291634:

How I thought the rvm plugin could work is on site design changes.

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, Goldfish and Halibut on the Presentation->Themes panel, you set one as the master, public theme. Let’s choose Goldfish, 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 shows Goldfish. But, behind the scenes, the act of choosing Halibut sets a pref or something, just for you. If you go to the Presentation->Forms (or Stylesheets) panel, Halibut will 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 master Goldfish setting, 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 the Halibut theme” 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 to Golfish or another theme you started called Shark. 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?

colak · 2015-06-18 10:28:27

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, Goldfish and Halibut on the Presentation->Themes panel, you set one as the master, public theme. Let’s choose Goldfish, 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 shows Goldfish. But, behind the scenes, the act of choosing Halibut sets a pref or something, just for you. If you go to the Presentation->Forms (or Stylesheets) panel, Halibut will 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 master Goldfish setting, 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 the Halibut theme” 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 to Golfish or another theme you started called Shark. 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!!!!!!!!!

philwareham · 2015-06-18 10:29:39

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.

Bloke · 2015-06-18 10:45:25

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.

philwareham · 2015-06-18 11:04:15

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.

Bloke · 2015-06-18 11:26:02

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.

NicolasGraph · 2015-06-18 11:26:51

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 the load_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…

NicolasGraph · 2015-06-18 11:35:21

philwareham wrote #291641:

WordPress uses flat files for themes still with the option of editing them directly within the control panel.

+1

philwareham · 2015-06-18 11:40:44

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.

Bloke · 2015-06-18 11:42:05

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.

Textpattern CMS

Textpattern CMS support forum

#13 2015-06-18 09:01:44

Re: Textpattern themes: a plan

NicolasGraph wrote #291628:

#14 2015-06-18 09:24:41

Re: Textpattern themes: a plan

sacripant wrote #291633:

#15 2015-06-18 09:41:05

Re: Textpattern themes: a plan

colak wrote #291634:

#16 2015-06-18 10:28:27

Re: Textpattern themes: a plan

Bloke wrote #291637:

#17 2015-06-18 10:29:39

Re: Textpattern themes: a plan

#18 2015-06-18 10:45:25

Re: Textpattern themes: a plan

philwareham wrote #291639:

#19 2015-06-18 11:04:15

Re: Textpattern themes: a plan

Bloke wrote #291640:

#20 2015-06-18 11:26:02

Re: Textpattern themes: a plan

philwareham wrote #291641:

#21 2015-06-18 11:26:51

Re: Textpattern themes: a plan

Bloke wrote #291635:

#22 2015-06-18 11:35:21

Re: Textpattern themes: a plan

philwareham wrote #291641:

#23 2015-06-18 11:40:44

Re: Textpattern themes: a plan

#24 2015-06-18 11:42:05

Re: Textpattern themes: a plan

NicolasGraph wrote #291643:

Board footer