Closed (duplicate)
Project:
Drupal core
Version:
6.x-dev
Component:
block.module
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
16 Dec 2006 at 22:27 UTC
Updated:
21 Apr 2009 at 18:16 UTC
Jump to comment: Most recent file
Comments
Comment #1
profix898 commentedYes, this is really anoying, but I dont think it can be solved easily. We are facing such issues with contrib theme switching modules for some time. ATM we are not able to distiguish installed themes (themes that can be chosen as admin theme) from enabled ones (themes that are exposed to the user). So you must enable the theme to configure its blocks and disable it then to avoid it being selected as user theme. This is something we must think about for Drupal 6. The only chance I see to solve this quickly is to make all (installed) themes available in the blocks configuration ...
Comment #2
profix898 commentedOr a more minimalistic approach: show enabled + admin themes in blocks configuration.
But actually I'd prefer the previous patch, because it solves the same issues with (sections, taxonomy_theme, ...) contributed modules.
Comment #3
dries commentedCommitted to CVS HEAD. Thanks.
Comment #4
Jaza commentedThe block administration page now shows 'configure' links for all installed themes. On a default install of 5.x, this is SIX links, when it was previously zero (with only one theme - i.e. garland - enabled). When I first saw this, I was very confused and somewhat bewildered by the big clutter of links. IMHO the patch that was committed in this thread was very bad for usability on the block admin page.
Attached is a new patch that rolls back the previous patch, and that introduces a new persistent variable called 'configurable_themes'. This patch makes it so that when a new admin theme is selected on the 'admin/settings/admin' page, the admin theme is added as an array element to 'configurable_themes', with the element's key being
'admin_theme', and with its value being the name of the theme.The idea is that other modules (e.g. sections, taxonomy_theme) can also use this persistent variable to tell the block admin page that certain themes should be configurable. For example, the sections module could add elements such as
('sections_0' => 'bluemarine', 'sections_1' => 'marvin')to the variable.I know that it's very late in the game, but this patch was only committed a few days ago, so there hasn't exactly been much time to notice it and to fix it up. This is a very small API change (one new persistent variable) that will greatly improve (or should I say, that will restore) usability on the block admin page.
Comment #5
profix898 commentedNot sure this is a matter of taste, but I like having all themes available in blocks configuration. But I also realized that the Garland theme cant handle many tabs nicely (It doesnt format a second row of tabs at all).
So all in all I like what Jaza proposed in #4. The only problem with all the theme-switching modules is that it is very difficult to tell which themes are actually used. So these modules will probably add all themes to that array to avoid excessive code complexity.
I cant tell how users generally administer their themes. In my case I only have the themes installed which I actually use (= site themes + admin theme). What means I simply remove all unneeded themes from my install ... in that case it is very nice to have all remaining themes available in blocks configuration.
Comment #6
drummThis should be done with a hook to gather theme names instead of a variable hack.
Comment #7
restyler commentedI've installed cvs version of D5 yesterday and was surprised by these tabs for all disabled themes... the blocks configuration page started look like a mess.. may be I don't understand something, but isn't it more correct not to allow admin to select 'disabled' theme as admin theme?
Comment #8
restyler commentedooops, sorry, missed Jaza patch.
Comment #9
profix898 commentedMarked http://drupal.org/node/140949 as duplicate of this one.
I think we should revive Jaza's patch in #4 again ... that would solve the issue of all themes showing up in blocks administration and still allow disabled (but used) themes to stay configurable.
Comment #10
quicksketchSubscribing.
Comment #11
profix898 commentedHere is a patch introducing a new hook 'config_themes' to determine which themes to show in blocks configuration. What means only enabled themes and themes returned from hook_config_themes are available for configuration. Contrib 'theme switching' modules can easily implement the hook and make additional themes configurable.
Comment #12
profix898 commentedComment #13
catchNeeds a re-roll.
Comment #14
klance commentedOne of the big problems with administering sites in the same theme that is used to view the site, is the fact that some of the administration pages often need a great deal more width than ordinary pages, to be reasonably functional. One such page happens to be the "Blocks" administration page, because it displays the right sidebar unconditionally. Another is the "Access control" page, which often has to be scrolled horizontally if there are numerous roles. If your main theme has a three-column layout with "overflow: hidden;" on the center column to prevent content from spilling onto the right sidebar, the contents of the administration pages will often be cut off at the right boundary of the center column. Hence the need for an administration theme. On the "Blocks" administration page, even if you have links to other themes, Drupal still has to switch to the target theme in order to administer blocks for it, thus bringing you back to square 1. It would be ideal to be able to administer the blocks for all themes using the selected "Administration theme." Besides, in many cases the blocks that are being administered aren't even displayed in the administration pages--one would have to go to the node view to see them anyway--so in my opinion there's no point switching to the target theme to view the blocks as they are being administered. Just my opinion.
Comment #15
jody lynnThis issue reemerged at http://drupal.org/node/192779
Comment #16
drecute commentedNice patches guys. I want to try them out. What file or files are my suppose to modify. Thanks.