Critical remark about the theme module in Contao 2.9

Hi all,

First of all Contao is very great CMS and framework. I like it because as a developer I can easily develop new modules and new functionality. As a designer I like it because the basics are done and the only thing I have to do is to style the different columns.

However, I am using Contao 2.9 and the new theme module has one big disadvantage which is the ability to export and import theme's. Actually this is not too bad at all. But when I am using modules in a theme, lets say a login form which redirects to a particular page and when I am exporting this theme, the module gets exported. And when importing this theme on another site, the redirect page is not correct.

Pragmatically this means that layout and content are mixed. It would be nice that the theme module really makes themes and that there is a content module where additional content could be added and linked with the theme.

I am wondering how you think about the theme module in Contao... And I would like to develop a new way of handling theme's. However this requires changes in the core and I am willing to do this but before I would appreciate your ideas and also I would like to know if I am going to develop this, if it would be merged with a new Contao version somewhere in the future.

Thanks,
Jaap Jansma

Hereby my thoughts for a new setup for layout and themes.

Regquirements

• Layout/Templates must be separated from content (e.g. modules)[/*:m:2l4u6etg]
• The generated (x)html should be semantic correct (however this is the responsibility of the Theme Developer)[/*:m:2l4u6etg]
• A separate theme directory. Which holds the templates (if necessary), the images and the css of that theme[/*:m:2l4u6etg]
• Based on the User Agent and probably other factors, a different template or different content could be shown. So that it would be easy to define a layout for a pc (full content, big images) and for e.g. a mobile device (small content). [/*:m:2l4u6etg]
• Also it should be easy to integrate ajax in a theme. So that an ajax call could be made to the theme module to retrieve content[/*:m:2l4u6etg]
• The framework for a basic template based on header, footer, right, left as it is now, should stay intact, so that it will be easy to make a new theme based on common used sections.[/*:m:2l4u6etg]
• Settings which should be defined per site. This could be the basics, such as additional headers, additional footer content (e.g. to include google analytics etc)[/*:m:2l4u6etg]

content sections
At this time you add content to a theme, to create a layout and link modules or articles to a section, e.g. right, header, footer etc. I want to call this content sections. And the theme developer defines a certain amount of content sections, which could be right, header etc. But also more semantic, branding, navigation, site-information, main-content, sub-content etc. To add content to a theme, the content should be defined in content sections where it is easy to link the modules against the content sections.

Hi Jaap-

I guess I'm a little confused as to what you are trying to do. The themes feature is simply designed to allow you to import a look/feel (style sheets, modules, and templates) and associated page layouts (which apply those items to the layout).

It is not designed to drop content/modules into articles not setup your Site Structure for you, which is why you have to reconnect the jumpTo pages. It allows you to maintain a bit of flexibility but still re-use or apply the themes as you like.

Is that what you had in mind? In that case the theme would also ship with a SQL template as well, which I think is what you are getting at. Although I may be wrong...

My comment is as follows, that the theme module contains a look and feel, which exist of Style Sheets, Layouts and Modules. This lat one is my concern, because the modules contain Content and strictly spoken content and layout should be separated. So in theory it is easy to import/export themes and in practice with work around this is possible. But it is not possible as the theme module suggest.

To give an example, I make a very nice theme, with a header, footer, right column. In the header I put a custom html module with the site title. In the footer a custom html module with some site information and in the right column a block with a login form and navigation. In the main block articles. Exporting the custom html modules are alright, exporting the navigation module sort of (works), but the login module results in a broken link to a page which does not exist on the website where I import the theme. And by export it is in principle not done to guess that the redirect login page does exist on import.

Also another issue I have with the themes, is that I deleted the folders /system/modules/calendar and /system/modules/news for a particular website and I could not access the layout anymore because they are depended on those modules, why are those modules then in a separated directory? So to improve contao, I would like to redesign and redevelop this to resolve those issues.

I don't see that as being the function of a theme. The modules that come loaded with a theme should only necessarily be used in conjunction with the page layout.

All you need to do is provide a list of dependent modules for a theme (and in the case of news and calendar, those are part of the core system so I don't see needing to specify those, nor should you delete them when you can simply disable them in the System Settings). Those should not be exported with the theme itself because they can be Contao-version dependent, plus it is better to add them through the extension repository so that they can be updated later.

The solution to the jumpTo is to provide a SQL template file that gets loaded with the install tool that contains the proper data. That is separate from a theme, however, in my opinion.

I can see something during import/export of themes that perhaps gives you the option to include the template SQL and an XML list of the 3rd party modules that are used so that on import if there are any that are missing you can give the user the option to install them, but they should not be packaged as part of the theme (plus that may very well violate the license of many of the extensions).

Themes are simply design and layout starting points for your sites and I don't think they should be taken as fully functioning sites out of the box. For that they need a template SQL file.

I agree that an exported theme should only contain theme andlayout options. I am not saying that I want to export the theme including the modules. No what I want is functionality to export a theme without the modules.

Winanscreative: can you explain to me, why I have to define modules by a theme? In previous contao versions, this was done through a separet module functionality but now it is included in the theme section... Is that not a bit weird? I think we are saying the same thing. But you are arguing for no change? While I am saying that when there is something structural wrong wrong with the theme framework or paradigma in Contao, why not change it for the better?

I think that modules SHOULD inherently be grouped by theme because they directly relate to Page Layouts and in turn the Style Sheets for that theme.

Here's a good real life example of how I use the themes manager to keep things organized:

I have a client running 9 different websites from a single Contao install. In previous Contao versions I had a single "Module Manager" that contained all the modules for all 9 sites, as well as a "Style Sheet manager" with all the numerous style sheets, page layouts, etc.

With the theme manager, I can break the sites down into themes and isolate their design & layout resources as well as their modules.

I see what you are saying in that if I create a module that is necessarily "content-based", such as a custom search form from "Form Generator" that I would be using in my page layout, that there is more that needs to be exported other than stylesheets/page-layouts/modules. But that is why Contao has SQL data templates, which I see as different from themes.

Themes for export should likely contain only base modules that are not dependent on other modules/content themselves. HOWEVER, I think you may be on to something in simply giving the user the option on export to choose which modules would be included. I think this would give you the best of both worlds, no?

Quote:

---

Themes for export should likely contain only base modules that are not dependent on other modules/content themselves. HOWEVER, I think you may be on to something in simply giving the user the option on export to choose which modules would be included. I think this would give you the best of both worlds, no?

---

Yes I that is what I am thinking of.

Quote:

---

With the theme manager, I can break the sites down into themes and isolate their design & layout resources as well as
their modules.

---

Another solutions for this, is a separate 'module' for Frontend Modules, grouped by Layouts in the system. A theme export will only export a theme, and leaves the Modules section untouched.

Hi all,

I am working on an extension that let users the ability to export contents from a Contao installation and import them into another installation. The extension does not require any core changes.

You can get an overview at the project home page.

The project is currently on hold due to lack of time :(

I hope I can get on it again to the end of October.

Hi ga.n,

Your extension sounds great. However I have some questions, how does your extension know that e.g. jumpto by forms has to be followed? And how does your extension work with my own developed extensions?

Jaap

Quote:

---

Originally Posted by grapio

Hi ga.n,

Your extension sounds great. However I have some questions, how does your extension know that e.g. jumpto by forms has to be followed?

---

simply it recognizes that the field type is a pageTree and follow it. it currently supports all the core widgets.

I've already exported (and reimported successfully into another installation) some websites with dozen of pages "linked" to modules, pages, different layouts and so on.

Quote:

---

Originally Posted by grapio

And how does your extension work with my own developed extensions?

---

You have to edit your dca to add the "Export this" button (in the operations section).

if your extension uses core widgets (i.e. fileTree, pageTree and so on) this is the only modification required :)
Anyway the system is expandable so it is easy to add code for exporting "complex" fields, if your extenson uses some fields that can not be recognized by the exporter.

An example of "complex" field is the field "modules" of the tl_layout table.