Blocks admin user interface should not do theme switching

This nice feature of Drupal calls out people to say stuff like (from http://stackoverflow.com/questions/1393464/drupal-administration-theme-d...)

The problem is that when you try and edit the blocks page, it uses the default theme and half the blocks admin settings are unclickable behind the images. I KNOW this is by design in Drupal, but it's annoying the hell out of me and is edging towards "bug" rather than "feature" in my mind. It also appears that there is no way of getting around it.

So since it was affecting both the dashboard add new block experience and the overlay block editing experience (see http://drupal.org/node/544360#comment-2103130 and http://drupal.org/node/517688#comment-2054106)

Just want to comment that I see a lot of WTF in the forums regarding the theme changing on the block config page-- and frequently get asked if there's anyway to prevent it. I would think stopping that behavior, especially in light of the difficulty it seems to be causing this important d7 feature, is no great loss.

1. The attached patch removes the theme switching from the blocks admin pages altogether.

2. This also fixes a recently introduced bug where even the new block addition bug page was showing up in Garland regardless of our admin theme (it inherited its theme callback from the main/default blocks page). This was a mistake introduced with the menu theme callback patch.

3. The patch also adds demo pages per theme. These pages do not display blocks or any page content, just the themed page with the block regions highlighted.

4. I've also found a bug with the help text while adding the link to the demo pages to the help text. The help text was only displayed on the default tab of the blocks admin, since it was using that static path to match. Now added a more intelligent checker.

Here is how the Garland blocks admin looking now:

And the demo page when the link is clicked:

Not sure about the exact interaction we should support/follow here. Should we have some kind of "go back to block placement" action on the demo page? Is the demo link in the help adequate? (Note that the "add new block" action link is not showing up and that has its own issue at #556872: Action links do not work on all levels (example: 'add block' action link does not appear))

Also note that the demo page does not spell out the name of the Highlighted content region. That is the same regardless of the patch. Tried to find the root of the issue, but decided I covered enough ground already :)

Since we are already on the second level in the local tasks, we cannot do this easily with local tasks. We could add a local action, not sure whether that is applicable here (demo is not a CRUD operation :). Any better ideas?

Updated patch with updated screenshot as per @Bojhan/@Dries. Looking into those test failures but I highly doubt we can fail so many tests by this simple change. Removed the "add block" link from the help text, since it will be a prominent local action once the related bug is fixed.

Ok, these test failures all around were due to how the underlying code (and many API functions) behind the blocks page assume we do switch the theme. Those underlying functions and APIs need fixing. Therefore this results in some API changes.

- made block_admin_display() do something in itself with its $theme argument (get blocks for that theme and order them with that in mind)
- _block_rehash() gets a $theme argument and defaults to $theme_key if not provided
- _block_compare() needs to know about the theme internally; since it is a usort() callback, we cannot just add arguments to it, so I've used drupal_static() outside _block_compare() to tell it the theme to use (still defaults to $theme_key as before)
- block_admin_display_form() made $theme mandatory
- the default theme needs to be passed on to the default block config page
- NonDefaultBlockAdmin() test was looking for the stark CSS in the output (assuming theme switching), that was removed

Given how all kinds of places assumed a theme switching on the blocks page, this turned out to be a bit more extensive then originally assumed. Anyway, let's see how this passes tests. I've rerun some tests, but not all, so it might turn out it still fails some tests. Let's see.

Found whitespace issues, updated edited patch attached.

Doh, theming of the blocks admin form still assumed using the $theme_key global. Also found other instances of the $theme_key, but they were not global. To overcome any later confusion, I've renamed those to $key only. Let's run this through the tests. Again, run some tests which were failing, and looked good.

Even more tests assumed that the blocks page was to be displayed with the same theme being edited, so they looked for blocks on the same page. Fixed this by requesting a page which is in fact displayed with the theme the blocks are edited for (picked 'node'). This flied through the two failing test groups that the detailed results above point to. Let's see whether this passes now.

Ok, now that tests pass and the UX feedback was implemented, what is outstanding?