This is a spin-off from #610204: Overlay API changes. See comments 16-21 of that issue. There are some situations (for example, within an overlay), where a module wants to stop the toolbar from being displayed. This is done easily enough with a hook_page_alter()
function that sets $page['page_top']['toolbar']['#access'] = FALSE
. However, with the current code in HEAD, the toolbar still gets built in this situation, which is wasteful. The suggestion from that issue was to move the toolbar build step to a #pre_render function. Patch coming in a follow-up comment.
Comment | File | Size | Author |
---|---|---|---|
#1 | toolbar-delay-build-612974-1.patch | 2.18 KB | effulgentsia |
Comments
Comment #1
effulgentsia CreditAttribution: effulgentsia commentedHere's the patch. In running benchmarks, I also discovered that in a situation where the anonymous user has access to the toolbar (admittedly, unlikely), warnings are triggered when building the "Hello USERNAME" link. This patch solves that by building a different link, more appropriate to an anonymous user.
The benchmark I ran was a fresh install of HEAD with the default profile, adding a single node of the Page type (title = "Title", body = "Body"), and enabling all permissions for the anonymous user. I also created and enabled a dummy module whose only code is:
With this setup, on my computer (running MAMP, so not a production server), running "ab -c1 -n100 http://localhost:8888/d7/node/1", I got:
HEAD + just the last 2 hunks of this patch (needed to turn off PHP notices): 93.0 +/- 2.1
HEAD + full patch: 89.0 +/- 2.2
Comment #2
moshe weitzman CreditAttribution: moshe weitzman commentedCode and benchmarks look good.
Comment #3
webchickYum! Thanks! Committed to HEAD. :)
Comment #4
yched CreditAttribution: yched commentedApplied to #563562: Batch API pages should not show the toolbar