If I'm using the admin theme for editing content, then the "choose language to translate to" screen (node/%/translate) should use the admin theme too. Otherwise I get a jarring switch from admin theme (edit) -> site theme (translate) -> admin theme (edit).

Patch and test included.

Comments

drifter’s picture

Status: Active » Needs review
drifter’s picture

StatusFileSize
new1.89 KB

Sorry, n00b mistake - submitting patch again for the test bot.

gábor hojtsy’s picture

Looks like a good idea. It might be better to somehow generalize this though, since other contrib actions might want to have the same? This would solve it for core, but what about other contrib modules?

drifter’s picture

Well, where would it make sense to do so? Add an 'admin theme' key to hook_menu, which will trigger the admin theme if TRUE?


  $items['blog/feed'] = array(
    'title' => 'RSS feed',
    'page callback' => 'blog_feed',
    'access arguments' => array('access content'),
    'type' => MENU_CALLBACK,
    'admin theme' => true
  );

Or go further and allow hook_menu to specify an arbitrary theme?

  $items['blog/feed'] = array(
    'title' => 'RSS feed',
    'page callback' => 'blog_feed',
    'access arguments' => array('access content'),
    'type' => MENU_CALLBACK,
    'theme' => variable_get('admin_theme', 0)
  );

Or maybe hook_menu is the wrong place to define this?

drifter’s picture

I see there is a related issue: #346573 Setting administration theme visibility by path and role (other then /admin and content editing now) - which works similarly to the block visibility settings, allowing more pages to use the admin theme. It's a more generalized solution, and doesn't involve hook_menu :)

Then again, I do feel that node/%/translate belongs to the "node editing pages", and you shouldn't need to specify it explicitly.

seutje’s picture

I agree with drifter that we shouldn't explicitly need to do it for this page as it is obviously part of editing content but we do need those underlying mechanisms for allowing contrib modules to specify which pages are admin pages, but I think we would need to split it up in admin_page and node_admin_page so we can still take in account if the user has the "Use the administration theme when editing or creating content" option enabled

joris_lucius’s picture

I couldn't find this that fast for D6. But, if you want also want this implemented in D6, use hook_init in your module:

/**
 * Implementation of hook_init().
 * We use this to get the core translate overview in backend theme.
 */
function MODULENAME_init() {
  if (arg(2) == 'translate') {
       global $custom_theme;
       $custom_theme = variable_get('admin_theme', 0);
  }
}

(not extensively tested yet)

Status: Needs review » Needs work

The last submitted patch failed testing.

adraskoy’s picture

solution in #7 works for me in D6. I added it into the i18n_init, just after the check to see if this is the front page.

drifter’s picture

Status: Needs work » Fixed

Drupal 7 has hook_admin_paths() - it solves this problem too, so marking it as fixed.

http://api.drupal.org/api/function/hook_admin_paths/7

Status: Fixed » Closed (fixed)
Issue tags: -#d7ux

Automatically closed -- issue fixed for 2 weeks with no activity.