Valid menu name is admin-menu and no admin_menu. I had problems with deleting them when tryed uninstall.

#19 admin_menu.uninstall-menu.19.patch749 bytessun
#9 admin_menu-6.x-3.x-old_name.patch6.82 KBlpalgarvio
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es). View
#10 admin_menu-6.x-3.x-new_name.patch8.64 KBlpalgarvio
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es). View
#7 admin_menu-names-v4.patch8.63 KBlpalgarvio
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es). View
#5 admin_menu-names-v3.patch7.3 KBlpalgarvio
FAILED: [[SimpleTest]]: [MySQL] Drupal installation failed. View
#4 admin_menu-names-v2.patch4.75 KBlpalgarvio
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es). View
#2 admin_menu-880640.patch4.69 KBxtfer
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es). View
Members fund testing for the Drupal project. Drupal Association Learn more


sun’s picture

Status: Active » Closed (won't fix)

Unfortunately, that's not easily possible anymore. Also, 7.x-3.x no longer uses a dedicated menu, so this issue might be revisited when someone will work on an upgrade path.

xtfer’s picture

Version: 6.x-3.0-alpha4 » 6.x-3.x-dev
Assigned: jasom » Unassigned
Status: Closed (won't fix) » Needs review
4.69 KB
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es). View

Seeing as this has direct implications for using the Alpha release, I've patched the module to rename the menu to 'admin-menu'. It seems this is a relatively simple fix for the 6.x branch.

This patch does not include an upgrade path through hook_update to rename existing menus.

lpalgarvio’s picture

Title: change menu_name od Administration menuu from admin_menu to admin-menu » rename admin_menu


just to add, to mimic Drupal 7 behavior, i think that "Administration Menu" & "admin-menu/admin_menu" should be renamed to "Management" as visible name & "menu-management" as machine name.

that way it retains the behavior and look between D6 and D7, while causing no conflict with an upgrade to D7 (where it is machine-named "management").

also, like me, some users might already have created a "menu-management" (machine name) menu. the module should check for existence of such menu and promptly skip the step of creating the menu, and just move the Administer menu inside it. perhaps make provisions for the current name, "admin_menu/admin-menu".

the D7 version of the module should delete D6 menu if it finds it ("menu-management"), and confirm that the menus have been placed in the new management menu ("management") - if they haven't, it should move them before deleting the menu.

lpalgarvio’s picture

4.75 KB
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es). View

i've modified the previous patch from xtfer to reflect the "menu-management" / "Management" names

lpalgarvio’s picture

7.3 KB
FAILED: [[SimpleTest]]: [MySQL] Drupal installation failed. View

supplying version 3 of the patch with an update path (update_6303).
it renames "admin_menu" to "menu-management" on the database when updating from older versions.

it also adds some code changes that were forgotten by xtfer.

Status: Needs review » Needs work

The last submitted patch, admin_menu-names-v3.patch, failed testing.

lpalgarvio’s picture

Status: Needs work » Needs review
Issue tags: +Management
8.63 KB
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es). View

the simpletest might have failed because of timestamps on .install.
changed those and also added new code do deal with possible conflicts on "admin_menu" vs "menu-management"

similar methods will need to be employed in the 7.x version if this patch is committed.

i tested the patch with the patch command an on a working drupal installation with admin_menu 3.x-dev, patched with this patch. it successfully updated.

The following queries were executed
admin_menu module
Update #6303

    * DELETE FROM {menu_custom} WHERE menu_name = 'menu-management'
    * UPDATE {menu_custom} SET `menu_name` = 'menu-management', `title` = 'Management', `description` = 'The <em>Management</em> menu contains links for administrative tasks.' WHERE `menu_name` = 'admin_menu'
    * UPDATE {menu_links} SET `menu_name` = 'menu-management' WHERE module = 'admin_menu' OR menu_name = 'admin_menu'

the target installation had both an existing user created "menu-management" menu as well as the "admin_menu" menu.

lpalgarvio’s picture

Title: rename admin_menu » rename 'admin_menu' menu machine name

changed title to a more logical name

lpalgarvio’s picture

Issue tags: -administration menu +Management
6.82 KB
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es). View

jcnventura told me to remake a version of the patch, the plan A, that changes the name to "admin-menu" instead, so that less changes are required.
posting that patch.

lpalgarvio’s picture

Assigned: Unassigned » lpalgarvio
Issue tags: -Management +administration menu
8.64 KB
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es). View

and here i post a final version of the patch, the plan B (with a few changes), with the name changed to "menu-management".

it is up to the maintainers to accept or not one of these patches and if so, choose whether they want to name the menu "admin-menu" or "menu-management".

for reference, they apply to the current 6.x-3.x-dev version (2010-Sep-15)
have fun reviewing.

sun’s picture

Status: Needs review » Needs work
Issue tags: -Management

Hold on. What's the actual problem here?

I had problems with deleting them when tryed uninstall.

That's the only problem. The 'admin_menu' menu is not removed in admin_menu_uninstall(). But it should.

However, prior to blatantly deleting the menu, we need (or should) check for any 'customized' menu links in the menu not belonging to 'module' = 'system'. Not really sure what can be done if we find some, but at the very least, we can only delete the menu if there are none of those.

lpalgarvio’s picture

admin_menu is an invalid name. it can't be renamed, edited or deleted.

it should use a hifen, not a underscore. hence the patch to make it "admin-menu" or "menu-management".

the patch does not attempt to delete the menu on uninstall (only during update, covered by one of the 3 ifs), but attempts to rename it to a valid name.

it also helps on a ugprade path (plan B)

sun’s picture

admin_menu is an invalid name. it can't be renamed, edited or deleted.

Please explain why it is invalid. Of course, it cannot be renamed, edited, or deleted, because the module depends on it, so this behavior is intentional, and also an intentional feature of Drupal's menu system.

lpalgarvio’s picture

as far as i know / tested, it can't be edited, even when admin_menu is absent, because of the underscore.

by editing, i mean, change the title (not machine name) and description.
by renaming, i mean changing the machine name.

IMO, it would be a lot easier to maintain the 6.x-3.x and 7.x-3.x versions if they had more in common.
the menu machine name, title and description is an example of what can be kept in common.

there are a lot of references to this machine name "admin_menu", HARDCODED in the code, meaning is more hard to maintain between the 2 versions, as they use different names. also, the "admin_menu" string appears a lot, not just in the machine name, which sometimes causes me confusion while reading the code.

i would say it would be a lot easier to not hardcode the menu name, at least use a string in the code, or instead pick the name dynamically (use a selection box to choose the menu name in the admin interface - an example of this box can be seen with the admin_role module, which allows setting the administration role), and by populating a admin menu that resembles that of D7 core admin menu - hence my idea for "menu-management", aka, "Management".

i will again note, that by using "menu-management" or "admin-menu" as a machine name, there are no issues with upgrades to D7, no problems with edition, renaming or deletion.

i will also state, as the 3.x line is in alpha version, perhaps it can be considered non-freeze yet, so the name could perhaps be changed with no major issues.
the patches also cover potential problems between upgrades of existing 3.x/alpha versions to this patch version.

i don't see drawbacks in committing one of these patches. it is my opinion anyways.

sun’s picture

Title: rename 'admin_menu' menu machine name » 'admin_menu' menu not removed upon uninstalling / re-installing the module

Unfortunately, the menu system in Drupal 6 still contains many deeply hidden bugs (see project page). I fixed most of them in Drupal 7. You probably do not know of these bugs in detail. A management summary of the current state would basically be: Don't try to perform heavy menu changes, because they will very likely have unintended side-effects and consequences.

Since no one cared for resolving those bugs in the menu system of Drupal 6, and the chance for getting those changes in is getting more unlikely to happen with every day we're closer to Drupal 7 being released, I doubt that Drupal 6 will ever be fixed.

In turn, it's unlikely that admin_menu for Drupal 6 will ever get out of alpha. It works as long as core's menu system works. And that's it.

Therefore, I've resorted to consider certain patches for D6 only: (1) All patches not related to menu system functionality. (2) Patches that fix bugs in the current implementation.

Which means:

- Leaving a stale 'admin_menu' menu behind upon uninstalling the module is a bug.

- Allowing to edit, change, or even re-assign the menu being used is a feature.

This direction only applies to Drupal 6. Contrary to that, 7.x-3.x is actively developed and will have a stable release very soon (at which point we'll also remove the big note on the project page).

To fix the actual bug, we need to implement the fix that was roughly outlined in #11; i.e., make sure that the menu is removed upon uninstalling the module. Meanwhile, I came to the conclusion that any custom links we find in the menu simply have to be moved to the 'navigation' menu.

lpalgarvio’s picture

so basically, the developers will work on removing altogether the new menu, also remove it with uninstalls, with "Administer" remaining at "Navigation" menu... leaving up to the user the decision to move around or not, be it safe or unsafe, the "Administer" tree. right?

that would work too :)
better no extra menu, than a buggy menu

a few notes:
- in admin_menu 1.x, i had no problems moving "Administer" elsewhere, for example, to a "menu-management" menu
- i found no major issues with admin_menu 3.x (both D6 and D7) (except some nuisances with cache, but that was reported elsewhere)
- moving the "Administer" menu around to some other menu, in the 3.x version (D6), does break the menu render, so probably that should be noted in the project page or readme for D6 until that code is patched/removed.
- in the D7 version, it does not seem to break it. however, the core toolbar menu (in my install, but might just be a cache problem or some bug) does break if you move around administer (it reads menus from the management menu only. empty => shows nothing).
- my patch/modified admin_menu does work for me, so i'm happy.

i will wait for that future version (in which the code is patched/removed) to update on my end.

// EDIT:
some of the unintended side-effects and consequences are menu trees disappearing entirely when running cron or clearing caches. basically your administer menu gets partially or wholly FUBAR.
as why this happened some times, but did not other times, is a mystery - it worked okay for about a week. multiple updating, croning, cache clearing and other tasks might have triggered the bugs.

recommending the use of the 1.x line unconditionally
a remark - while you can't get the looks of the 3.x in the 1.x series (without massive recoding), you can get the Views without any issues:
just copy the views directory to your 1.x admin_menu and change the version on it
it should work okay (it has at least for me for more than a month)

bryrock’s picture

This is true also in 7.x-3.0-rc1 (that admin_menu does not uninstall). Its variables are deleted but the schema is not dropped entirely, so an empty table persists.

lpalgarvio’s picture

Assigned: lpalgarvio » Unassigned
sun’s picture

Status: Needs work » Fixed
749 bytes

Committed attached patch to 6.x-3.x.

Status: Fixed » Closed (fixed)

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