Making the installation of front-of-site themes easier

thebombsite · 2010-02-09 16:58:16

I am currently in the position of having to port a large number of WordPress themes to Textpattern. Robert was aware of this and asked me to supply any suggestions I might come up with to make installing these themes a more simple task than it currently is. So here goes.

First let me say that I am not looking for some kind of “one-click” installation process vis-a-vis WordPress. Textpattern isn’t built that way, nor should it be. It would become less flexible if it were. None-the-less there are some simple (in my opinion) things that could be done right now to alleviate installation headaches.

The first problem everyone faces with installing a theme is copy/pasting all the page, form and CSS templates into the appropriate tabs. This can be a right pain in the arse particularly if there are a lot of them. Not only is it time consuming but errors can occur during both copy/pasting AND naming. We already have a plugin, hcg_templates, that can both export and import these templates with a couple of “clicks”. I would suggest that this plugin become a part of the base code. It should still have it’s own “Extensions” tab and a new folder, _templates, should be added to the root as part of the Textpattern installation process.

My second point comes from my firm belief that design images do not belong in the “Images” tab. The current “Images” tab is contained within the “content” area of the admin navigation. Design images are not content. Somewhat related to this are design files. By that I mean stuff like js files required to run something, maybe audio, video, or something specially built like the slider on the frontpage of the textpattern.com site. Now I am well aware that these could be uploaded to the “Files” tab and linked to from there but that would also be incorrect usage for the same reason ie. they are not content, they are design. For my own part I would place these in their own folder anyway. Now I suspect you think that I’m going to suggest that image and file tabs be added to the presentation navigation but I’m not. That would pose it’s own problems from a theme installation point-of-view relating to id numbers for images assuming that the same mechanics as are currently being used were applied to the new tab/folder. How the heck is a theme CSS going to know which id has been applied to a particular image? The theme designer has no control over what order a theme’s images get uploaded, nor does he/she know how many images may already be in there. Bit of a dilemma isn’t it?

Well actually, no it isn’t.

My suggestion is the addition of a second folder to the root which we could call something like “site-design”. Within site-design there would be sub-folders, one for each theme. Each sub-folder would contain all the necessary images, js files and CSS for that theme. Indeed there might well be sub-sub-folders for the js files, for additional CSS files (not the base CSS which I will come to later) such as css-reset.css, ie6.css and ie7.css etc. The base CSS file would reside in the main theme folder with the images. Now all this organisation is down to the theme designer to set up, it’s not something for Textpattern to do. I would only expect Textpattern to include the “site-design” folder during installation plus it’s own sub-folder for the default theme.

Now that was a lot of text which has probably confused you all so here’s what I think a textpattern installation should look like:-

_templates (new) (for exporting/importing page, form and CSS templates)
files (existing)
images (existing)
rpc (existing)
sites (existing)
site-design (new)
     classic (new) (folder for the default theme which would contain the 3 images used plus the base CSS)
     falling-away (new) (folder for the Falling Away theme which would include all theme images plus the base CSS)
          css (optional) (folder for additional CSS such as css-reset, ie6 and ie7 etc.)
          js (optional) (folder for javascript files used in the Falling Away theme)
          styles (optional) (folder for additional colour variations of the theme if there are any and there would probably be sub-folders in here too.)
textpattern (existing)

Note that the current default theme (I have called it “classic” above) would get it’s own sub-folder. This would remove the need to include it’s images in the “Images” tab. They don’t belong there. Also it’s base CSS should be in there which leads me to my next suggestion.

Ruud’s rvm_css should be included in the base code. I know this has been asked for before (also hcg_templates) but it hasn’t happened yet. This plugin adds a new option in “Preferences” to set the folder that the static CSS files are saved to. I would suggest that this be a select box displaying the first-level sub-folders of the “site-design” folder. I don’t know if there is any way to automatically detect which theme is currently being used?? With this code in the base the main CSS files for a theme could reside in it’s main folder alongside any theme images. That would remove the need to specify a path to the images in the CSS. All you would need are the image names. Keep it simple say I.

My last suggestion doesn’t really make theme installation easier but I think it is related. When you install Textpattern for the first time your natural instinct is to get it styled, not that I have any problem with the default them but it is a little basic isn’t it? (No I don’t want it changed.) Of course whilst all this restyling is going on your site looks a bit of a mess plus, if it is a new site, you don’t have any content. The last thing you really want at this point is visitors including Google. I would therefore suggest that Ruud’s rvm_maintenance become part of the base code. An option for on/off could be added to “Preferences”. With this in place, no sooner you install Textpattern you could pop it into maintenance mode with a single click (make that 2) allowing you to get on with the messy design stuff in peace. ;)

Well there you go. I may come up with other stuff which I shall post here. (I think this may be my longest post ever.)

Please discuss.

Last edited by thebombsite (2010-02-09 17:21:58)

MattD · 2010-02-09 18:18:08

I have had great success with hcg_templates and I include js and images in the template directory.

_templates
    mytemplate
      img
      js
      forms
      pages
      styles

stephan · 2010-02-15 13:43:33

Have you checked mem_templates¹? It’s pretty much like hcg_templates but also supports the ex- and import of plug-ins.

¹ http://manfre.net/project/905/mem_templates

thebombsite · 2010-02-15 15:45:11

Thanks for that Stefan. Didn’t even know that existed. :(

I shall give it a whirl.

I should say that I am also finding a very good use for a modified version of Adi’s adi_variables plugin though it needs to be modified for each theme. Doesn’t take long though and gives users a simple way of personalising the themes once they are installed. Really must talk to Adi about this.

MattD · 2010-03-03 21:04:38

I also use adi_variables for theme specific “settings”.

thebombsite · 2010-03-04 17:21:22

I have just uploaded the Bueno theme (http://textgarden.org/layouts/232/bueno) to Textgarden which is constructed in the manner I intend to pursue for the future. I would be grateful for any feedback on the methods employed. Whether you like the theme or not is secondary but please don’t hold back on my account. ;)

What I would like to happen is that we get a “standard” for theme construction which is followed by all designers. This is particularly relevant at this time in light of the future Textplates competition. Let’s get it sorted before that happens.

mapu · 2010-03-05 19:09:40

First of all, I love this theme and I like the way how the theme is administrated in the backend. And I’m grateful for every new theme that is available for TXP. Thanks for that!

However, I’d prefer the method suggested by MattD to put everything related to the theme inside a subfolder of the _templates folder. This way the root folder is staying clean and uncluttered and to explain wich folders and files to upload would be more easy (upload only the _templates folder). Also, this way one can upload more themes that could live peacefully inside the _templates folder each in its own subfolder.

thebombsite · 2010-03-05 20:27:58

Well I’m not really sure how useful that would be with Textpattern.

First of all the _templates folder is there specifically for the mem_templates plugin and I’m not sure how it would react to having foreign sub-folders in there. I’d have to experiment with that.

Also switching themes in Txp is no simple matter so I’m not sure what advantage might be gained by having several different themes uploaded. To my mind it would be simpler to just remove the extra site-design folder of a theme and replace it with a new one, swap the template/plugin sub-folders in the _templates folder and start again. I think with your method it could get quite messy quite quickly not to mention the space it would take up on the server.

Plus if the themes were in their own sub-folders you would have to find some method of telling the plugin which sub-folder it was hunting for so there would need to be some re-coding. I’m no PHP expert but I’m thinking this might be a little tricky.

Now I shall say something rather bold and I’m not trying to be disparaging in any way to the devs or this community, but I tend to think we have become too insular for our own good, or more importantly, Textpattern’s own good. A lot of the people that use Txp are designers, or coders and when we ask for things that we want in the software we tend to think from our own points-of-view. What we ask for or desire may be good for our small band of die-hards but is it any good for the rest of the planet? What I am trying to do here is create a method that can be followed by someone who is totally new to Txp and indeed those are precisely the people that I shall be doing this for from within WooThemes. The last thing I intend to do is put people off using Txp by making the theme installation process any harder than it needs to be nor make it seem “geeky”. We have to start avoiding “geeky” otherwise Txp will never become the force it deserves to be. That doesn’t mean I want any great changes to Txp. For those of us who are designers, coders or just Txp fanatics it is a great piece of software, indeed I think it is unrivalled, but we do need to start widening our horizons before we become a tiny island that people stop visiting.

Now there are some things I would like to see get into the base code, if for no other reason than it would stop me having to upload 3 or 4 plugins every time I do a new install.

First off, and this would be for the coders amongst you, I would like to see Mary’s upm_insert_tab plugin code added.

Second there would be Ruud’s rvm_css plugin code.

Third there would be Ruud’s rvm_maintenance plugin code.

These are all small-fry and wouldn’t add much weight to the base code but would certainly make life a little easier and sites a little quicker.

This post is getting too long for me. ;)

Last edited by thebombsite (2010-03-05 20:54:06)

stephan · 2010-03-05 20:40:08

Maybe Txp core needs a new folder for everything design. Images and Files should just contain content rather than site design and one dedicated folder would make absolute sense. If using rvm_css or any other design/theme any developer could always rely on a design folder being there.

Would that make a clean install a little bigger? Yes. Would it be a good choice semantically? Certainly. For now we mix design and content inside these folders. Maybe we should stop doing so. But wait, didn’t you suggest this in another thread before, Stuart?

thebombsite · 2010-03-05 20:58:31

Actually Stephan, it’s right at the top of this thread. :)

stephan · 2010-03-05 21:27:17

Damn, I am losing it ;-)

stephan · 2010-03-08 16:53:33

I took some time and thought about the installation of front-end themes because I tried several in the last couple of days using mcw_templates and mem_templates. Since I know there are so many people working on Txp who are way smarter than me I just figure I’ll throw in some thoughts and see what they stimulate ;-)

How do I install frontend themes today?

Here’s what the entire process of installing a theme looks if broken down into a couple of rather simple steps:

Get all the HTML snippets into place (create page templates, forms, css)
Get all the ressources into place (design images, javascripts, etc.)
Check if required plugins exist and if not install them
Check that all required sections exist and if not create them (if there are too many disable/delete them using a new property saying invisible), then assign the right page templates and CSS to all sections + default
Make sure settings for core and plugins are set correctly (date format, append comments automatically, specific plugin settings, …)
Check if special articles (like a single sticky about article in the about section) should exist and if not create them
Perform some (optional) kind of (self) test to make sure everything went smoothl

Now to a possible solution:

Meta talk comes first

Every theme should¹ contain a meta-file that gives you a very concise and machine-readable overview of the templates. This includes the name, version, used plug-ins, initial settings for plugins, used sections, specifics to sections and so forth. At first this will be a file that is manually created but later on maybe some kind of parser would be able to identify which modules (plugins, forms, pages, settings) need to be set.

The simple part

For 1 and 3 we could use the existing mechanism from mem_templates. It already works. However at the moment it is a little “dumb” as it doesn’t know which templates/plugins are actually needed.

should be easily dealt with by taking the textpattern/theme directory for backend themes as an example. Let’s add a dedicated themes directory to root as well – this would be for frontend themes:

/ (root)
/index.php
/textpattern
/theme
/theme/my_new_theme/
/theme/my_new_theme/images
/theme/my_new_theme/css
/theme/my_new_theme/js
/…

Sections

The fourth step will require you to set your sections accordingly. The meta file should contain the names and settings for all used sections. The installation routine for frontend themes should set them all up. Yes, it may mess up an existing section structure but in case you’re worried about this there are two solutions:

Make this step either automatic or manual so that during installation of a frontend theme the user can chose to manually adjust the sections
Back up the existing frontend theme including the sections structure just like mcw_templates already does it today

Adjust the settings

This may become tricky – I have no idea. But I know that there are some themes that ask the user to set comments to automatically be appended to an article or adjust the format for date and time. Also some plugins work only correctly when the right settings are applied.

Maybe there is already some core-API that allows the adjustment of settings, that would definitely make life easier for an easier theme importer. For plugins it may be nice to allow some kind of save state that preserves all settings of a plugin at the time it was exported.

Mess with the content

Now it gets tricky. Just as we needed to make (site breaking) changes to the sections a theme may rely on one special article in the about section and show its excerpt on the front page. The meta file should contain info which sections are actually used (already discussed this) and whether they

allow any number of entries
require a specific number of articles

As with the sections there should be a manual or automatic approach. If a user selects the automatic approach some pre-defined articles should be inserted (and of course be edited by the user, so actually this is semi-automatic).

Think of it as importing a branch of the (in txp not visible) content tree instead of manually needing to re-create it.

Does it work?

From a developers point of view the testing would be done in each step, but from the end user’s perspective at present I would also open pages from all sections just to make sure.

What needs to be done?

Alright, after so much text, what is actually needed to be done now?

Extend core so that a plugin may easily make adjustments to settings
Extend core so that sections may also be invisible – similar to drafts in articles
Extent the plugin API so that settings may be exported at will
Refactor mcw_templates/mem_templates so that it performs the above steps based on a master meta file

Feedback

So, does any of this sound reasonable?

¹ If you were to implement the outlined concept, the imperative is misleading :-)

Textpattern CMS

Textpattern CMS support forum

#1 2010-02-09 16:58:16

Making the installation of front-of-site themes easier

#2 2010-02-09 18:18:08

Re: Making the installation of front-of-site themes easier

#3 2010-02-15 13:43:33

Re: Making the installation of front-of-site themes easier

#4 2010-02-15 15:45:11

Re: Making the installation of front-of-site themes easier

#5 2010-03-03 21:04:38

Re: Making the installation of front-of-site themes easier

#6 2010-03-04 17:21:22

Re: Making the installation of front-of-site themes easier

#7 2010-03-05 19:09:40

Re: Making the installation of front-of-site themes easier

#8 2010-03-05 20:27:58

Re: Making the installation of front-of-site themes easier

#9 2010-03-05 20:40:08

Re: Making the installation of front-of-site themes easier

#10 2010-03-05 20:58:31

Re: Making the installation of front-of-site themes easier

#11 2010-03-05 21:27:17

Re: Making the installation of front-of-site themes easier

#12 2010-03-08 16:53:33

Re: Making the installation of front-of-site themes easier

Board footer