Right now the administration theme can only be used on pages with the admin prefix and content editing pages. With the ongoing efforts to put a better administration theme into core, I think we also should start working on a more flexible way to use the administration theme on more pages.
I've started to develop a module, which I've contributed to open the discussion and to allow people to use the administration theme on more pages in Drupal 5 and 6. A Drupal 7 version is already available.
http://drupal.org/project/admin_theme
I've also introduced hooks there to allow modules to add their pages to the admin/settings/admin page as options.
<?php
// $Id: admin_theme.api.php,v 1.1.2.1 2008/12/13 09:47:29 davyvandenbremt Exp $
/**
* @file
* Hooks provided by the Administration theme module.
*/
/**
* @addtogroup hooks
* @{
*/
/**
* Add more options to the administration theme settings page.
*
* This hook allows modules to add more options to the administration theme
* settings page.
*
* @return
* A linear array of associative arrays. The keys of the linear array are
* the identifiers for the "options" that will be check for in
* hook_admin_theme_check. The associative arrays have keys:
* - "title": The title to display on the checkbox on the administration
* theme settings page.
* - "description": The description to display on the checkbox on the
* administration theme settings page.
*/
function hook_admin_theme_info() {
$options = array();
$options['batch'] = array(
'title' => t('Use administration theme for batch processing'),
'description' => t('Use the administration theme when executing batch operations.'),
);
if (module_exists('coder')) {
$options['coder'] = array(
'title' => t('Use administration theme for code reviews'),
'description' => t('Use the administration theme when viewing Coder code reviews.'),
);
}
if (module_exists('service_attachments')) {
$options['service_attachments'] = array(
'title' => t('Use administration theme for viewing the service attachments form on nodes.'),
'description' => t('Use the administration theme when viewing service attachments on nodes.'),
);
}
if (module_exists('webform')) {
$options['webform_results'] = array(
'title' => t('Use administration theme for viewing webform submissions.'),
'description' => t('Use the administration theme when viewing webform submissions.'),
);
}
if (module_exists('statistics')) {
$options['statistics'] = array(
'title' => t('Use administration theme for viewing pages of the statistics module.'),
'description' => t('Use the administration theme when viewing pages of the statistics module.'),
);
}
return $options;
}
/**
* Check if an option is "on" for the current page.
*
* This hook allows modules to check for each option defined in
* hook_admin_theme_info if the option is "on".
*
* @param
* $option. The option to check.
* @return
* TRUE or FALSE indicating if the administration theme should be used.
*/
function hook_admin_theme_check($option = NULL) {
switch ($option) {
case 'coder':
return arg(0) == 'coder';
case 'batch':
return arg(0) == 'batch';
case 'service_attachments':
return arg(0) == 'node' && arg(2) == 'service_attachments';
case 'webform_results':
return arg(0) == 'node' && arg(2) == 'webform-results';
case 'statistics':
return (arg(0) == 'node' || arg(0) == 'user') && arg(2) == 'track';
}
}
/**
* @} End of "addtogroup hooks".
*/
| Comment | File | Size | Author |
|---|---|---|---|
| #43 | screenshot-107.png | 74.58 KB | mgifford |
| #38 | system-administration-theme-14.patch | 17.3 KB | davyvdb |
| #35 | system-administration-theme-13.patch | 17.3 KB | davyvdb |
| #32 | system-administration-theme-12.patch | 17.3 KB | davyvdb |
| #30 | system-administration-theme-11.patch | 16.51 KB | davyvdb |
Comments
Comment #1
davyvdb commentedJust a quick heads up. I've added a new feature "Do NOT admin theme on certain pages" and regrouped all form elements. Not allowing admin theme on certain pages makes it possible to say "Allow admin theme (so on all /admin pages) bug not on admin/settings/*.
Comment #2
dave reidPlease see #135976-21: Make picking administration theme more user-friendly for the approach I'd like to take for this issue that will still keep things simple.
Comment #3
davyvdb commentedGood idea to move this screen closer to the themes section, but I think we need some extensible framework to allow module developers to define their own sections too. Maybe these two are different things?
Comment #4
dave reidHere's an initial patch for review based off a solution I came up with in #135976: Make picking administration theme more user-friendly.
Comment #5
dave reidMissed attachment...
Comment #6
dave reidThis time fixing the new tests that were added for the admin theme.
Comment #8
davyvdb commentedI kind of gave this another twist. I put it back on it's own page (see screenshot) and added role visibility and vertical tabs.
This patch will probably fail since tests need to be written. But first... What do you think of this way of working? http://www.drupal.org/project/admin_theme can still be used as a contributed module to add other stuff like checkboxes for "use for editing content."
Comment #10
davyvdb commentedComment #12
davyvdb commentedComment #13
davyvdb commentedComment #15
davyvdb commentedComment #17
davyvdb commentedComment #19
davyvdb commentedComment #21
davyvdb commentedComment #22
davyvdb commentedComment #23
davyvdb commentedComment #25
davyvdb commentedComment #26
davyvdb commentedComment #28
davyvdb commentedComment #30
davyvdb commentedComment #32
davyvdb commentedComment #33
davyvdb commentedComment #35
davyvdb commentedComment #36
davyvdb commentedComment #38
davyvdb commentedComment #39
seutje commentedQuick look, some of the selectors are pretty specific and this one:
Seems a bit silly, isn't this more efficient:
I'll try to have a decent look when I get home
Comment #40
davyvdb commentedI followed the same code that was already available. It might have to do with jQuery versions.
Comment #41
pasqualleMy major problem with this patch is that it should not be in core. When I am thinking about using this feature then this is too much or not enough, depending on the requirements..
1. I mostly do not need this
2. If I need this, then I need it for other themes also and/or need more options
other concern: if you switch the theme based on path only then you will find major problems with ajax content. #340276: ajax view and sections module
I would really like if Drupal would work better with more themes, but as I see this patch is not the right way to move forward..
instead of system_show_admin_theme() function just create some kind of *_alter() hook where modules can say which theme (admin or any other theme) should be used on given page. And let all the extra setting to be implemented in contrib..
Comment #42
seutje commentedlooks like system.module went stale coz of #557890: Configuration page: 'Search and metadata' category
I'll try to reroll it when I get back tonight if no1 else did by then
Comment #43
mgiffordI've got concerns about introducing more vertical tabs before addressing - http://drupal.org/node/467296
I do think that more people are going to look for an admin theme config at the top tab rather than at the bottom (under the other themes).
I like that it gives much more control to how you want to display non-public areas of your site. For instance if you've got an internal wiki you might want to display that with the admin theme so that it's clear that the pages aren't public.
I tested the patch and it worked well.
Comment #45
davyvdb commentedComment #46
davyvdb commentedComment #47
dave reidI'm not intending to demean your work Davy, but I just don't see how this is useful for the majority of our users. But I have no problem with this living on in contrib and it would be quite easy to do. In addition, the patch does not have an upgrade path for the old/current admin theme variables.
+1 for won't fix.
Comment #48
davyvdb commented@Dave Reid. I'm curious about how many people need this. I've release the admin theme (http://drupal.org/project/admin_theme) module and about 800 people are using it. Not much, but it seems like a lot of other users need more flexible settings. I've made this module because I needed it on about 80% of the sites I made. And all other guys at the companies I've worked for had the same need. It makes more sense to see the batch pages in the admin theme, devel (node stuff) too. There's no use for that in the front end theme.
On the other hand, I can live with it that this won't happen in Drupal 7. We have http://drupal.org/project/admin_theme and I've sworn the pledge #D7CX.
Comment #49
pasqualleThemeKey 1,139 users
Sections 1,544 users
Comment #50
dave reidJust thinking we need to figure out what should or should not land in core with the code freeze of doom coming up fast. According to the current usage statistics, 800 people is 0.005% of the current Drupal installs. Where as something like token, which has landed in core is over 50% of the current Drupal installs, which I can understand. As long as we have the capability to do this in contrib just as well as we could in core, there shouldn't be a reason to include this in core.
Comment #51
drifter commentedI have a related issue in #547162 - in that node/%/translation should use the admin theme if it's switched on for editing. Goba asked for a more generalized solution, this might be it?
Comment #52
davyvdb commentedThis won't probably happen in Drupal 7, so I suggest we do it only for a specific case where the administration theme makes a lot of sence, batch processing pages. I filed another issue for this http://drupal.org/node/563634
Comment #53
narendrak commentedhi drifter,
i want "node/%/translation" should use the admin theme.
i am not getting exact solution from post.
can you please direct me right path to solve this..
Thanks in advance
Comment #54
pasqualle@Narendrak: Sections or ThemeKey
Comment #55
narendrak commentedContent Edit
Comment #56
moronicbajebus commentedFor many of the clients I work with, this is what they need - particularly those migrating from WordPress. I can understand why to have it adjustable because many sites will have node/*/edit as part of the admin, but this doesn't make sense for a community driven site such as Drupal.org.
@Dave Reid - This may very well be the case that most Drupal programmers will not use this functionality, but I would bet that web agencies building Drupal sites will use it. Why? It is a simple thing to add a lot of perceived value.
Comment #57
dave reidMuch better alternative at #669510: Merge administration theme with hook_admin_paths() since we now have hook_admin_paths() in core. Plus, the solution is easily over-ridable by contrib modules.
Comment #58
davyvdb commentedFair enough. This works for me. Much more consistent solution that one. I'll mark this a duplicate then.