Dashboard blocks should be configured completely independently from the default/admin theme blocks

Partially a duplicate of #950878: Disabling the dashboard module permanently removes all blocks from the dashboard?

Although @carlos8f already has a patch up there that solves that bug in a different way, so maybe it is better to split this off from the bugfix anyway.

I'm working on this, and so far it is looking very promising, actually.

This patch is what I had in mind from the discussion at #950878: Disabling the dashboard module permanently removes all blocks from the dashboard and I think similar to the idea here as well.

It doesn't solve #601932: Allow dashboard to limit available blocks by itself, but the UI you get for free from this (see attached screenshot) might help there, in addition to the other benefits of approach.

The remaining issues, though, are these:

• The 'dynamic base theme' approach works great in general (and especially with Seven), but not after switching themes. If you switch the theme, then at a minimum I found you need to clear caches to make the dashboard page look at all presentable (not sure which caching bug causes this), and even then, certain things (logo, color module integration) don't look quite right. To solve that (and not wait for Drupal 8 to solve it), maybe we should look into @sun's suggestion above: "Prior to retrieving blocks for the dashboard, just switch the current theme to 'dashboard_theme'. Revert the theme afterwards."
• The fake dashboard theme is naturally hidden in most places, but does show up under admin/appearance/settings still. Actually, that could even be useful in some ways, but for the most part it is confusing - we should probably hide it somehow.
• This would need an upgrade path, but I saw no point in writing one without the rest of the patch being done first.

Subscribing

OK, so it sounds like this needs work.

Hm... I'm guessing there's a dashboard_theme.info file that accidentally got left out of this patch? :)

Adding a new hook_system_rebuild_theme_data() is likely to get some pushback at this point. We should try to do this issue without that. I don't think it's the end of the world to ship a separate 'dashboard_theme' in the themes directory.

Never enabling the fake theme (and only using it to construct the dashboard regions themselves, not the whole page) seems to make a lot of sense! I think that means:

• hook_menu_alter() in the patch is no longer necessary?
• A hook_flush_caches() doing the equivalent of http://api.drupal.org/api/function/block_flush_caches/7 (but for this disabled theme) might be necessary?
• We may now need a hook_form_alter() in order to make the Dashboard region selector appear on the individual block configuration page - i.e., in order to produce this screenshot from above: http://drupal.org/files/issues/block-configure-dashboard-separate-theme.png

I am not the only person working on this issue, so unassigning myself to avoid confusion.

Attempting to fix some of the issues above revealed a bunch more bugs. I'm getting less optimistic that we can effectively make this work without the dashboard theme being enabled and/or being the actual theme used to render the page :( A lot of modules make assumptions about which themes they are dealing with and their expected status.

In any case, the attached version mostly works now - the dashboard correctly renders the blocks and allows you to arrange them. There will be at least one test failure, though, and it's real. It's because block_add_block_form_submit() only saves data to the database for currently enabled themes, so when a new block is added, it does not get recorded correctly for the dashboard theme. This is an example of something I'm not quite sure what to do about.

I went back to putting this in themes/dashboard_theme for now (so we don't have to deal with a new hook), but looking at #953336: Contributed modules are not able to test theme-related functionality that issue does seem to make a lot of sense.

This version should solve the remaining issues discussed above. I do not know of any functional bugs with this one; the patch seems to work fine now, and the only thing missing is an upgrade path.

There are some hacks here, no doubt, and they should be discussed. But none that seem totally beyond the pale to me.

As this is marked "task" not "bug report", here is a reminder of what this patch does and why it is worth pursuing still:

For end users:

1. Makes it so that putting a block on the dashboard does not prevent the block from being placed anywhere else on the site, or vice versa (identified elsewhere as a serious WTF).
2. Allows the dashboard regions to get their own dropdown on a block's configuration page (http://drupal.org/files/issues/block-configure-dashboard-separate-theme.png), rather than being buried rather confusingly in one of the other dropdowns.

For the code:

1. This patch removes many more lines of code than it adds, and overall makes the module simpler:

$ diffstat dashboard-theme-951212-14.patch
 modules/block/block.admin.inc               |    2 
 modules/block/block.test                    |   13 -
 modules/dashboard/dashboard.install         |   79 -----------
 modules/dashboard/dashboard.module          |  192 +++++++++++-----------------
 modules/dashboard/dashboard.test            |    4 
 profiles/standard/standard.install          |    6 
 themes/dashboard_theme/dashboard_theme.info |    8 +
 7 files changed, 100 insertions(+), 204 deletions(-)

I'm not so hot on adding a /themes/dashboard_theme. I'd rather that this issue be put off until #953336: Contributed modules are not able to test theme-related functionality is approved, that way we can do /modules/dashboard/dashboard_theme instead.

Also, if you want to judge a patch on number of lines removed, I think http://drupal.org/files/issues/dashboard_real_fix_0.patch wins :D

In my opinion, this is just trying to help remedy the fact that blocks are just terribly broken (the fact that you can't assign one block to more than one region), which is not the way to go. I don't think there is a solution for Drupal 7, but for Drupal 8, I think this is totally fixable (Butler!)

Agreed with #17, this is symptom fixing. Consider downgrading from major to normal priority.

Let's retitle this to focus on the goal, rather than the implementation.

If someone has a different implementation that meets the goal and is achievable, they can feel free to propose it. But the above patch was pretty close to working, and would have been fine for Drupal 7 if it had been finished at the time (though probably no way to backport it to D7 now).

This Module is a killer feature in larger projects. If you have more admins a lot of contributors and set the blocks, views right it simplifies the work. I use it in my personal site too. For example i have some blocks, which display latest g+ contributions, tweets, facebook etc. In the main content area i have my last created pages with a button for sharing on social sites. The main point is - nobody uses it, becouse nobody nows how! If somebody set up some usefull blocks, published some usefully views it would be a different story. If u sometime remove it from core, make it at least a working module.

Patch needs to be rerolled. And may be obsolete due to SCOTCH?

I agree that this does not qualify as major, especially since it's not at all backportable and it hasn't seen enough traction to even get a reroll since D7 was released.

Let's still leave the issue open until such time as (hopefully) SCOTCH resolves the issue in a way that is not a big, clever hack.

It's been removed from core.