Textpattern themes: a plan

Bloke · 2015-06-17 19:37:40

Spawned from a thread about paid themes, let’s stop messing about and look at themes in Textpattern seriously. I realise I may be covering old ground here, but for completeness I’m going to lay it all out.

Bert (hcgtv) has been one of the biggest proponents of Themes for as long as I can remember, and since he resurfaced today we ought to make him a present. I’ve given the theme concept brief thought over the years and always put it in the “too hard” bucket, but with a fresh pair of eyes and some experience under my belt I gave it some thought today based on a 2010 post by Bert (see thread above). And I think his vision might be doable, fairly simply. Well, “simple” is a relative term, but I mean “not too hard to accomplish” and “backwards compatible”.

Ostensibly, a theme in Textpattern is a collection of:

Pages
Forms
Stylesheets
Plugins
Assets (thanks johnstephens)
Some prefs (thanks NicolasGraph & sacripant)
Textpacks (thanks NicolasGraph)

And that’s it. Sections transcend these and apply to all themes as they are containers for content. Categories likewise, but cutting across content. So on the face of it, all we need is a mechanism for grouping the above items. That’s easiest achieved by adding a column called theme to the Page, Form and Stylesheet tables, and setting it to be a compound index with the name field, therefore permitting the same name to be used on different themes, but only one name can be used within a template, just like now. It’s not very 4NF (the “correct” way would be with joins to link tables, which adds complexity), but simple enough so far and is better than using IDs which aren’t portable between sites.

By adding a new Admin panel, Presentation->Themes with a usual tabular layout like the Sections panel, new Themes can be created ready to assign stuff to. A simple DB table can hold the name, title, and any theme-related options we desire. If only one theme is present (as in the default case after installation/upgrade) then the rest of the UI remains essentially unchanged: you work on “the site” and you’re good to go.

Adding another theme will add, I dunno, maybe a select list at the top of the right-hand column in the Pages/Forms/Stylesheets panels that will allow you to choose which theme’s content to “load” (i.e which template content to list, ready for editing). That means you can only work on one theme at a time: I don’t think that’s too onerous a restriction. When you select one, navigating between panels retains the one you were last working on until you change it. This also serves as a hint to the “View site” link which will use the currently-selected theme to render the public site, allowing you to preview/test the theme prior to going live with it. This is probably best stored as a per-user pref or cookie or something. Ideas welcome.

A “master theme” setting on the Presentation->Themes panel would switch the front-facing theme to the selected one. Like the ‘default section’ thing does now for articles created on the Write panel. As far as the public site is concerned, it’s then business as usual once the master theme name has been read from the prefs. In the absence of any cookie/per-user pref, this is the theme everyone else sees. The new Themes panel would also house export/import links to bundle up the theme for distribution as a zip, or to install one from somewhere else. A bit like smd_macro does. And the usual multi-edit stuff to delete / rename themes (which impacts quite a few tables for one operation, but it’s manageable). More on that in a moment.

Before going too much further, I’ll mention plugins. These should be handled differently, imo. Whereas a Page, Form or Stylesheet would have its own copy (i.e. not shared among themes), you don’t really want to be installing plugins more than once. So there probably needs to be some kind of pointer mechanism to indicate which plugins a theme uses. When you export a theme, it then knows which plugins to package up. Not sure how plugin version differences would be handled, but you simply cannot have more than one version active at a time because the function names would likely clash. If you install two themes, one of which uses plugin A at v0.1 and a newer theme that uses v0.3, what do we do? Upgrade and hope it doesn’t break the existing theme? Leave it but risk breaking the new one? And how to handle people using the cache directory instead of the database for plugins?

Also, when you delete themes, from the multi-edit tool in Presentation->Themes it won’t delete plugins if there are other themes that point to it. Maybe (not sure about this) if no themes are “pointing” to it, the plugin will be deleted, but I’m not sure if that’s a good idea. It’ll probably depend on the mechanism for “assigning” a plugin to one or more themes. Anyone with any bright ideas on UI flow and layout here, please shout.

There would be obvious fallout from the above approach, the first of those being rah_flat and cnk_versioning which would need to add an extra tier, either as a folder or as theme.page.name.txp when storing offline copies. But aside from that, and maybe storing any theme-specific settings (I can’t think of any offhand but there’ll probably be some), it shouldn’t pose too many problems. Behind the scenes we’d expose the theme name to things like the (badly named) <txp:page_url> tag. And maybe add a <txp:if_theme> tag. Simple to implement, not sure if it’s useful.

The existing Presentation admin panels themselves need to just have the theme-specific stuff added to them, primarily the dropdown to switch theme, and the multi-edit / save operations to be cognisant of the theme so it doesn’t clobber files of the same name in other themes. Easy enough to do.

When using the Duplicate feature, I envision the copy being placed in the same theme as the one currently selected, unless you use theme.page_name notation as the new name prior to hitting Duplicate. Since dots are disallowed in Page/Form/Stylesheet names, it’s as good an indicator as any that you want to duplicate the sheet into a different theme, assuming the designated name doesn’t already exist in the target theme.

I think copying and pasting template files between themes using drag n’ drop or some other mechanism might be something we leave to plugins as it’s not conducive to the workflow outlined above. But if anyone has any thoughts on how this might be achieved in core (if indeed it’s desirable: I’m on the fence) then please speak up.

As far as I’m aware, all prefs are theme-agnostic so we’re covered there.

I think that just about covers it. Anything I’ve missed? Anything to add? Further thoughts? Corrections? Caveats? Improvements?

The floor is yours.

[Edited for clarity]

Last edited by Bloke (2015-06-18 09:53:59)

bici · 2015-06-17 20:26:49

a brief response. Themes are long overdue. and i mean simple themes that can be customized if one wants is something that is sorely lacking in the Textpatttern ecosystem. just look what is available for WP. Both paid and non-paid are most welcome.

PS I bought a TXP theme a few years back that was a nightmare to try and customize. in fact i was never able to . The basic technical and system part was well done…. but forget trying to adjust colors images etc …/.

Bloke · 2015-06-17 20:46:39

bici wrote #291617:

i mean simple themes that can be customized if one wants is something that is sorely lacking in the Textpatttern ecosystem.

OK, that’s not exactly what I had in mind with the above, but I can see how that has appeal. What I’m talking about is the ability to have several “designs” alongside one another in Textpattern that you can flip between while developing. So you can just grab a theme package, install it and preview it without affecting your existing site templates. Or load one and start from scratch. Since Textpattern currently leans towards being a designer’s tool, editing the theme templates by hand is kind of what I expected.

What you seem to be wishing is some kind of GUI experience that sits atop a theme (or comes packaged with it) where you can adjust some colour sliders, swap out theme background pics and so forth, without having to do much (any?) actual CSS or markup changes by hand?

That kind of thing is going to be down to the theme author or maybe a plugin. One option for CSS is to, I dunno, write colour info to a SASS file as a variable / mixin and compile it when you Save to generate the CSS. Not beyond the realms of possibility. But since things like Stylesheets and template tags vary so wildly, unless a convention is adopted and stuck to, this’ll probably always be the realm of per-theme customisation.

Now, I do have a plugin in development which might help if a plugin author hooks a theme into it, which allows variables to be set up in advance that are used in the theme. The values are made available in the Prefs panel for people to edit. Whatever customisations the theme author wishes to expose can be put here, so that might go some way towards helping realise something like you describe.

bici · 2015-06-17 22:12:33

Yes sorry i did misunderstand your post. But I do like what you propose.

I also think that the best way for Textpattern to gain traction is to have Themes with which a user can quickly get a site/.blog up.

johnstephens · 2015-06-17 22:15:27

Anything I’ve missed?

I don’t use Textpattern to manage external JavaScript files, but JS is integral to my Web design workflow. I can’t imagine how it could work to have Txp import JS from theme files, though. Possibly write to a directory specified by the theme? Simply add a line to the theme’s README directing people to copy certain JS files to a path relative to the document root?

Up to now, I have always used cnk_versioning, and I can’t see myself using Txp themes unless it included a feature like cnk_versioning that automatically imported theme files from text files based on production status. But if themes went into production, I can imagine them being distributed on Github and possibly via Bower—in which case, being able to clone a theme’s source and have Textpattern read it automatically (like cnk_versioning or rah_flat) would seem essential.

Bloke · 2015-06-17 23:01:55

johnstephens wrote #291621:

I can’t imagine how it could work to have Txp import JS from theme files, though.

Ah yes, forgot to mention those, thanks for the reminder. I’ve edited the OP to include them in the list.

I had envisaged managing things like we do with admin side themes: have a dedicated (web-accessible) themes directory (let’s say /themes for argument’s sake) and in there are directories, each named as per the theme it represents. Inside that go theme-specific directories to which the templates refer, images, js, and so on. It’s up to the theme author to stuff such additional content in there and link to it in the theme.

When it comes time to export, anything in the /themes folder bearing the name of the theme in question is zipped up with the Pages, Forms, Stylesheets and plugins from the database. That will make a single zip file that’s easy to install on someone else’s system without clashes (especially if themes are prefixed with the ubiquitous three-letters). So the zip will have a structure such as this:

abc_theme
--> images
----> background.jpg
--> js
----> jquery.megawidget.js
--> css
----> default.css
--> pages
----> default.txp
----> error_default.txp
--> forms
----> article.default.txp
----> misc.page_head.txp
----> misc.footer.txp
--> plugins
----> smd_wrap_v0.11.txt
----> pax_grep_v0.3.txt

An .htaccess file could prevent access to .txp files, leaving everything else fair game. But I’ll take advice on whether it’s better to have two directories: one web-accessible, one not for the respective content.

I can’t see myself using Txp themes unless it included a feature like cnk_versioning that automatically imported theme files from text files based on production status.

I consider cnk_versioning or rah_flat as things that a site admin chooses to install on top of everything else. Such plugins are not “in” a theme, i.e. not associated with one, so they persist no matter what happens to the site themes around them. That gives you the flexibility to work either in the DB or file system, or a bit of both

When importing a theme using the admin-side ‘import’ link, it would unpack the above zip file and any Pages, Forms, Stylesheets and Plugins get inserted in the database as needed. The remainder go in the filesystem as assets. But since the zip file structure is conducive to a versioning environment (its structure heavily borrowed from the best bits of the pioneering work of mcw_templates, hcg_templates, cnk_versioning and rah_flat), there’s nothing to stop you unpacking it lock stock into the filesystem if that’s your bag. From there, your favourite workflow plugin can pick the files up and sync them with the DB depending on production status, as normal for you.

If you work predominantly in the filesystem, it also means you can just zip up the entire theme folder and distribute it that way if you prefer. Nobody will be any wiser which method you used to create the zip file. Crucially, people who like the theme but prefer to use the DB can still install it using the ‘import’ mechanism and everything will continue to work no matter which workflow method you choose.

Defining the convention of the file system structure will be a big step towards all this. Each plugin / versioning system does it slightly differently but if there’s a core-sanctioned folder structure and the entire themes system is just a glorified interface for reading/writing zip files, versioning plugins can tweak their setup to use the official folder structure and we get the best of all worlds. I hope.

I can imagine them being distributed on Github and possibly via Bower

Absolutely. Why not. Never used Bower (shame on me) so there might be something in there we can leverage to help. Any nuggets of wisdom you can offer to teach this old dog new tricks would be most welcome.

Bloke · 2015-06-17 23:10:15

bici wrote #291620:

the best way for Textpattern to gain traction is to have Themes with which a user can quickly get a site/.blog up.

Sure. If we can cater to that with a simple-to-install distributable system (as outlined in my above post from johnstephens’ points) and the theme is packaged with my theme-prefs plugin, then installing, enabling and tweaking a theme are a few clicks away.

colak · 2015-06-18 03:28:24

Bloke wrote #291616:

By adding a new Admin panel, Presentation->Themes with a usual tabular layout like the Sections panel, new Themes can be created ready to assign stuff to. A simple DB table can hold the name, title, and any theme-related options we desire. If only one theme is present (as in the default case after installation/upgrade) then the rest of the UI remains essentially unchanged: you work on “the site” and you’re good to go.

If we could use rvm_privileged plugin with that, we have a winner.

NicolasGraph · 2015-06-18 06:56:22

Bloke wrote #291616:

Spawned from a thread about paid themes, let’s stop messing about and look at themes in Textpattern seriously. I realise I may be covering old ground here, but for completeness I’m going to lay it all out.

Good to hear! I’m trying find a way to package a theme and make it easy to install and custumize but it’s when I describe the install process I tell me that it should be easier…

I like the way it moves and your approach seems to be good to me.

Ostensibly, a theme in Textpattern is a collection of:

Pages

Forms

Stylesheets

Plugins

Textpack
Images (?)

Would it be loaded too?

Before going too much further, I’ll mention plugins. These should be handled differently, imo. Whereas a Page, Form or Stylesheet would have its own copy (i.e. not shared among themes), you don’t really want to be installing plugins more than once.

Wouldn’t it be possible to have the same theme structure than the pages and forms. I mean that the Plugin tab loads and plays just with the current theme plugins (with the good version) based on the theme choice in the Presentation tab? Of course the plugin tab should remember the user that he is watching the current theme plugins/versions.

What you seem to be wishing is some kind of GUI experience that sits atop a theme (or comes packaged with it) where you can adjust some colour sliders, swap out theme background pics and so forth, without having to do much (any?) actual CSS or markup changes by hand?

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.

Beside that, regarding to this:

I dunno, write colour info to a SASS file as a variable / mixin and compile it when you Save to generate the CSS.

I thought to use txp:variables in styles (with one of your plugin Stef) to allow a user to choose a color, but there is probably a better way to do because it slows the css loading isn’t it? Do you know if it is possible to use rvm_css (I usually use static sheets) with txp:tags in styles?
Using SASS is the better way but it’s not the easiest for beginners who are those who would like to use themes? Am I wrong? Is there a plugin which allows SASS in txp styles (it would be crazy)?

Edit: 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.

Edited for to package ideas and replies…

Last edited by NicolasGraph (2015-06-18 09:03:13)

Bloke · 2015-06-18 08:15:05

colak wrote #291624:

If we could use rvm_privileged plugin with that, we have a winner.

Not sure I follow. rvm_privileged is a public plugin, you can use it in any theme you like for restricting access to content.

The privs to control access to the Presentation->Themes panel would take the usual approach of being defined in admin_config.php (and thus overridable via smd_user_manager or bot_privs). Have I missed your point?

sacripant · 2015-06-18 08:35:34

Bloke wrote #291616:

Ostensibly, a theme in Textpattern is a collection of:

Pages

Forms

Stylesheets

Plugins

It depends, that’s your definition
But if you really want to offer specialized and professional theme, your proposal seems too low.

For example if I wish to propose an e-commerce theme with a best UX (front and back). My Theme must contain :

Pages
Forms
CSS
JS
Plugins
- Some plugins configurations (bwt_customize configutation, adi_notes with some existing notes, smd_tabber with configured tabs, etc.)
Custom fields configurations (actually it’s preferencies)
Some site preferencies configurations (use Textile, use comments or not, some publish options, etc.)
Specifique Admin theme
Some textpack files
Some articles already installed

For me, the biggest challenge is how to add plugins configurations and custom fileds configurations. Plugins are différents configurations possibilities : a specifique table in BDD, some specifiques preferencies in prefs table, directely in plugin PHP file. And for custom field configuration, I don’t now, it depends on the work on Txp 4.6.

If you want create a true theme market possibilitie for Textpattern, a theme must be a complete application for specific targets. If not the only themes that could be distributed are simple blogs! And Textpattern will continue to be considered as a old blog system only.

colak · 2015-06-18 08:59:28

Bloke wrote #291631:

Not sure I follow. rvm_privileged is a public plugin, you can use it in any theme you like for restricting access to content.

The privs to control access to the Presentation->Themes panel would take the usual approach of being defined in admin_config.php (and thus overridable via smd_user_manager or bot_privs). Have I missed your point?

Hi Stef, I might be getting all this wrongly and for that I apologise. How I thought the rvm plugin could work is on site design changes. A scenario is that the site designer could work on a new theme for the site which could – during its development time – only be visible to the admins and only when it finishes, the theme could be made available in the front end. It would be a great help if all content could be previewed with this plugin as it would position the plugin in very real situations. It would be great of course if you can think of another way which does away with the rvm plugin and offers full previews to the populated with existing articles themes.

Textpattern CMS

Textpattern CMS support forum

#1 2015-06-17 19:37:40