Subpathauto causing admin pages to appear in default theme

I have the same issue with Views 3.5 on Drupal 7.15 or Drupal 7.16
Everytime I save a view, the admin theme is not loaded, the default one is. I have to reload the page so that the admin theme appears again.
I spent a lot of time trying to figure out what was causing this and when I finally disabled sub-pathauto I worked back as normal.
The problem also appears after executing update.php and then following the link to administration pages.

Here are the keywords I was typing on Google and that didn't lead me here, maybe this will make others who have the same problem arrive on this thread.
admin theme not loading
admin theme not showing
views admin theme not loading on save
views admin theme not select on save

simple fix

<?php 
/**
 * Implementation of hook_init().
 */
function MODULE_NAME_init() {
	global $theme;
	$arg0 = arg(0);
	$current_path = current_path();
	$admin_theme = variable_get('admin_theme', 'none');
	$init_redirect = FALSE;
	
	if (user_access('administer views')) {
		if ($arg0 == 'admin') {
			if ($theme != $admin_theme && $init_redirect == FALSE) {
				$init_redirect = TRUE;
				drupal_goto($current_path);
			}
		}
	}
}
?>

Here's what I was searching for:

drupal features admin/structure/features not using admin theme

I found a similar issue that had occurred with the domain module ( http://drupal.org/node/1419090 ).

fix from #2 worked for me.
I added it in subpathauto.module file
I personnally don't understand the code but I really think this should be fixed directly in sub path auto and committed.

The reason is quite complicated. The reason this happens is because on some pages (such as saving a view) the variable menu_rebuild_needed is set to TRUE. This means that on the next call to menu_get_item() the menu cache is being rebuilt.

subpathauto_url_inbound_alter() calls menu_get_item() and does this before the theme system is initialized. Building the menu tree calls the l() function, which initializes the theme, but does not initialize the custom theme (see drupal_theme_initialize()). So that is why on some pages the regular theme is used.

The fix in #2 is very views specific. I tried some work-arounds, but the simplest is to set menu_rebuild_needed to FALSE temporarily when calling menu_get_item().

The function becomes:

/**
 * Implements hook_url_inbound_alter().
 */
function subpathauto_url_inbound_alter(&$path, $original_path, $language) {
  // If the current menu item exists at this path, then we should not continue
  // processing.
  // menu_get_item() may initialize the theme system when a rebuild is needed.
  // Ignore this rebuild because it initializes the theme too early.
  if ($menurebuild = variable_get('menu_rebuild_needed', FALSE)) {
    variable_set('menu_rebuild_needed', FALSE);
  }
  $item = menu_get_item($path);

  // Restore the menu_rebuild_needed variable.
  if ($menurebuild) {
    variable_set('menu_rebuild_needed', TRUE);
  }

  if (!empty($item) && $item['href'] == $path) {
    return FALSE;
  }

  if ($source = subpathauto_lookup_subpath('source', $path, $original_path, $language)) {
    $path = $source;
  }
}

If a full patch is needed, please let me know.

The bug was introduced here: #1691054: Sub-pa shouldn't recursively check existing aliases.

#5 Function seems to fix the problem.

Here's #5 as a patch. It worked for me.

Works for me.

Wow. I started noticing that this was happening a few weeks back and was browsing the Subpathauto issue queue for totally unrelated reasons, only to find this. Good work! :)

I just applied this patch and I'm still seeing some issues. When I go to edit a node, it shows the edit form using the default theme instead of the admin theme (checked theme settings and they're correct, should use admin theme for edit forms). If I click the "Edit" tab again, it correctly loads in the admin theme.

I don't think it is the same bug, but it may be so. I never experienced this myself.

I'm also experiencing the same issue. I have not applied any patched. By disabling Subpathauto, saving a view would correctly load the admin theme not the front end theme. However, I do need my paths for edit user profile to be user/[username]/edit instead of user/1234/edit.

Sinan

I have improved the patch because variable_set() creates an exclusive lock on the variables table, causing performance issues. I now modify the $conf variable, which has the same effect during the page view.

I don't think the patch above or any solution that tries to fix the usage of menu_get_item is a good solution. I think it is simply not a good idea to use menu_get_item here, for the reasons mentioned in other issues with the same cause (like [1419090]).
So I propose to remove the check if there is a menu item with the current path and just go forward with the redirect. The Redirect module behaves the same way, you can add redirects for existing menu items except for admin paths.

Both #14 and #15 seems to have fixed the problem

But for the following use case, #15 caused some undesired effect :

1. A node having alias "about"
2. A view having a page display with path "about/branches"
3. When navigating to "about/branches" :
   • #15 showed the node page (same as "about")
   • #14 (as well as 1.3 release) showed the view page (as desired)

Hi all,
to add my 5 cents to the case :
1) calling menu_get_item in the hook_url_inbound_alter causes the issue because the theme may not be initialized at this point as this is called from drupal_path_initialize() from _drupal_bootstrap_full() in inclides/common.inc

2) menu_get_item at some point might invoke hook_permission which results in calling dashboard_permission that calles l function and if variable_get('theme_link', TRUE) is true then it will initialize the theme.

so what i did was to change subpathauto_url_inbound_alter() :

/**
 * Implements hook_url_inbound_alter().
 */
function subpathauto_url_inbound_alter(&$path, $original_path, $language) {
  if (!defined('MAINTENANCE_MODE') || MAINTENANCE_MODE != 'update') {
    global $theme;
    if (!isset($theme)) {
      menu_set_custom_theme();
    }
  }

  // If the current menu item exists at this path, then we should not continue
  // processing.
  $item = menu_get_item($path);
  if (!empty($item) && $item['href'] == $path) {
    return FALSE;
  }

  if ($source = subpathauto_lookup_subpath('source', $path, $original_path, $language)) {
    $path = $source;
  }
}

as copied some login from _drupal_bootstrap_full().
This way i would initialize the custom theme if the theme is not initialized to if someone calls drupal_theme_initialize() it will have correct custom theme as in the case with the "l" function.
Maybe I should call drupal_theme_initialize() here as well , not sure.

Kind Regards

Attached is a patch with the changes noted in #17 above. I tested this locally against the 7.x-1.3 branch and so far things are looking good.

I can confirm that the patch in #18 fixes the issue with Features UI being displayed in default theme.

Patch provided in #18 resolves my issue with openlayers admin (#2212141: /admin/structure/openlayers/maps/list/[map]/edit doesn't keep administration theme)

Can this be committed please?

Thank you very much

If you are using menu token, patch 18 causes an infinite loop when you try to edit your menu items.

Patch #18 fixed it for me as well. Please merge!

I'm encountering theme switch to default theme after save a views view.
#18 fixes the issue.

Cross-referencing #2347825: CustomError causing admin pages to appear in default theme, where the same issue occurs with the CustomError module due to a call to menu_get_item() from hook_custom_theme().

Great module, but I also encountered the theme switch to default theme after save a views view.
#18 fixes the issue.
Please commit the patch from #18.

I'm having problems with colorbox/colorboxnode after applying patch #18. Has anyone experienced issues too?

Thanks for the patch, #18 works for me.

#18 patch verified (again) to work, had this problem after saving views, features, even nodes.

Patch #18 works great!

Can also confirm that patch #18 works great.

Thank goodness that is fixed. Thanks for the patch #18 works perfect like a charm!

The patch has been around a while now, any chance of getting the fix committed? Thanks!

Patch #18 works for me, and I'm doing some tricky re-routing stuff in a custom way. Great patch. Thanks a bunch.

Hey @brian@256ideas.com did you ever resolve the issue with colorbox/colorbox_node?

I am also having a problem where it breaks colorbox_node and throws the error:

An AJAX HTTP request terminated abnormally.
Debugging information follows.
Path: www.example.com/colorbox/node/157/delete?width=500&height=300&iframe=true
StatusText: error
ResponseText: 
ReadyState: 0

Will look into it and see what I find to fix this.

Ah, I also get the same as #21 an infinite loop on menu token module links... causes a major problem because they can't be deleted or edited after the initial creation.

I have retested and patch #15 by Volx is a much better solution for us. It has been holding up with no problems. Unfortunately, patch #18 broke colorbox node module and also caused an infinite loop when trying to edit or delete menu token items as seen in this issue.

Hoping we can push #15 as the better solution? I noticed comment #16 here though mentioned some issues with #15 patch though? I haven't experienced problems like that; sub path auto is correctly working on our system with patch #15 (also fixes admin theme original issue).

Thanks everyone!

Patches 14, 15, 18 didn't work for me at all.

Who knows, maybe I have some more active modules causing the same issue.

Patch #2 fixed at least my views problem. Thnx!

According to all comments here I thing it's not apropriate to keep status of this issue as "Reviewed & tested by community".

"Needs review" (or even "Needs work" maybe ?) seems to fit better.

Ok for me with the patch #18 and several modules : Openlayers...

Thanks.

Patch #18 solved the problem also here on several pages having admin_theme troubles with features ui and views. Is the problem related to any other contrib module or cache setting, because we have a lot of `not working` comments.

Patch 18 works for saving views.

A good explanation of the issue here: https://www.deeson.co.uk/labs/curious-incident-wrong-theme-being-used-af...

Attached is a patch to get around the issue of menu_get_item rebuilding the menu and triggering the wrong theme.

New patch with fixes to failed tests.

Patch at #44 is working very well for me. I think it's a fairly elegant solution (only do the minimum amount of work, instead of the full menu_get_item step).

My vote is for RTBC, but maybe others want to chime in?

Thanks JonMcL,

I've been using this patch now on (semi)production for a couple weeks now. Seems to be stable. RTBC OK?

Two things: 1. it shouldn't have commented out code, 2. it shouldn't reference a blog post with a really long URL and should instead have a clear comment that explains what the problem is.

Updated patch with improved commenting attached.

Thanks,
I have applied patch from #48 and until now, it solved this issue for me.

Thanks!

Chiming in to say that the patch in #48 works perfectly for me.

Hi,
Patch #48 works for me.
Thanks!

Minor improvements to the comments.

Hi,
patch #53 works great for me. +1 for RTBC
Thanks

Patch #53 is working for me. Would be great if this could be released so this nice module works appropriately out of the box!

For those who are not using the Subpathauto module, but are having a similar issue (admin/structure pages going to default theme), I created a module with #2 and it has resolved the problem. I plan on figuring out which module I'm using is causing the issue when I have time. But for now, thanks mirgorod_a... Works great 6 years later.

patch 53 works for me, and for another problem that I believe is connected: I have some content types which are entity translated, with title module installed to translate title into other languages. it happened that after installing subpathauto module, the node title was no longer translated and remained in the default language, while the rest of the content body was correctly translated. After a long troubleshooting and after applying patch 53, the node title is translated again. Maybe the problem was because subpathauto_url_inbound_alter called menu_get_item too early. Thanks for the patch.

I note this is still an issue with Subpathauto for Drupal 7 and that Patch #53 solved it.