Hi,

Please correct me if I'm wrong, but I always thought that theme support is an ability of an application to represent the same data/content using different visual models.

Currently with OctoberCMS it is not the case: all pages, content, and components are stored inside the themes/ directory. As far as I understand all mentioned objects are not part of "theme", so it's a wrong place to store them. To make it a bit more clear I'll explain it by an example:

Imagine that I've created a nice looking website with hundreds of pages. Now, the Xmas time is approaching and I want to temporarily switch the an Xmas theme. With the current approach at OctoberCMS it would mean one of two things:

1. You either need to copy the whole theme directory and modify it to make your "Xmas" one;
2. or you need to tweak your existing theme.

If you go with option 1, you will duplicate all your content and will need to develop a strategy on how to merge content changes made during the Xmas period back to the regular theme once the holiday period is over. I'm not even starting to discuss option 2 since it's plainly wrong thing to do.

What would be really great is to unbind Pages, Content, and Components from themes and have a configuration setting to specify the location of these objects -- then all themes will be able to re-use the same content.

WDYT?

Actually, what would be really perfect is to have two levels of objects: global and theme.

In other words, there should be global Pages, Partials, Layouts, Content, Assets, and Components. Then a theme should be able to "overlay and extend" these by providing its own versions if required. This way it would become quite flexible and powerful and you will be able to provide users of your website with a theme switch option :).

This is quite a good idea - I like the "Global" + "Local" aspect within themes, that makes good sense. Might be worth posting this as a "Question" or "Feature Request" over on GitHub as you'll get a quicker response from the Devs on there.

Last updated 10 years ago

In October a "Theme" represents the entire front-end structure of a website. Not to be confused with a "Skin" that would represent the look-and-feel only (stylesheet swap). A theme can potentially have multiple skins as a feature. Other systems use the terms in a different context, perhaps less accurately.

The concept of Theme inheritance can be considered "Child" and "Parent" themes.

Still, the proposal is to define some kind of a "global" theme that provides the fallback resources for any other theme assigned to the frontend. This will provide a lot of flexibility in design matters and also will make it possible to switch from one theme to another if such a desire is expressed.

As I see it, the backend interface will have a horizontal split. Pages, Partials, Layouts, Content, Assets, and Components above the split will be the "global" ones, the split line itself could be made as a drop down box of the activated themes, so when you chose one Pages, partials, Layouts, Content, Assets, and Components of that theme will be listed below the split line.

This will also allow to use themes for skinning by the way :).

@daftpunk, also i wanted to explicitly mention that I fully understand your point re: "theme represents the structure of the website", however, I think this is a limiting feature and could be a bit expanded to make it appealing to a broader audience with the changes I proposed. This will cover both sides: who prefer to consider a theme as a representation of the whole website structure will assign/use the global theme, others who need some flexibility (e.g. during Xmas I want some specific functionality from the front end and that functionality is only needed during that time) will be able to have "a theme for an event" approach :).

I agree that this is a good idea to have a 'global' / 'local' separation.

I see this as a separation of a content itself from the design. Layouts and partials seam to be more related to design (the 'look and feel), Pages and Contents are the meat (the content) and Assets are somewhere in the middle, as some of them can be global (e.g. article images) or local (design elements).