Enforce themes to content-types in Drupal

Yesterday, for my project at ONE-agency, I was seeking for a module that could change theme settings beyond default implementation.  When installing Drupal, which is drupal6 in my case, you can add your own theme. After adding, it is available in the administration themes list so you can set it as default (admin/build/themes).  Because drupal is also a content management system, it allows further theme settings such as the default admin theme (admin/settings/admin). It has even an selectbox “Use administration theme for content editing” which simply allows you to always display the admin theme or otherwise the default theme such as your own.

It is the word “always” that I didn’t like there, because I am very fond of using the admin theme as content managing theme and the frontend theme otherwise.

Reason and purpose

In my short experience with drupal, I came across a couple of nice frontend themes that were too small to easily edit content.  Pages or stories, with that nice TinyMCe installed, the body textarea and fields have to be restyled completely to fit in.  Our company almost always did that give the client a leaner interface to work in.  Here is the problem, it is not pretty to work, copy , paste or manage your texts in such a small area.inflatable balls

Always using the admin theme is no sollution as well.  When a node form is displayed, end-users swap from front theme to admin theme, and that is not a pretty sight.

In drupal you can set or code permissions to almost everything and the user mechanisme is rather marvelous. Suppose you have forms used to write and manage pages and forum topics.  It is very likely that managing a page is especially for the content manager (role) and all users can post topics in the forums. Even worse you want every user (anonymous role) to be able to write and edit their own topics.


With this in mind, we could try to force the site theme to certain roles, so that anonymous users and forum moderators see the site theme and content managers, webmaster roles see the admin theme, no matter on which page.  I will have to figure out if my initial theory matches up the reason.
The first approach to do things with roles and permissions in drupal.

  • A user surfing to an node edit form where he does not have permissions to, will be shown an access denied page.  This user will end up in the admin theme.
  • When another content type comes in (and this happens a lot in the production) , for instance blog users … , then I would have to make a new role for this type of user and change my settings so that blog users see the frontend theme as well. I can here you think “so, why not make a more general role for all the container of users. for example content users”. The answer here is that I’d have to set the default role for registered users as content users, but that would be actually the same as the normal authenticated role provided in drupal. For this users, it is already clear that they can stay in the frontend theme.
  • Drupal registered users are authenticated users but can not change or set their role themselves. So you would surely have to set that moderatioin is needed after registration of users by a webmaster or admin role.
  • Webmasters, admin role and like me developers would stay in the admin theme at all time.  As we don’t like logging in and out all the time to test how the end users see things, I tend to walk away from this proposition.
  • If you by accident or so some users end up with the authenticated role (or content users) and the role you had in mind, they will see the admin pages you allowed for them in the ’smaller’ theme.

A second approach is to force the front-end theme to specific content-types in stead of roles.  This way blog users (blog content type) and forum users (forum content type) could see the frontend where other content forms will appear in the admin theme. This makes more sense to me.

Start working

What I came up with is that both approaches can be nice if used how it is intended.  The feature of setting your frontend site theme for specific content-types is nice because you can manually set that you want pages and stories in the admin role and bloggers or forum posters in the theme designed by your designer collegues.  The approach of role specific theme handling could be nice but more likely something happens that shouldn’t.  Maybe there should be an overruling option that you specifically want to show the front theme for the role ‘content users’.  This could make sense for various website concepts.

The module I build is very small and easy to use, because there is only one administer settings form.  You choose the content-types where you want to force the frontend theme to appear with the extra option to force the front theme for certain specified roles as well.

After the proof of concept was evaluated well, I did some severe testing to check all possiblities.  In the drupal install i added then the coder module to check my code for all conventions in Drupal.

You can download this module.

Download Theme setter module Version 0.0.2
Feel free to comment your questions and remarks.


The module adds settings to force the frontend theme for certain content-types and certain roles. The reason why I built this module: in almost all designs that are too small or not fit to be viewed in an other theme than the admin theme, you can now enforce the frontend theme.
Example blog-posters (content-type) and forum-posters(content-type) will be provided with the theme by the designer. This is the enforce by content-type rule.
The other rule is enforcement by roles and works the same way.
Then there is an extra option that extends this algoritme where one rule gets priority to another.

This entry was posted on Wednesday, September 10th, 2008 at 8:02 pm and is filed under Drupal. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

8 Responses to “Enforce themes to content-types in Drupal”

  1. Nison Says:

    Actually, quite frankly, the commentary is more interesting messages themselves. (Not to insult the author, of course:))

  2. ectogon Says:

    Have you submitted this to drupal.org?

  3. will Says:

    Hi. I installed it. I configured my D6 site (local, on Ubuntu 8.04) such that all content types, and all roles, are to use the Tendu theme. Nothing. I am still getting those content types with vocabulary/term associated with it, appearing differently from those without.

    Did I misunderstand what this module is supposed to do? What I want is to be able to choose the “look” by content type and by role, rather than D6 choosing them.


  4. Rj Says:

    Thanks for sharing.. saved me a lot of time. :)

  5. Chad Says:

    Thanks… Exactly what i was looking for.

  6. Cesar Brod Says:

    Great idea! I am thinking of a different thing though and I am trying to tweak your module a little bit in order to get what I want. Here is the situation:

    1. I use the Sections module along with pathauto, so I can say that all Urls that have book/* to use a specific theme. As my content evolved, though, I have created other content types that will use the same theme I have for the books, so I need to remember to add the proper pathauto settings and also add these pages to my Sections.

    2. What if, instead of only using the front theme, I could have a matrix of themes and content types, and freely select the themes I want for each type of content?


  7. Stalski Says:

    @all : this functionality in this module will be combined with these modules soon: administration theme, theme_key and theme_setter.
    This will be better for everyone and lead to less confusion. The new module will have all features combined so you will have a lot of factors leading to a certain theme.
    - path based
    - content type based
    - role based
    - maybe even user based, but this never occurs because most of the time, we developers and function analysts would end up using one theme with several variants imho … So this would be a bit over the top.
    I will let you know when everything is done.

  8. Tom Says:

    This is a lifesaving module! No need to theme up all the forms in my front-end theme for the admin :) Thanks a lot!