Support from Acquia helps fund testing for Drupal Acquia logo

Comments

casey’s picture

Forgive me, but I don't see what you mean :p

yoroy’s picture

dashboardlinkmissing

marked #721328: Dashboard link no longer appears in the toolbar duplicate:

When the toolbar and dashboard modules are enabled, a "Dashboard" link used to appear in the top left of the toolbar.

Following the commit at #652122-21: Acces to dashboard permission required to access Management menu this is no longer the case. I assume that was an unintended side effect.

yoroy’s picture

Priority: Normal » Critical

marked #721326: Link to Dashboard is gone now that dashboard lives at /admin a duplicate, but bumping this to critical because we should not release D7 with this kind of stuff happening.

David_Rothstein’s picture

So basically, the fix here is just to make the toolbar and management menu exact mirrors of each other, right? (And hopefully, that results in ripping some ugly code out of the toolbar module too.)

Doing that now would result in the "Add content" menu item showing up in the toolbar too (which as I recall, was the reason the toolbar didn't do it this way in the first place?). However, that would likely be taken out by #408160: Normal users should not see the create content link appear by default in a menu called "Management", which is another critical issue already.

In other words, I think we want:

MANAGEMENT
* Content
* Structure
* Appearance
* etc

This raises the interaction question of how a user gets to /admin (or /admin/index, or whatever it is going to become) from that menu, but the same issue exists now in the case where you have the Toolbar module enabled but not the Dashboard - I don't believe there's any good way to get to the "Administer" screen in that case except by breadcrumbs. So that part needs to be solved either way.

cosmicdreams’s picture

subscribing.

horncologne’s picture

Subscribing.

sun’s picture

The /admin (Administer) item cannot be taken out of this menu and has to stay where it is.

For one, users without Toolbar and Dashboard and whatnot, need to have a way to access admin/ in the first place. If there is no link to /admin, you can't reach the sublinks.

Second, our menu system is fragile. Especially when it comes to translating menu router paths into menu links and deriving menu names and menu link parents. If you try to move /admin, you are opening a big, really big can of worms. See also #550254: Menu links are sometimes not properly re-parented

Off-topic for this issue, but for quite some time already, I wanted to suggest that we should rather prohibit altering menu links below /admin. I.e. lock the entire Management menu.

David_Rothstein’s picture

Status: Active » Needs work
FileSize
6.37 KB
60.76 KB
60.18 KB

Perhaps we can just leave Administer in that menu, then, and pull everything else out?

The attached patch is more or less the same patch I proposed last year at #508458: Config and modules page. The code is a bit ugly, but the code it removes is pretty ugly too :) Plus hopefully it makes some sense since we already allow router items to specify their default menu.

Issues with this:

Screenshot of patch with the Dashboard module disabled - a direct link to Administer winds up in the toolbar:

patch-with-dashboard-disabled.png

Screenshot of patch with the Dashboard module enabled - that link is replaced with a Dashboard link, as intended:

patch-with-dashboard-enabled.png

sun’s picture

ugh.

  1. The "Administer" link makes no sense. I really don't like how this patch destroys the hierarchical structure of administrative links.
  2. Speaking of hierarchical administrative links, this change to menu links will ultimately break breadcrumbs, even if we manage to get the other patch in that fixes them.
  3. Meanwhile, I think that Toolbar should stop trying to "build a menu slice". It is no menu. It's a list of links. Dead simple.
David_Rothstein’s picture

Believe me, I'm not in love with it either, but we need something :)

I seem to remember the problem with having the Toolbar use a separate list of links is that there would then be two competing administrative lists (Management menu and Toolbar) that do not stay in sync at all. I'm not sure the Toolbar should have its own IA that doesn't apply anywhere else.

Also, assuming that "Administer" page migrates to something more like a site index at the other issue, then it won't be as weird and won't necessarily destroy the hierarchical structure - admin/index is on the same level as everything else (even if /admin points to it as well).

The breadcrumbs aren't (yet) broken with this patch any worse than they are already broken, and in some ways are better. Are you sure it will break things in the end? The patch doesn't really do anything that a site administrator can't already do on their own with the Menu module, so if the breadcrumb system can't handle it, that seems like a bigger problem.

sun’s picture

Breadcrumbs are based on menu links. By moving those links to the top-level of the menu, the indication of being in the administrative area of the site is completely lost.

Yes, breadcrumbs are currently broken in HEAD. However, (not so) recent changes that (more or less) went in for admin_menu, and the patch over in #576290: Breadcrumbs don't work for dynamic paths & local tasks will finally fix them.

Note that I personally like the change to move the sub-items to the top-level. However, that change would be yet another hack, with the sole purpose of supporting one of the new UX features. Effectively breaking other valid use-cases for a natural, hierarchical menu link tree structure below /admin in contrib and Drupal distributions.

At the very least, the "Administer" item would have to move to the Navigation menu. (And Dashboard would have to hook_menu_alter it into the Management menu, or ideally, rather, remove that entire bad hack of overriding an existing, fundamental core menu item)

sun’s picture

Status: Needs work » Needs review
FileSize
2.13 KB

Due to #550254: Menu links are sometimes not properly re-parented, you need to run the following query on an existing site to see the result:

DELETE FROM menu_links WHERE router_path LIKE 'admin%'

New installs work just fine.

Status: Needs review » Needs work

The last submitted patch, drupal.management-menu.12.patch, failed testing.

catch’s picture

# Meanwhile, I think that Toolbar should stop trying to "build a menu slice". It is no menu. It's a list of links. Dead simple.

Yes I've been saying this for months now, using the menu system for those links only causes countless issues and workarounds.

sun’s picture

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

#12: drupal.management-menu.12.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, drupal.management-menu.12.patch, failed testing.

sun’s picture

Status: Needs work » Needs review
Issue tags: +D7UX

#12: drupal.management-menu.12.patch queued for re-testing.

Gábor Hojtsy’s picture

@sun: your approach to move the actual items to display to the management menu instead of the parent admin path looks reasonble. It lacks a way to go to the admin overview/dashboard page though. This might not be an issue in the toolbar but it will be for users without that attempting to use the management menu block, right?

sun’s picture

Only if you choose to hide the Navigation menu. To clarify, the new flow is:

1) Click "Administer" in Navigation.

2) See "Management" popping up (if that menu block is enabled).

3) Click further through "Management".

Bojhan’s picture

@sun Can you provide some images please :)

Gábor Hojtsy’s picture

@sun: how does this approach solve the missing Dashboard link in the toolbar that was the starter problem in this issue?

sun’s picture

See #11:

At the very least, the "Administer" item would have to move to the Navigation menu. (And Dashboard would have to hook_menu_alter it into the Management menu, or ideally, rather, remove that entire bad hack of overriding an existing, fundamental core menu item)

With this patch, we can remove that ugly hack, and just make Dashboard use admin/dashboard. Display in the toolbar as "Dashboard", displayed in the regular Management menu block as "Dashboard", and there's no strange, unpredictable, or hard to account for behavior in core.

People can click "Administer" and get the usual administration page.

People can click "Dashboard" (most likely in the Toolbar) and get the dashboard.

Gábor Hojtsy’s picture

@sun: yes, we added the dashboard in that way originally and some people insisted on overriding the main admin page instead. I thought dashboard can be a standalone thing and not the admin index, but that was ruled out for some reason. I've reopened #652122: Fix dashboard as the default /admin local task for a rollback. Seeing you've also supported the rollback previously so I've re-enumerated the reasons for rolling it back.

sun’s picture

Right. So this patch should be RTBC.

Bojhan’s picture

@sun Can't set it RTBC without images :)

sun’s picture

aspilicious’s picture

hahaha, sun that is not nice ;).
But I'll apply it and post some screenshots!

aspilicious’s picture

FileSize
67.05 KB

Do I need patch in #652122: Fix dashboard as the default /admin local task
Because I get the screenshot as result and I don't think that is a good thing...

sun’s picture

The actual change for Toolbar wasn't contained yet, right.

The "Dashboard" link may appear at a wrong position (not first), but that will be fixed in #652122: Fix dashboard as the default /admin local task

Bojhan’s picture

@sun No screenshot, still.

aspilicious’s picture

Cause I am not able to show a decent one, need a fresh install... (again).
I'll be back soon.

aspilicious’s picture

FileSize
57.16 KB

Well it wasn't my fault...
Patch isn't working...

I can't see the dashboard link AND everything is in the wrong order.

(Or am I doing something wrong :( )

sun’s picture

Did you apply the patch before or after installing Drupal? If after, then you need to force the menu system to rebuild administrative links by executing the query in #12 and rebuilding the menu afterwards.

aspilicious’s picture

I did it *before* the install.
First I did it after, I wasn't sure about the result, so I cleared my localhost version, did a fresh checkout, applied the patch, installed drupal again.

I'll do it once more just to confirm my results...

aspilicious’s picture

Status: Needs review » Needs work

Triple checked, patch isn't working

Scott Reynolds’s picture

Status: Needs work » Needs review
FileSize
64.69 KB
mysql> DELETE FROM menu_links WHERE router_path LIKE 'admin%'
    -> ;
Query OK, 240 rows affected (0.08 sec)

And as mentioned previously things are out of order.

Scott Reynolds’s picture

Status: Needs review » Needs work

Forgot to mark CNW

Scott Reynolds’s picture

The reason why its failing to show the dashboard link its because the $item['link']['hidden'] = -1 for admin/dashboard.

Scott Reynolds’s picture

FileSize
47.99 KB

And this is because dashboard_menu_alter() makes it the default local task for admin/

Which using the menu system, it then will not pass the bit mask check for visible menu item and thus it won't show up.

This is solved with this additional patch. I have mucked up my Drupal git so I need to reset it from the start. But this makes the Dashboard item show up.

https://gist.github.com/ff5c6ad993d5c6c18032

aspilicious’s picture

Where is the find content in the shortcut bar?
Why are the items in a new order?

sun’s picture

Status: Needs work » Postponed

Alright, postponing on #652122: Fix dashboard as the default /admin local task

Sorry for not realizing this hard dependency earlier.

Bojhan’s picture

So I discussed this in length with tha_sun and although the technical difficulties are immense in any other way.

We broke apart Administrative links into "Management" and Site links into "Navigation" - because testing showed that these blended together created a lot of confusion. This patch breaks this concept, by putting an administrative link into Management. Arguably its only 1 link, however the problem that it causes could be greater - since it destroys the mental model of Navigation being for the anonymous visitor.

YesCT’s picture

#41 says this is postponed waiting on #652122: Fix dashboard as the default /admin local task, but 652122 says that it can be fixed by this issue.

so it seems 652122 is waiting on this... like circular logic?

yoroy’s picture

Status: Postponed » Needs work

Unpostponing this, just because we have to revisit this, rather sooner than later.
I think the original reasons for postponing this should be pointed out (is that in #39?), then decide again which issue needs fixing first.

Damien Tournoud’s picture

Priority: Critical » Major

I'm not sure what remains to be done here, when the two other issues will get in:

I'm not sure this one qualifies as a critical bug. The toolbar is generated from the elements below the 'Administer' link. This is by design. We could change the Management menu (as previous patch in this issue do), so that all the links are top-level, but the current behavior doesn't feel like a critical bug to me.

Downgrading to major.

yoroy’s picture

What needs to be done is that the link to the 'Dashboard' needs to be put back into the toolbar.

Damien Tournoud’s picture

@yoroy: the link in the toolbar should be handled by #652122: Fix dashboard as the default /admin local task

arianek’s picture

subscribing so i can try and catch when this gets fixed and update the text/screenshots here http://drupal.org/handbook/modules/toolbar, since we didn't realize this was a bug until i started asking around why there was no way to get to the dashboard...

if someone knows for certain what menu title will be in the toolbar, what permissions it'll depend on, and has a screenshot, i'd much appreciate that info being posted to http://drupal.org/node/652304 so the associated handbook docs issue can get re-closed. thx!

sun’s picture

Status: Needs work » Needs review
FileSize
4.54 KB

Re-rolled against HEAD.

Status: Needs review » Needs work

The last submitted patch, drupal.management-menu.49.patch, failed testing.

David_Rothstein’s picture

Status: Needs work » Needs review
FileSize
5.77 KB

admin/content and admin/help were missing from the patch, so I added those in.

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

The last submitted patch, drupal.management-menu.51.patch, failed testing.

sun.core’s picture

Status: Needs work » Needs review

#51: drupal.management-menu.51.patch queued for re-testing.

Status: Needs review » Needs work
Issue tags: +D7UX

The last submitted patch, drupal.management-menu.51.patch, failed testing.

geerlingguy’s picture

I just upgraded from a D6 to a D7 site, and as I stated in #865702: Broken admin pages/links after upgrade if "Administer" was not in the "Navigation" menu, there are no links at all (besides the "Hello username" and "Log out" links) in the top toolbar. Shortcuts seem to work properly. Is this problem related to this issue?

virgo’s picture

Havin same problem as #55 comment, any info ?

siliconmeadow’s picture

@geerlingguy & @virgo: I have had the same problem. I've gone through this whole thread in detail and found that cleaning the menu router table as per #12 above solved my problem. I'll have a look around further and see why that's not executed during update.php. Might need a patch to the menu module's install file?

sun’s picture

Version: 7.x-dev » 8.x-dev

Meh. Everyone will have to live and work with this mess for the next couple of years.

quicksketch’s picture

Title: Items in the top level of the 'management' menu disappear from toolbar » Make the entire 'management' menu included in the toolbar instead of slicing the menu for "admin/" paths.
Category: bug » feature

I think Damien's comment in #45 sum this up quite nicely. I'm going through issues re-categorizing them now that major and critical bugs are actually preventing development of Drupal 8 (See #1050616: Figure out backport workflow from Drupal 8 to Drupal 7). This is actually more of a functionality change than fixing a bug, as the actual bugs have already been addressed (other than the item sun mentions in #12, which is part of the critical bug #550254: Menu links are sometimes not properly re-parented). Please re-re-categorize if needed.

sun’s picture

With #594660: Rename default menu names, the 'management' menu actually turns into the 'admin' menu, typically containing all links to paths that begin with 'admin/*'. That patch is quasi-RTBC, just needs someone other than me to actually mark it as that.

Given that, this patch here makes even more sense. To recap:

  1. Move the "Administration" link into the user menu. (user menu is renamed into 'account' menu)
  2. That inherently moves all administrative links to the top-level of the Administration menu.
  3. The toolbar simply fetches the first level of the 'admin' menu. (and so does admin_menu module, but without limit.)
  4. Optional: Add a visibility constraint to 'admin*' for the 'admin' menu block, so it is only output when you are on or below the path 'admin'.

Deal?

Bojhan’s picture

Yup!

johnv’s picture

Status: Needs work » Needs review
FileSize
4.85 KB

Attached is a recent D7-version of this patch. I'll try and create a D8-version, too.

sun's comment #12 is still valid:

Due to #550254: Menu links are sometimes not properly re-parented, you need to run the following query on an existing site to see the result:
DELETE FROM menu_links WHERE router_path LIKE 'admin%'
New installs work just fine.

@#60: on my D7-test, removing the '/admin/' path from management, moves it to 'navigation', not 'account'.

johnv’s picture

This is the D8 version.

Status: Needs review » Needs work

The last submitted patch, toolbar_596010_63_D8_management_path.patch, failed testing.

johnv’s picture

Version: 8.x-dev » 7.x-dev
Status: Needs work » Needs review
FileSize
6.28 KB

This is a better D7 version.

sun’s picture

Title: Make the entire 'management' menu included in the toolbar instead of slicing the menu for "admin/" paths. » Move "Administration" link into Account menu and make Toolbar output first level of 'admin' menu
Version: 7.x-dev » 8.x-dev
Component: toolbar.module » menu system
Category: feature » task
Priority: Major » Normal
Issue tags: -D7UX +Usability, +API clean-up
FileSize
6.13 KB

@johnv: Please do not post D7 patches. This change will not get backported to D7.

Attached patch implements #60. Includes additional diff context lines to ease patch reviews.

sun’s picture

Issue tags: -Usability, -API clean-up
FileSize
28.77 KB

#66 works as expected:

admin-menu-root.67.png

However, we'll have to enhance/fix the system_admin_menu_block() page callback that is used to produce the content for the admin/index + admin/tasks pages. With this patch, those pages output "You do not have any administrative items." The cause for this is that system_admin_menu_block() uses menu_get_item() to retrieve the menu_name of the listing page and dynamically creates the page output based on that router item/menu link. Since the menu_name is different now, it does not find any child links.

sun’s picture

Attached patch additionally adjusts system_admin_menu_block_page() to optionally accept a custom menu router $item that is used instead of menu_get_item() for building the list of links in the page content.

Status: Needs review » Needs work

The last submitted patch, drupal8.admin-menu-root.68.patch, failed testing.

sun’s picture

Status: Needs work » Needs review
FileSize
7.42 KB

Ugh. Life is full of surprises :-/

Breadcrumb Home » Administration » Structure » Taxonomy found on /admin/structure/taxonomy/tags.

By moving Administration into a different menu, the resulting breadcrumb is Home » Structure » Taxonomy. That's obviously not what we want. :(

I see two possible ways out:

A) Dynamically inject it into the breadcrumb via System module on all /admin/* paths.

B) Rewrite the menu, menu links, and breadcrumb subsystems in order to allow a menu to be hierarchically located as a child of another menu link. I.e.: The menu link for /admin has a child "link" tree that is the 'admin' menu. Or in other words: Nested menus.

Since B) obviously is a major undertaking, attached patch implements A).

Status: Needs review » Needs work
Issue tags: -Usability, -API clean-up

The last submitted patch, drupal8.admin-menu-root.70.patch, failed testing.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

Issue summary: View changes
Status: Needs work » Closed (outdated)

There hasn't been any discussion here in 11 years. I don't work on the menu system but I will go out on a limb and say that the changes in the last 11 years make this outdated. If there is still things to do here then a new issue should be opened.

Thanks