Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
toolbar.module
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
30 Jul 2014 at 16:21 UTC
Updated:
5 Nov 2014 at 13:17 UTC
Jump to comment: Most recent
Comments
Comment #1
dawehnerGreat cleanups!
Comment #2
alexpottCommitted 2283584 and pushed to 8.0.x. Thanks!
Comment #4
wim leersThis is indeed a wonderful clean-up — thanks, olli!
I have only one concern:
Shouldn't the removal of these two hooks be replaced by setting the
array('extension' => TRUE)cache tag?It's strictly speaking unnecessary, but only because (un)installing modules clears all caches. It's better to be explicit about the dependencies.
Comment #6
wim leersI'd still love feedback regarding #4.
Comment #7
olli commentedGood question. I found only views using that tag and that it gets invalidated when theme info is refreshed which happens on module/theme (un)install but the code comments refer to clearing library info which does not use it. It's also deleted by views on module (un)install. This happens on every module/theme (un)install while these hooks were invoked after the modules were (un)installed. It's not clear to me when should I use that tag. I think we could:
a) remove the tag
b) add/improve docs for it
c) improve docs for testModuleStatusChangeSubtreesHashCacheClear in case module (un)install stops clearing all bins.
What do you think?
Comment #8
wim leersThe reason those hooks were listening for module (un)installation, is because modules can implement
hook_toolbar(), which can add things to the toolbar.However, I didn't realize we had
ToolbarAdminMenuTest::testModuleStatusChangeSubtreesHashCacheClear(), which indeed proves that it's still working fine, because module (un)installation clears all caches. In which case I think we should do #7.c) :)Thanks!
Comment #9
wim leers