Short description:

You make all sorts of blocks. Then you install a new theme.
Drupal makes an incomplete (!) copy of the blocks and sort of ties them to the new theme.

I may have a solution, but your input is probably needed.

Long description:

Blocks are made by different kinds of code:
?q=admin/block/configure/block/20
?q=admin/block/configure/menu/214
?q=admin/block/configure/event/1
?q=admin/block/configure/user/3

Blocks are created on a lot of different dates.

Drupal has a rather nasty bug: whenever you install a new theme all the old blocks are duplicated in the Blocks table.

Let's take an example from the blocks table just after NEWtheme has been added:

menu;215;DEFAULTtheme;1;0;left;0;0;0;[some fine php-statement]
gets copied to
menu;215;NEWtheme;1;-2;left;0;0;2;[php-statement missing]

What sucks?
* The php-statement will no get copied.
* visibility will not get copied
* pages will not get copied

What sucks even more?
* When we try to edit the menu 215 block in the DEFAULTtheme it fetches the wrong block from the database - the NEWtheme-one with the php-statement missing
menu;215;NEWtheme;1;-2;left;0;0;2;[php-statement missing]
(Block table structure: module;delta;Descending;theme;status;weight;region;custom;throttle;visibil
ity;pages)

These are bugs.

You could also argue that not copying the placement of the block and not copying the "on/off"-sattus to the new theme is a bug.
But lets get to a solution quickly.

PROPOSED SOLUTION:

You should be able to set a "global"-flag somewhere on the
?q=admin/block/configure/[block name]
page.

UI:
[v] should work like this in all themes (same content, placering, php-logic, visibility (1))

Then, over at the block-pages
http://mydrupalsite.com/?q=admin/block
http://mydrupalsite.com/?q=admin/block/list/sometheme
http://mydrupalsite.com/?q=admin/block/list/newtheme

you should have some checkboxes close to the block name.

Show this on
[ ] All themes
[ ] sometheme
[ ] newtheme

Actually, we should lose
http://enhedslisten.vertikal.dk/?q=admin/block
as soon as possible. It's baffling.

Copy blocks between themes? Perhaps. But often not that necessary. Most designers would go for fewer but smarter blocks.

The way blocks are presently copied and maintained is buggy and we need a smart solution.

Maybe you can improve on this proposed solution?

Comments

pasqualle’s picture

pasqualle
Location 🇭🇺 Budapest
commented
Status: Active » Closed (won't fix)

This version is not supported. Reopen or create a new issue if the problem exist in any recent version (version equal or above Drupal 5)

doublejosh’s picture

doublejosh commented

This goes against the flexibility of themes. This is impossible, unless you ensure that all themes have the same set of regions.

Requiring that all themes have the same set of regions mean all themes will look even more similar... a BAD idea.

I love the flexibility of regions. Just make sure you take the 5 MINUTES to configure where your blocks will land in your new theme when you install it.

dman’s picture

dman commented

If the copy does indeed not get the vital phpcode, yet a new block instance is copied, I would say that is indeed a bug.
Need to confirm if the problem is still present in D5,6. Nothing else will be worked on, I imagine.
The visibility and placement however does need to be adjusted on a per-theme basis. Which admittedly makes the block-instance copy a little pointless.

I know what you are saying with the 'default' configuration intuitively meaning 'all themes' yet actually only applying to 'current default theme'. It's a flaw of sorts.
Yeah, I'd like to have a 'global' block list to administer, and changes made their inherited somewhat. But I think it may take a lot of refactoring.
I don't run sites with multi-themes active in parallel, so I can't suggest the code.

:-\