Problem/Motivation
AFAIK this hasn't been reported anywhere but there is a bug in the Admin Toolbar and its criteria of showing the "Home" / "Back to site" button, for which this doesn't work anymore on admin themed pages that don't start with a /admin/ segment in the URL.
I am pretty convinced this has been regressed after the changes introduced in the first release of core 8.4.x and more specifically by the changes in #2542050: Toolbar implementation creates super annoying re-rendering..
Steps to reproduce:
- Install Drupal via 1 of the latest core versions
8.8.xis fine for this bug. - Login as an admin and visit the front page or subsequently another page that doesn't have the admin theme to build the session storage with an item for
escapeAdminPath. - Go to an admin page and see that the first item in the toolbar shows either "Home" or "Back to site" if not the front page.
- Go to an admin page that doesn't start with a
/admin/segment eg./taxonomy/term/xxx/editor/user/xxx/editwhich are still pages that use the admin theme. See how these pages do not show the "Home" or "Back to site" button.
When executing these exact same steps on core <8.4.x the above works correct.
Screenshots:


Origin:
The bug I believe originates from the added changes in core/themes/stable/css/toolbar/toolbar.module.css:
/**
* Toolbar home button toggle.
*/
.toolbar .toolbar-bar .home-toolbar-tab {
display: none;
}
.path-admin .toolbar-bar .home-toolbar-tab {
display: block;
}
... where it was assumed that every admin themed page is identifiable with the .path-admin class. However as it turns out these are not interchangeable, because an admin themed page can perfectly fine not start with an "/admin/" segment for which that class is the actual representative, and we now end up having pages like the user edit or the taxonomy edit pages that don't have this button anymore.
Proposed resolution
Either extend the CSS classes that show the button or use a different class that is a more exact 1 on 1 representative of an admin themed page. At first I thought to extend it with another 2 selectors including .path-user and .path-taxonomy but that wouldn't be reliable or even be correct, as only the edit form of taxonomy pages are using the admin theme, and the same applies for the user entity pages.
Remaining tasks
Convert to MR
Respond to #41
Update proposed resolution
User interface changes
Add before and after screenshot here
API changes
None
Data model changes
None
Release notes snippet
None
| Comment | File | Size | Author |
|---|---|---|---|
| #44 | interdiff-3129705-35-44.txt | 607 bytes | nitin shrivastava |
| #44 | 3129705-44.patch | 8.97 KB | nitin shrivastava |
| #35 | 3129705-10.x-35.patch | 8.38 KB | alexpott |
| #28 | after.png | 63.75 KB | Munavijayalakshmi |
| #28 | before.png | 63.83 KB | Munavijayalakshmi |
Comments
Comment #2
baikho commentedComment #3
baikho commentedComment #4
baikho commentedHere is an initial attempt for a fix, but well aware there may be better approaches to this.
Comment #6
baikho commentedRight, this now breaks the layout builder tests because they are using a frontend theme and the changes in the patch do now check on
is_admin_route.Comment #7
shaktikapply patch to solved back button issue.
Comment #8
baikho commentedComment #9
pankaj.singh commentedTested and verified. Patch worked for me.
Comment #10
pankaj.singh commentedComment #11
pankaj.singh commentedComment #13
lauriiiThis is currently only added to Classy. Since this impacts the functionality of all themes, I think we should add this to system module and all core themes (including Stable)
Comment #15
johankleene commentedSlightly different solution, don't render the button when not in admin context, instead of trying to hide it through css. Could be there are some consequences that I don't see.
Comment #16
johankleene commentedFailed tests as button won't be rendered any more when not on admin pages. Adjusted tests.
Comment #17
jeroent@JohanKleene, I believe the button is hidden in CSS because of caching purposes.
I created a new patch that is based on #8 and made the changes as suggested in #13.
Comment #18
jeroentComment #19
jeroentComment #21
erik seifert commentedComment #22
aarti zikre commentedreviewing this and also confirm that this issue is found in D10 too..
Comment #23
aarti zikre commentedVerified #18 patch
Testing steps:
* created new instance of Drupal 9.5.x.
* Go to /admin/structure/taxonomy/manage/tags/overview.
* created one taxonomy.
* edit the taxonomy created in previous step.
After applying the patch still home or back to site is not visible.
Test result Fail.
Moving to need works.
Reference SS
After patch:

Comment #24
aarti zikre commentedComment #25
aarti zikre commentedComment #26
jeroentGood catch @aarti zikre,
The patch attached should fix this behaviour for Claro.
Comment #27
Munavijayalakshmi commentedComment #28
Munavijayalakshmi commentedPatch #26 resolved issue.
Comment #30
jeroentSeems lika an unrelated test fail.
Comment #32
jeroentComment #34
jeroentComment #35
alexpottHere's a patch for 10.1.x and 10.0.x - some themes no longer exist :)
Comment #36
alexpottI've discussed this issue with @lauriii and @ckrina and the consensus is that the fix is a good one.
However I've realised that we need a change record in order to tell themers with custom and contrib themes to update their html.html.twig to include this new class.
Comment #37
bramdriesenWill create the change record.
Comment #38
bramdriesenChange record created, feel free to edit some of the wording as I found this one not particularly easy to write.
https://www.drupal.org/node/3313633
Comment #39
alexpottI've rewritten the CR https://www.drupal.org/node/3313633 to more about what we want people to do rather than the bug itself.
Comment #40
bramdriesenYes, that looks a lot better! Thanks Alex.
Comment #41
alexpottHmmm... just wondering out load here but is the solution a bit complex and external to the toolbar module (where the problem lies).
I think we could change
toolbar_preprocess_html()toAnd then we could remove that changes to the templates and the other preprocess function, update the CSS for the new (more consistent class name) and not need a CR... wouldn't this be a better change?
Comment #43
jeroentComment #44
nitin shrivastava commented@alexpott,
Made changes in toolbar_preprocess_html(), as per comment #41,
Please review.
Comment #45
bramdriesenThanks for the patch. Don’t forget to set the correct status on the issue 😉
Comment #46
nitin shrivastava commentedComment #47
jeroentStill needs some work:
#41
Comment #49
quietone commentedDid a bit of triage here and this is no longer a novice level issue, mostly due to the work needed for #41.
Comment #51
baikho commentedWith Claro being replaced by Gin, I’m not sure this change is still necessary, as the issue does not occur in Gin.
Comment #52
quietone commentedThe Toolbar Module was approved for removal in #3476882: [Policy] Move Toolbar module to contrib.
This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.
The deprecation work is in #3484850: [meta] Tasks to deprecate Toolbar module and the removal work in #3488828: [meta] Tasks to remove Toolbar module.
Comment #53
quietone commentedToolbar has moved to contrib