Disabling the dashboard module permanently removes all blocks from the dashboard

Right, that's the idea - the dummy theme would always be a subtheme of the current admin theme (or the default theme if your site isn't using an admin theme).

Are there specific settings that get inherited that you would be worried about? I think the idea here is mostly that we want all settings to be inherited, since from the user's perspective this should look exactly like their admin theme does, with the only difference being the list of regions that are displayed.

I haven't tried it, but that looks pretty reasonable to me.

When the module is enabled or disabled, it looks like that code needs to run in a specific order with respect to block rehashing in order to work correctly - is it relying on module weights for that, I guess?

Maybe we can move the theme idea to @sun's new issue at #951212: Dashboard blocks should be configured completely independently from the default/admin theme blocks instead.

In that case I think this patch is pretty much ready to be committed. I tested it out, and it seems to work fine. I was impressed that it even caught (and correctly handled) the edge case where blocks that were once on the dashboard had been moved to another part of the admin theme during the time when the dashboard module was disabled :)

The only small thing I noticed was that in this query in hook_disable():

+  $result = db_select('block', 'b')
+    ->fields('b')
+    ->condition('b.region', dashboard_regions(), 'IN')
+    ->execute();

we are loading all rows from the database, but that seems unnecessary since we only wind up using a couple of them.

Er, yes, I probably had my head turned 90 degrees when I wrote that... in which case they switch places anyway :)

Rerolled to fix that issue.

I think this is basically RTBC. Looking at dashboard_enable(), though, I wonder why we ever want to check global $theme_key - that seems a little fragile, to make it depend on the theme of the current request (especially since this is inside an API function that might be called outside of a web browser, even)?

On the other hand, it's not much worse than what some of the other dashboard code does, and I don't really know how to fix it in the context of this issue alone.

Right, I agree we need something more than 'admin_theme' - I was just wondering if we couldn't use 'theme_default' or something as the fallback instead. However, there is no guarantee it would be better than the current behavior. For the purposes of this issue, what we have is probably the best we can do.

Here is a quick reroll because I realized that on hook_uninstall() we should be deleting this variable so it doesn't litter the database forever. (I'm not changing the RTBC status since this is a pretty trivial addition to the patch.)