Problem/Motivation

If "Use the administration theme when editing or creating content" is unchecked on the Appearance settings, it will be ignored for any content type with the machine name 'group'. The admin theme will still be used on node/add/group. This only happens when og_ui is enabled.

Steps to reproduce

  1. Install a clean Drupal 7 with only og and og_ui enabled (you'll need Entity API).
  2. Create a content type named "Group" (leave the default machine name of 'group'). Make it a group type.
  3. Go to Appearance and uncheck "Use the administration theme when editing or creating content" at the bottom.
  4. Navigate to node/add/group.

You should notice the admin theme is still in use, even though you've completed #3. Navigating to any other node/add form, you should see your default (non-admin) theme. You will even see the default theme on node/%/edit, where % is the nid of a Group node. Disabling og_ui will stop the bug from happening.

This is because in og_ui_admin_paths() of og_ui.module, 'node/*/group' is set as an admin path. This makes sense because in most cases the second argument ('*') is the nid of a group. In this situation, however, it is causing this bug.

Proposed resolution

Simply adding 'node/add/group' to $paths in og_ui_admin_paths() will not work because it will always force the default (non-admin) theme on this page, even if the theme option mentioned above is checked to true. The only way I see fixing this bug from within the module is by expanding the function to:

/**
 * Implements hook_admin_paths().
 */
function og_ui_admin_paths() {
  $paths = array(
    'node/*/group' => TRUE,
    'group/*/*/admin/*' => TRUE,
  );
  if (!variable_get('node_admin_theme')) {
    $paths['node/add/group'] = FALSE;
  }
  return $paths;
}

This does, however, involve an extra variable_get on any pages that aren't cached.

If the above (or a solution in general) does not make it into the module, others experiencing this problem can add this to a custom module:

/**
 * Implementation of hook_admin_paths().
 */
function custom_module_admin_paths() {
  $paths = array(
  	'node/add/group' => FALSE,
  );
  return $paths;
}

Note that this won't respect switching the node forms back to the admin theme (see above).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

guschilds’s picture

Version: 7.x-1.5 » 7.x-2.x-dev
Status: Active » Needs review
FileSize
378 bytes

I just confirmed that this still exists in the 7.x-2.x branch. Attached is a patch for this branch containing the fix mentioned in the description.

amitaibu’s picture

+++ b/og_ui/og_ui.moduleundefined
@@ -452,6 +452,9 @@ function og_ui_admin_paths() {
+  if (!variable_get('node_admin_theme', 1)) {

Why do you set 1 as the default value?

guschilds’s picture

I set the default value as 1 because the option (set in Appearance) is always enabled by default.

I just installed a clean Drupal 7 and node_admin_theme is in the variables table as 1.

amitaibu’s picture

But in other places in Drupal core you see the variable_get() without default value.

guschilds’s picture

Good call, thanks for looking so quickly and pointing that out.

Also, I must have botched testing the original patch. I don't think I was adding to the $paths array appropriately. Both have been fixed in the attached patch.

What do you think?

guschilds’s picture

Issue summary: View changes

Fixing example code from comments #1 to #5.

drumm’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: +affects drupal.org

Looks good to me, and we are using this on some Drupal.org sites.

greggles’s picture