Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Admin_menu appears to be included in the page cache, and not replaced by authcache or personalized... this is a small problem for variable roles... after all, visiting an /admin page is usually not cached, and Drupal will deny you inappropriate access. But it is a problem for the big "Hello username" that appears in the corner, which is incorrect and points to the wrong account.
Since this is such a popular module, it makes sense to have support for it.
Comment | File | Size | Author |
---|---|---|---|
#7 | 2281665-admin-menu-toolbar-7.diff | 6.96 KB | znerol |
#5 | 2281665-admin-menu-toolbar-5.diff | 7.63 KB | znerol |
#5 | interdiff.txt | 5.08 KB | znerol |
#4 | 2281665-admin-menu-toolbar-4.diff | 3.18 KB | znerol |
Comments
Comment #1
znerol CreditAttribution: znerol commentedSorry for the delay.
Admin Menu uses the page cache in a rather clever way. For each variant (user / role combination) a new hash is calculated and stored in the JavaScript setting
Drupal.settings.admin_menu.hash
. The hash is appended to the Ajax callback used to load subtrees. This ensures that different subtrees are recorded in the cache for different users/role combinations.However, on pages cached by authcache, the JavaScript settings will be the same for all users having the same authcache-key (role combination). If an admin hits a subtree which was cached by another admin having the same roles, the user-name of the other admin will be displayed.
There are two ways to fix this problem:
js/admin_menu/cache/*
in Administration » Configuration » System » Authcache » Page Caching SettingsComment #2
jh sio CreditAttribution: jh sio commentedIs Admin_menu the same as the core Toolbar module?
I've been attempting to implement hook_preprocess_toolbar() with authcache_user, but I'm struggling to understand how to get settings.authcacheUser in the javascript to actually have values set.
I realize that using the authcache_usercookie example works to dynamically replace the username, but I'd like to avoid setting extra cookies just for this.
Also, what's the difference between p13n settings, assemblies, and fragments?
Comment #3
ioskevich CreditAttribution: ioskevich commentedExcluding js/admin_menu/cache/* in AuthCache's page caching settings did the trick for me.
Comment #4
znerol CreditAttribution: znerol commentedOk, adding
js/admin_menu/cache/*
to the list of paths which are excluded by default.Also implemented replacement of the user-name in the toolbar. This is indeed a bit tricky because the toolbar is in the
page_top
region. This region is rendered from within template_process_html. However, at this point in timeauthcache_p13n_preprocess_html
already collected all authcache fragments/settings and assemblies and therefore the JS bits from authcache user were not added to the page. Movingauthcache_p13n_preprocess_html
to a pre-render function solves that problem.Comment #5
znerol CreditAttribution: znerol commentedAlso add support for the shortcut module: Load them via Ajax if a user has the permission to switch the shortcut set.
Comment #7
znerol CreditAttribution: znerol commentedHu?
Comment #9
znerol CreditAttribution: znerol commented