what is a theme?

maniqui · 2006-02-20 23:24:13

Hi all!
well, the question is in the subject… but I put it here and add a few more:

what is a theme?
what is a template?
what is the difference between a template and a theme?
and what is a theme engine?

Dont laugh of me! I have never completely understood those terms…
Sorry for this newbie question…

Maybe I should search at Google or Wikipedia… but I would like to read some answers from the TXP perspective…

PS: the forum grows, that’s always nice. Will this category have moderators? If yes, I would vote for thebombsite, thame, alexandra…

zem · 2006-02-20 23:31:45

The definition isn’t settled. Textpattern has no official “theme” concept.

Templates are more accurately “page templates” – i.e. textpattern > presentation > pages.

I think it’s fair to say that a theme ought to include more than a mere template: forms, images, CSS, etc.

By “theme engine” I mean, a Textpattern feature that knows how to install, uninstall and select themes, without requiring the user to copy and paste individual pages and so on.

Jeremie · 2006-02-21 00:51:55

I would define a theme as an all-in-one package. You take one package (one file), and from that after some TXP voodoo you’ll get an up-and-running website as intended by the theme’s creator.

Of course, the result can afterward be edited by the webmaster to better suits his needs.

So, in the TXP paradigm, a theme would be : sections_definitions + pages + forms + css + images. Maybe plugins, too.

A theme engine would be a tool, or a set of tools to :

create a theme file from an existing TXP install
install a theme with a simple click/button, maybe with compatibility check
switch from theme to theme

And some place, to browse themes, easy download them (directly from that place to our TXP install if needed), preview them, demo them, etc.

I belive several other software does all of this, we can inspire from. I know Dotclear does, but I’m guessing not so many here knows Dotclear. I’ve heard Drupal and Wordpress do that too, but I don’t know to what extent.

Last edited by Jeremie (2006-02-21 00:52:56)

zem · 2006-02-21 01:47:00

sections_definitions

I can forsee plenty of problems here, particularly when switching from theme to theme. I think it would be better to make it easy to create themes that are more or less independent of the site structure.

See the sticky post for a link to proposed requirements at Textbook.

Last edited by zem (2006-02-21 02:12:20)

Jeremie · 2006-02-21 02:51:26

I can see them too, but from the Textplate experience I can tell you there are other issues if sections are left out. The first one will be search and authors (in the /author/profile/ meaning) handling, you have tags and plugin that need section defined to customize it. However, these issues might be simpler (cons>pros). I’ll try to think about it, and sort it out.

Without the sections issue, the first big one I see is “component jailing”. Basically, we would need to attach each component (page, form, css, etc.) to a theme (I suppose that mean one more SQL column for these), so that a DTD Header form from theme B would not overwrite another DTD Header form from theme A on the same TXP install.

With this, the first question would be, can/do plugin have to be jailed? If so, is there is a mechanism to update all the copies of the same plugin at once? Wouldn’t that be too complex/ugly to do/handle?

The second, is how to copy a component from a theme to another. If I install theme A & B, how can I easily take the theme A’s CSS and the theme B’s form to integrate into a new theme C?

PS: can an admin/moderator edit the thread’s subject to something like “Exploring the Themes implementation issues” or whatever ?

Last edited by Jeremie (2006-02-21 02:57:46)

zem · 2006-02-21 04:47:23

I can see them too, but from the Textplate experience I can tell you there are other issues if sections are left out. The first one will be search and authors (in the /author/profile/ meaning) handling, you have tags and plugin that need section defined to customize it. However, these issues might be simpler (cons>pros). I’ll try to think about it, and sort it out.

These things can be solved independent of site structure by providing a way, other than section names, to create templates for and link to search/author/etc pages.

Alex McKee · 2006-02-22 02:25:27

I agree with zem. Keep structure totally away from themes. One of the reasons I love Textpattern is changing the site layout is easy insofar that the data and structure is completely abstracted to Textpattern.

However, a themes engine is definately a good idea. A theme should be a one-step installer of page templates, forms, any required plugins and css templates. Indeed, I think that a substantial review of the presentation section will be needed, maybe just making it the theme installer page and 2 subpages – one for CSS and one for Page Templates to allow for customisation and alteration.

Textpattern should come with a default theme, with a unique set of includes, css and html page templates. You then can modify each page. As with other open source systems it should be able to handle more than one theme being installed and they can be turned OFF and one can be turned ON at any given time.

I’m just thinking aloud here so forgive me.

zem · 2006-02-22 02:57:27

Textpattern should come with a default theme, with a unique set of includes, css and html page templates. You then can modify each page. As with other open source systems it should be able to handle more than one theme being installed and they can be turned OFF and one can be turned ON at any given time.

Definitely. Number one on my wish list is that there’s a button for switching back to the default, unmodified Textpattern theme. That way when something goes wrong, it’s trivially easy to distinguish between problems caused by a theme or user template, and bugs or other problem with Textpattern itself.

Alex McKee · 2006-02-22 03:41:39

That was what I was thinking. Plus it will make new theme creation a more pleasurable task (my textplate entry is still under construction lol) as you can, as you said above zem, switch back when having problems and debug.

placenamehere · 2006-02-22 04:12:05

I’m not convinced that site structure and theme can be separated without a good deal of additional conditionals to query the configuration and other site settings

As an exercise I’m working on an attempt to separate a “theme” as much as possible under the current system and I’m finding there are a few ugly spots:

to present section nav or not to section nav (or other static nav), what about files, or links
there are a few tags out there that need work (probably independent of themes) to better use default configs. I’ll file issues on all of these (one case i hit that i’ve has before was no way to get a feed link tag in the Page head that understood the pretty url setting.
need to manage preferences that the theme either (a) requires or (b) prefers. Things like comment popup mode, automatically append comments, present comments as numbered lists, all tie directly into the theme (or template). If there is no way to manage those preferences directly each case needs to have a way to modify via tag. Be careful of settings like “never display email” as well — a template can include text such as “don’t worry, we will never display your email”
Will there be cases of custom fields being important to a particlar theme? How can this be dealt with? (similar to the sections issues brought up, but I understand the arguments against tying sections into a theme (or switching sections based on theme)
image generation is a missing piece in the core config. without it any theme that uses logos or headers made from images will need to ship with PSDs or other files to get ma
The versioing issue has been already brought up. I’d worry that minimum txp version isn’t enough and you might want to consider carrying another theme version (or theme API version) so you don’t get the opposite issue of plugins breaking when trying to install on txp5.0 (see firefox)
there is also a big question as to how to deal with plugins. I can definitly see a desire out there to accomidate themes that “must have” particular plugins to work properly. How can that definition be setup, and how can that be packaged?

Things that I have an easy time of doing in a theme setting are the things commonly done in Pages or forms now, but themes will need to make up for that missing step that happens while editing Pages of adding or subtracting desired features from that base templates that admins normally do manually when they decide what features they’d like.

Now, I’m not expecting a theme never to be altered by the txp admin (plugins are a big case where its needed because I can’t code a theme for every contingency, having 50 sections can’t be expected, etc.), but I do think, along with it being self contained it should also be fully functional out of the box under most usage scenarios.

Jeremie · 2006-02-22 09:02:28

I do understand Zem point’s of view, and I’m agreeing more and more with it. But Placenamehere (argh, that name…) had explained several issues more in depth that I had.

One very crude example : how to code a main navigation using section (as most people do) without knowing the sections? You’ll need a tag to display the section title and URL with custom ordering and filtering capability, and possibility a lot of testing and if/ifnot. Core TXP is nowhere near offering that, and I don’t know any plugin doing that “in the void” (without knowing anything on the sections already set).

On the plugin matter, I think there are some way to deal with it. When someone build/export a theme, he could be asked what plugin on his install are needed (list of all of them with checkbox), and then an xml file generated and integrated within the theme with the plugins needed and their minimal version number, and the coded versions of those plugins. When one would install the theme, the theme engine should check the plugins installed, warn if some are missing, but offer bth the choice of “forcing install” without installing the plugins, or install/update the plugins from the theme pack.

thebombsite · 2006-02-22 13:32:00

One thing that hasn’t been mentioned yet is the inclusion in a theme download of a decent set of installation instructions. I’ve done a few of these and I think I’ve got them about right now. :)

I mention this because this is where “sections” and “plug-ins” are dealt with. If some form of “theme package” is going to be included in TXP in the future I see no reason why this should restrict theme designs from the point of view of sections and plug-ins. A separate folder containing the appropriate plug-ins can be included in the theme download. The installation instructions would describe how to install and activate them as well as describing how to create a section, what sections are needed and how to adjust the option settings.

Indeed the installation instructions can deal with anything that isn’t dealt with by the TXP auto-pilot including things such as “custom fields”, “auto append” on or off, are we using “pop-up” comments etc.

Textpattern CMS

Textpattern CMS support forum

#1 2006-02-20 23:24:13

what is a theme?

#2 2006-02-20 23:31:45

Re: what is a theme?

#3 2006-02-21 00:51:55

Re: what is a theme?

#4 2006-02-21 01:47:00

Re: what is a theme?

#5 2006-02-21 02:51:26

Re: what is a theme?

#6 2006-02-21 04:47:23

Re: what is a theme?

#7 2006-02-22 02:25:27

Re: what is a theme?

#8 2006-02-22 02:57:27

Re: what is a theme?

#9 2006-02-22 03:41:39

Re: what is a theme?

#10 2006-02-22 04:12:05

Re: what is a theme?

#11 2006-02-22 09:02:28

Re: what is a theme?

#12 2006-02-22 13:32:00

Re: what is a theme?

Board footer