Textpattern is all about crafting websites with loving attention to detail, usually from the ground up or basing sites on the excellent, fully commented default template that ships with it.

For newcomers, after the power of tags has been grasped vs having to learn to code first, most people never look back. And rightly so: it’s a phenomenally powerful platform. But Textpattern’s greatest strength—a clean palette upon which to build—has traditionally kept people who are not already designers away. It’s never been a truly ‘plug & play’ experience.

That’s no longer the case from Textpattern CMS 4.7.0 onwards. But before getting into what Themes are, here’s a brief bit of background into our approach and how it compares to other CMS tools.

When is a template not a template?

One of the main draws of a tool such as WordPress has always been about taking something that someone else has done and putting your content inside it, then using that to build your site upon. If you decide you don’t like the look, swap it out for one you do like. There are endless templates—free and paid—that can be used, with varying degrees of success depending on the template author.

Textpattern has always shied away from this. Partly this is due to its architecture; the very thing that makes it simple and elegant—a Section containing Articles has a Page and a Stylesheet associated with it—makes it easy to iterate or swap out page furniture on a Section-by-Section basis, but it’s very difficult to try something new alongside.

Most of the arguments that have raged for over a decade against our lack of themes tend to come back to a few central concepts:

• Themes in other systems ship with plugins: what about compatibility with the existing site?
• What about Preferences? Themes sometimes need to set these for operability.
• Why can’t we run sites from the filesystem?
• Why do we have ‘essential’ furniture like default and comments Forms?
• If we import a Theme, people’s Sections and content will be overwritten.

Prior attempts at tackling this system fell by the wayside because they tried to take it all into account, and Textpattern is simply not architecturally geared up for this. So what’s changed? Why have we now succeeded where we once failed?

Back to basics: what is a Theme?

Simply put, we took a step back. Spurred on by Bert Garcia, one of the major proponents of themes, and author of the ‘hcg_themes’ plugin that has been the mainstay of many people’s sites over the years, we took a look at what a Theme actually is and, more importantly, what it isn’t.

Our current definition of a Theme is:

• Pages
• Forms
• Stylesheets

Nothing more, nothing less. No plugins, no Sections, no content, no preferences. Just the bare template furniture. In future, we plan to expand this and introduce such additional items. For the impatient, we’ve built some fantastic goodies under the hood for plugin authors to play with that will allow fully-fledged theme plugins to be created with all of the above features. More on that later.

So if a Theme is nothing more than a few bits of scaffolding, why the fanfare? Why the big deal?

Template furniture can coexist

The main problem to date has been that if you want to migrate a site to a new layout or design, you have two choices:

1. Do it live, make up fake Sections and content to test it (with all the risks that entails) then migrate Sections to the new design.
2. Do it all on a staging site, get it working then upload everything and figure out how to sync the database content that has drifted since the redesign began.

Our approach in Textpattern CMS 4.7.0 has been to lean towards the former while removing as many of the risks and hacks associated with it. Given the choice, most people who want to migrate to a new site ‘skin’ would prefer to do it in a safe, parallel area without having to faff with database resynchronisation or setting up entirely new (sub)domains and site environments.

With that in mind, upon upgrade to the above mentioned version, you’ll notice, well, very little difference save for the introduction of a new Presentation panel labelled, unsurprisingly, Themes. First-time installers will be given the choice of the default theme or an ‘empty’ theme (or at least as empty as Textpattern knows how!) during the setup process.

Visiting the Themes panel will show you one theme (default) and that’s your current site. Not ours. Not anyone else’s. It’s your current site. If you’re happy with that, great. Call it Donald Swain if you like, it’s up to you. Nothing else will change on the Pages, Forms and Styles panels, it’s business as usual.

The fun starts if you create a new Theme or duplicate your existing one. A new selector then appears above the asset lists on the Pages, Forms and Styles panels, allowing you to switch Theme. As soon as you do that, you are editing all assets for the chosen Theme and the one you are working on is remembered from panel to panel.

One important feature is that, all the while you are editing assets in a Theme that is not in use by your site, nothing on your current public-facing site is affected. You can tinker away on your new design and change Pages, Forms and Styles to your heart’s content, directly in your live Textpattern installation, without any ill effect on your existing site. As long as you don’t start altering plugins or changing prefs that affect the entire site, nobody is any wiser.

It’d be no good working away in the dark, so Textpattern now has one more trick up its digital sleeve. If you are editing any Theme, you—and only you—can preview what that Theme looks like by viewing the public site as normal. Whichever Theme you are editing temporarily overrides the real Theme in use across the entire site. Regular users who are not logged into the admin side continue to see the site as it was.

The huge productivity benefit here is that all your content is still in place. No need to mess with synchronising data to other installations to get the latest article content; you get to see what your site will ultimately look like, directly on the live installation. Even better, you can give clients a preview too. You could make a series of parallel Themes and grant your client appropriate user privileges. They can then switch between Themes from the admin side and refresh the public site to see what each looks like in-situ. Very handy.

Making a Theme live

So far so good. You can copy, edit, and preview your Themes with live data in an isolated environment that has no effect on your user base. When the moment arrives that you want to showcase the new design to the world at large, it’s as simple as visiting the Sections panel. You can either click a Section as normal to edit it, select a Theme, Page and Stylesheet for that section and hit Save. It’s then live. Or use the multi-edit tool to apply a Theme, Page and Stylesheet to all the selected Sections.

This approach has one other exceptional benefit: you don’t need to apply the Theme to your entire site. Want the blog to look different? Just assign a different Theme to that Section. Want your gallery showcase to be a bit snazzier? Use a different Theme just for the affected Section(s). Textpattern will show you which Theme is in use for each Section and show you the number of assets in use by each. It’s like using a bunch of Pages for different parts of your site, but they’re entirely independent of one another.

You won’t be able to accidentally delete a Theme that’s in use, so no fears there. On the Sections panel, if you click the number representing the assets of that type, it’ll transport you straight to the corresponding Pages, Forms or Styles panel and switch you to the assigned Theme so you can edit the presentational aspects of it immediately.

Sharing Themes

That’s not all. The final piece of great news is that you can package up any Theme and export it to the file system. Each Page, Form and Stylesheet in the Theme occupies its own space under the themes directory. This has two benefits:

1. It allows you to export your theme and edit it under version control, then reimport it.
2. You can import any theme by dropping it into the themes directory in its entirety, then visit the Themes panel to import it. Whether that’s your own creation or someone else’s is immaterial.

Anyone who’s used rah_flat or oui_flat will instantly see how useful this is to have in core. And, in fact, most of the Theme import/export code has been written by Nicolas Morand of oui_flat fame so you can be sure it’s based on the considerable experience gained through maintaining his excellent plugin.

The main differences are that we’ve deliberately taken two features of the plugin out. Firstly, the ability to import preferences is not there. Secondly, the auto-synchronisation-when-Live aspect is removed: if you want to import a theme into Textpattern, you must manually do so from the Themes panel.

This workflow aids clarity and minimises the chance of overwriting your templates. Textpattern does not serve its Themes from the filesystem; they continue to be served from the database only. The ability to export and import is merely a convenience feature for version control, backup or sharing of Theme content. The furthest Textpattern goes is offering you the option to clean out any unused assets prior to import/export, which will remove all assets and use a completely fresh set instead of merging the content.

Plugins have full access

While the ability to manage Themes and their assets is pretty cool, on its own these features would be very limiting. So we’ve let plugins not only have access to the full set of import/export actions, enabling plugin authors to augment the concept of Theme building, but also bundled some excellent additions in the background.

In our vendors namespace, plugin authors will find a virtually complete system for import of XML files. You can define XML files for Article content, Categories, Sections, Pages, Forms, Styles, Preferences, Links, Comments, even database table definitions. Methods allow content be pulled into the database from flat files. In fact, core now uses this system during setup and upgrade.

This library enables plugins to natively and easily handle content import. Should anybody wish to do so, it’s now possible to write a plugin that replaces the entire ‘import data from another CMS’ that was ditched in the last version. And, in fact, make it a hundred times better than the creaking importer we sliced out of core.

The only reason we’re not shouting about this library just yet is that the work isn’t complete. We need to possibly figure out file and image imports, and write a companion export library, unifying all the Theme code so it uses the import/export library instead of its own. We’re looking into that for the next version so keep your ear to the ground.

Future expansion of Themes

For now, our concept of a Theme will remain strictly Pages, Forms and Styles. For future, who knows, we might extend the concept to include prefs and plugins or Sections, although these all bring their own challenges and require a ‘wizard’ approach, since importing such content has the potential to overwrite existing data.

We intend to consider—and please note, this is only a tentative idea that may never see the light of day—the following:

• Themes Pages, Forms and Stylesheets.
• Templates the above, plus Sections, Plugins and maybe Preferences.
• Packages all the above, plus site content.

We’ll likely still use the themes directory but choosing to export would ask you which components you wish to bundle up, and choosing to import would ask you which parts you wish to bring in and potentially overwrite.

All in all, we’re really excited to finally bring the ability to manage Themes to Textpattern. We hope it’s a useful feature that spurs a load of shared Themes—we will endeavour to host anything people create so the community can benefit and expand—and allows you to maintain and push your existing sites forward with less hassle than now. Anyone who can’t wait for v4.7.0 to hit the shelves can either download the latest snapshot from GitHub or give the development version of the demo a whirl.