Themes setup: where to load?

Bloke · 2017-10-16 22:35:36

With Themes support just around the corner (honest), there’s arguably overlap between the default theme in the setup directory and the default public theme in the themes directory. Work on moving the theme pages/forms/styles out of setup has already begun.

Doing this avoids duplication. It bundles the theme in the ‘right’ place. Thus the only stuff left in setup would be the prefs (data dir) and welcome article content (articles dir). The latter is only needed because a core Theme does not (yet) include article content. Maybe when we expand the scope of a Theme to include a full Package like Bert suggested, we can do more in core.

However, I’m now wondering if shipping a theme here is such a good idea after all.

For brand new installations, it makes sense. This is the process:

Run setup as normal.
Last step offers the choice of admin side theme and now offers choice of public theme as well.
It gets the list of available themes from the setup directory and also any themes you might have dropped into the themes directory by hand.
Thus you can choose the default bundled theme, or one of your own as a base. Once you’ve installed this one, you can login to your brand new Txp and from the new Presentation->Themes panel, you can go nuts and install other themes.
You can import (to the database) or export (to the filesystem) themes as you see fit.

Now let’s think about upgrades:

No setup directory exists.
Thus no default theme. Makes sense.
You upload all the files and visit the admin side to complete the upgrade as normal.
If we ship 4.7.0 with the ‘default’ theme inside the themes directory, we have an immediate mismatch between the on-disk theme – the pages/forms/styles in a folder called default – and the current database theme, which is made up of the site’s current pages/forms/styles. That’s also going to be called ‘default’ immediately after upgrade.
If you do an import there’s a chance you might destroy your current site template and restore it to the factory default. That’s undesirable.

I know it’s a slim chance and there’s confirmation on import yahde yahde, but I’m wondering if it makes more sense to ship the Txp files bundle with an empty themes directory and leave the setup folder as the only copy of the factory default theme structure. Thus there’s no potential mismatch. Thus you can’t obliterate your database theme with the factory default theme unless you copy it into a themes/default folder and perform an import. And the only time you get anything in the themes directory is after you export a theme or manually copy stuff in there.

To me, that seems safer. Does that make sense or have I missed some nuance in the system that means shipping the factory default theme in the themes directory is a good idea?

etc · 2017-10-17 08:11:21

I’d say, default theme should be some minimalist “Go pick some theme” link. It shouldn’t be editable, nor even selectable, just a crash-pad in case there is no theme installed at all. Ship it in setup or even hard-coded. And all “true” themes would go into themes directory. Dunno how to organize the migration of the current default though.

philwareham · 2017-10-17 08:31:32

I disagree sorry – we need the basic default theme in my opinion, and I’m inclined to leave it in the setup folder now as Bloke suggests. We can always guide people to investigate themes further via text in the Welcome article.

But we should ensure the default theme follows exactly the structure as other themes (i.e. have a manifest.json file, same page/form/style folder structure, etc.).

phiw13 · 2017-10-17 08:47:33

I haven’t tested the themes branch yet, beyond installing it. For some strange reason I always seem to run into bugs with those branches… :-(

But if the upgrade situation is as Bloke describes, then better leave the default theme in the setup folder. I wouldn’t want the upgrade process to mess with a live site.

PS – agree with philwareham. TXP needs a default theme as an example.

Bloke · 2017-10-17 08:52:36

philwareham wrote #307397:

we need the basic default theme in my opinion

I agree. It’s a great starting point for an out-of-the-box experience, plus the inline documentation is a wonderful learning aid to help newbies take the next steps towards customization. Anyone who doesn’t like it or wants to install something different on a brand new install now has the option of dropping their own theme in the themes directory and installing it right out of the gate.

We can always guide people to investigate themes further via text in the Welcome article.

Good idea.

we should ensure the default theme follows exactly the structure as other themes (i.e. have a manifest.json file, same page/form/style folder structure, etc.).

Absolutely. In fact, I think makss did just that, changing the setup routine to use Form folders and manifest.json.

In theory – and this’ll be a good test – we should be able to a) empty the themes directory, b) copy the manifest file and the pages/forms/styles directories out of the setup directory and stuff ‘em all in a themes/test_theme directory, and be able to import it from the Themes panel.

If that works, we can then test if it’s possible to:

Still inject the factory theme from the setup directory during install.
Add one or more themes to the themes directory prior to running setup, check that both factory theme and the manually installed themes are given as options in the dropdown during setup, and that the chosen one is installed.

If all that checks out, as far as I’m concerned, we’re sorted.

Last edited by Bloke (2017-10-17 08:57:15)

etc · 2017-10-17 08:57:31

I totally agree that no theme at all would not be user-friendly, I just suggest to ship themes under some proper name, not as default. This would avoid name conflicts and allow for testing the new “official” themes on upgrades too. The default theme would not even exist as such, it’s just another name for notheme.

philwareham · 2017-10-17 08:58:47

Bloke wrote #307399:

Absolutely. In fact, I think makss did just that…

I’m not sure it’s totally correct yet – basically we need to house the default theme and its components within setup folder in it’s own subdirectory there called default_theme. Then in theory that follows the exact structure as if you had the same theme in the themes folder.

Bloke · 2017-10-17 09:04:34

etc wrote #307400:

I just suggest to ship themes under some proper name, not as default.

If we can do that, sure. I thought the name ‘default’ was kinda ingrained into the whole process, but maybe that’s just for Pages. This ties in with…

philwareham wrote #307401:

we need to house the default theme and it’s components within setup folder in it’s own subdirectory there called default_theme

Gotcha. The only snag is that the ‘setup’ theme includes article and prefs content, which our basic Themes don’t support yet. So do we put that content inside the ‘default’ (or whatever we decide to call the factory theme) directory or leave it separate?

philwareham · 2017-10-17 09:10:14

Bloke wrote #307402:

Gotcha. The only snag is that the ‘setup’ theme includes article and prefs content, which our basic Themes don’t support yet. So do we put that content inside the ‘default’ (or whatever we decide to call the factory theme) directory or leave it separate?

Depends whether the theme importer ignores files that it doesn’t recognise (I hope it does). Ideally yes IMO we should put prefs and article stuff into the theme’s directory. Although we need to give some consideration on how it is housed in there because if in future themes are allowed to install prefs and dummy article content (which again I hope we can eventually do one day) we need to ensure it’s house correctly right now.

PS. I’m fine in renaming the default theme if something is better – although I think ‘default’ kind of sums it up nicely.

Bloke · 2017-10-17 09:19:40

philwareham wrote #307403:

if in future themes are allowed to install prefs and dummy article content… we need to ensure it’s house correctly right now.

Yeah, that’s my concern. We haven’t given the extension of themes into Templates, and Packages (or whatever the terminology becomes) enough thought, as they’re future concepts.

If we’re shipping just a “Theme” (the basic Lego scaffolding) then my gut feeling is they’re the only components that should be included, otherwise we potentially trip ourselves up on our own conventions or scupper what we do in future. Perhaps later when we decide how to handle more content, we can fold the additional stuff like articles and prefs into the setup folder then? For now leave them separate.

I’m fine in renaming the default theme if something is better – although I think ‘default’ kind of sums it up nicely.

Default is fine. Not very sexy, but fine. A nameless rival of ours ships new versions of the CMS with themes named after the year. Admin themes ship with nice names in Txp after all. Nothing to stop us giving our default public theme a decent name. Could even open it up as a competition to the community. Winner gets their chosen theme name used in Txp as our factory theme :-)

Last edited by Bloke (2017-10-17 09:20:25)

philwareham · 2017-10-17 09:23:03

Bloke wrote #307404:

If we’re shipping just a “Theme” (the basic Lego scaffolding) then my gut feeling is they’re the only components that should be included, otherwise we potentially trip ourselves up on our own conventions. Perhaps later when we decide how to handle more content, we can fold the additional stuff like articles and prefs into the setup folder then? For now leave them separate.

OK, that’s fine then. If I upload a new folder called default_theme into setup, and delete the older pages/forms/styles folders there and commit – can you please then hook up that new folder so it works?

etc · 2017-10-17 09:26:22

Bloke wrote #307402:

If we can do that, sure. I thought the name ‘default’ was kinda ingrained into the whole process, but maybe that’s just for Pages. This ties in with…

We can untie whatever we need, it shouldn’t be much code. The main problem I see is that default is currently (4.6) used as theme, without respecting the themes structure, i.e. without being a true 4.7 theme. What to do with it on upgrade is unclear, but certainly not replace it with a new default. Let’s call the new default (shipped in themes), say, factory and progressively make the old default “theme” erasable.

Textpattern CMS

Textpattern CMS support forum

#1 2017-10-16 22:35:36