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.
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.
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.