Using the current (7.x-1.9) or the dev version, I'm completely unable to get any of the edit or list pages to display using the site's admin theme. I've tried everything I could find from other threads, including the admin_theme module, custom modules implementing hook_admin_paths_alter or hook_custom_theme with no results whatsoever.

I initially thought the issue was due to the fact, that the module currently attempts to set the $custom_theme global, which was deprecated with D7. Guidelines now mention the use of either hook_custom_theme, hook_admin_paths or using $item['theme callback'] in hook_menu.

However, after attempting all those to no avail, I started to dig a little deeper. To fix an issue with the node fields loading the latest, rather than the current field values, the field_attach_load function now includes a call to field_attach_load_revision('node', $nodes_to_be_fixed). Commenting that out fixes the admin theme issue, but leaves the original issue.

I've dug around in field.attach.inc a bit, trying to isolate the problem, but I can't seem to find a foothold. As the field_attach_load is called many, many times on each page load, my current guess is, that reattaching the fields for all nodes is somehow either overriding or removing the theme setting for the current page node.

Comments

RdeBoer’s picture

Hi afeldinger,
Thanks for your report and all your research that went into it. Looks like this is a tough nut to crack.
Rik

afeldinger’s picture

Yeah, the weird thing is, I actually tried to fix it from the theming side as well. I thought maybe by letting the field_attach_load_revision call run and then overriding the theming value at the end, I could force the theme value to re-evaluate.

But no such luck. Or maybe I just don't know the correct way of asking it nicely :)

In any event, I'd like to figure out a solution, but it's more of an annoyance to me (and by extension, my client) than an actual "this-needs-to-be-fixed-right-now". So I can't really ask them to pay for my time on this. However, it annoys me enough that I'll try to figure it out anyway – it just may take some more time than I'd like. Any help would be appreciated, even just a push in the right direction.

JimiOBrien’s picture

Hi afeldinger

Did you get anywhere with tracking this down? I find that the admin theme is disregarded only when a media module tag is inserted into a wysiwyg field. If you remove the media module tag the problem goes away. So I was searching for issues with the media sub module media_wysiwyg but as soon as I disabled the revisioning module the admin theme comes back regardless of whether any media module tags are present.

Alas for me it is a "this-needs-to-be-fixed-right-now" situation.

Jim

JimiOBrien’s picture

Hi afeldinger

You were right, reattaching the fields on the node trips the admin theme because the field filters have already been run on the originally attached fields and re-run on the newly attached fields. In my case that included "Convert Media tags to markup" or media_wysiwyg_token_to_markup().

In the first process of the field_attach_load before the revisioning module re-attaches fields the media_wysiwyg module outputs a display render array (containing $element['content']) rather than a wysiwyg field render array, this alone trips the admin theme, I don't know why yet.

So my solution was to use the drupal_alter function in media_wysiwyg_token_to_markup(), check for the existence of $element['content'] and whether the page is an admin page and add an #access => false, to the render array.

my_module_media_wysiwyg_token_to_markup_alter(&$element, $tag_info, $settings) {
  if (isset($element['content']) && path_is_admin(current_path())) {
    $element['#access'] = false;
  }
}

Perhaps this should be better suited in the media issue queue but since you haven't mentioned whether you have the media_wysiwyg submodule enabled, perhaps the description about field filters on field_attach_load at least might help somebody else with a similar situation. Certainly it was the way that revisioning re-attaches fields in hook_node_load that caused the issue in the first place, but then again I can't see any other way to do what needs to be done there.