The admin_menu provides links to each local task, and my instinct is to dig as deep as possible for the menu item I want even though for many admin pages, the "list" menu item is identical to the parent menu item. For blocks, this causes an error.

To reproduce:

Navigate to site building -> blocks -> list.
Change a block placement to a different region.
Submit the form.

Access denied!

Then try:

Navigate to site building -> blocks (not list!)
Change a block placement to a different region.
Submit the form.

Success!

Drupal bug or Admin_menu bug?

CommentFileSizeAuthor
#11 drupal.block-list-submit.patch686 bytessun
#11 drupal6.block-list-submit.patch691 bytessun
#9 drupal.block-list-submit.patch698 bytessun
#9 drupal6.block-list-submit.patch703 bytessun
#8 drupal.block-list-submit.patch696 bytessun
#8 drupal6.block-list-submit.patch701 bytessun
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

g76’s picture

g76 CreditAttribution: g76 commented

same issue. subscribing

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented

I experienced this bug myself, too. However, wasn't able to dig into the code yet. The behavior sounds more like a Drupal core issue, but we better ensure this in front moving this issue.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

The module could sidestep this issue by not rendering (or optionally rendering after the bug is fixed wherever it might be) the default local task. It's unusual among user interfaces to have two menu items in a parent-child relationship perform identical actions.

ultimateboy’s picture

ultimateboy CreditAttribution: ultimateboy commented

Same issue on several sites.. subscribing.

I do agree that this is much more of a core issue than with the d.a.m.. it is just that this module enlightened the issue and made it visible.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

Maybe it's a Drupal bug, but Drupal does not direct users to the default local task's path and admin_menu module does.

Why do I need the "List" local task to appear underneath the "Content" menu item? I think admin_menu should not redundantly render the default local task. The default local task should be left out, and we won't have this problem.

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented

@bangpound: Those default local tasks (usually "List") might be useless currently, but they will soon become the base for more awesomeness in DAM: See #293768: Allow to enable/disable menu additions - we will allow modules to implement hook_admin_menu() to indicate that, for example, admin/build/block/list should be dynamically populated with all enabled blocks via AJAX. With the result that you will save even more clicks and page loads to administer a Drupal site.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

@sun If the default local task has to be rendered, use the path of the parent menu item. Can that work?

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented
Project: Administration menu » Drupal core
Version: 6.x-1.x-dev » 7.x-dev
Component: Code » block.module
Assigned: Unassigned » sun
Status: Active » Needs review
FileSize
drupal6.block-list-submit.patch701 bytes
drupal.block-list-submit.patch696 bytes

No, this is a bug in Drupal core.

Description

When trying to submit the block configuration form on the path of the default local task admin/build/block/list instead of admin/build/block, Drupal displays an access denied page. This happens, because Block module assumes that if there is a "list" argument, there would automatically be an additional argument containing the theme name - without accounting for the fact that Block module itself registers the default local task "admin/build/block/list", which does not have a 5th argument and just displays the blocks for the current theme.

All other default local tasks in Drupal core work like they should - it does not matter whether a form is submitted on the parent path or on the path of the default local task.

Steps to replicate:

1) Visit admin/build/block/list in any Drupal 6 site.
2) Click on the submit button on the form.
3) Drupal responds with "Access denied".

Attached patches fix this bug in D7 and D6.

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented
FileSize
drupal6.block-list-submit.patch703 bytes
drupal.block-list-submit.patch698 bytes

Added parentheses to the condition.

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented
Status: Needs review » Needs work

Oh well.

It seems the install process for D7 has been fixed so there is always one theme enabled by default. I am unable to replicate this bug in latest D7.

However, before I updated my test site for HEAD, the error occurred there, too. Both in D6 and my previous install of D7, the theme selection form on admin/build/themes had no enabled checkbox in the "Enabled" column at all. Just submitting this form (even without ticking any checkbox) seems to update the system table and mark at least ONE theme enabled (which is Garland by default). After that happened, the error vanishes.

I am unsure how to proceed from here, because

a) The logic itself is basically wrong, it should check for arg(4) instead of arg(3), because the 4th argument holds the theme name, the 3rd just "list".

b) This bug seems to affect a few users of D6, so a system update would probably be a proper fix.

After further investigation, the required pre-condition to replicate this bug is:

UPDATE system SET status = 0 WHERE type = 'theme';

Which effectively means, no theme is enabled, and only the theme_default variable is set.

Thanks to webchick, who pointed me to #305653: Themes disabled during update. So either we fix a) anyway (meaning PNW), or we mark this duplicate of the other issue?

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented
Status: Needs work » Reviewed & tested by the community
FileSize
drupal6.block-list-submit.patch691 bytes
drupal.block-list-submit.patch686 bytes

Testing arg(4) instead of arg(3) is the proper logic.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented
Version: 7.x-dev » 6.x-dev

Thanks, sun! Fixed in D7. Moving back to 6.x.

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented
Status: Reviewed & tested by the community » Fixed

Committed to 6.x thanks.

Status: Fixed » Closed (fixed)

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

casperl’s picture

casperl CreditAttribution: casperl commented

This issue may be "automatically closed", but sure as heck, I am still getting "access denied" messages despite the latest Drupal 6.6 and every updated module available!

I get it when trying to re-order block menus and submitting the new arrrangement.

And yes, it is the same error when using the URL admin/build/block/list instead of admin/build/block where this error does not occur.

The Drupal Admin Menu system points to admin/build/block/lists which is how I end up on this obscure URL instead of on admin/build/block

Maybe this info is of use to someone, somewhere.

shadeshigeru’s picture

shadeshigeru CreditAttribution: shadeshigeru commented
Version: 6.x-dev » 6.6

Same here casperl i'm getting this issue using Drupal 6.6. Do i need to install the patch still or does (committed to drupal 6.x) mean i dont need to? Please let me know so i can fix this problem it's a pain.

cog.rusty’s picture

cog.rusty CreditAttribution: cog.rusty commented

Notice the dates.
D6.6 released on Oct-22
Patch committed to D6.x on Nov-3

Either apply the patch or wait for D6.7