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.
Problem/Motivation
While investigating whether https://www.drupal.org/node/2642848 needs to be forward ported (it needs to) I found the call chain to whitelist rebuild be absurdly long and of course such a long call chain ought to contain a bug: system_path_delete does not pass the source so the whitelist is always rebuilt on alias delete. That's quite a performance hit.
Proposed resolution
Trival: pass the $path['source']
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#11 | 2645036_11.patch | 3.44 KB | chx |
Comments
Comment #2
oriol_e9gComment #3
chx CreditAttribution: chx at Tag1 Consulting commentedComment #5
chx CreditAttribution: chx at Tag1 Consulting commentedGrr!
Comment #6
Wim LeersWow, great find! Looks like a sane (and simple!) fix. Still needs test coverage though.
Comment #7
chx CreditAttribution: chx at Tag1 Consulting commentedComment #8
tim.plunkettFor those concerned: hook_path_update/hook_path_insert was already passing the $path, it just wasn't used here.
This is a nice trick. +1
I've never once used this. I don't think it's needed (i.e., it is automatic)? If you don't have these, and the code does something to violate the shouldBeCalledTimes() expectations, doesn't the test fail
Comment #9
chx CreditAttribution: chx at Tag1 Consulting commentedSure, the test fails without checkProphecyMethodsPredictions but at the same time your assert count goes up if it's there. So, I dunno, I'd rather keep it. Explicit is better than implicit.
Comment #10
dawehnerThe reason why you need to call
checkProphecyMethodsPredictions
is because you have 1 test for 3 different things.Just split it up, then you don't need to deal with that.
Comment #11
chx CreditAttribution: chx at Tag1 Consulting commentedSplitting saves us little: you need to insert to update and to delete. And it has nothing to do with the checkProphecyMethodsPredictions calls. The reason I didn't want to remove it was -- it's not in the destructor so I didn't see clearly how it gets checked and the byzantine overengineered phpunit is makes it very hard to find where it is but actually phpunit does the same check eventually. Sane people would expect it in tearDown where the phpspec docs recommend it but phpunit, no, for some bizarre reason it calls TestResult::run (why does the result run the test?) which eventually threads its way back to the TestCase::runBare where runBare has a verifyMockObjects which since 3.5.0 also happens to verify prophecies despite its name. So much fun...
Removed the explicit calls. I am glad this is well documented.
Comment #12
dawehnerSeems alright for me now. Splitting it up would be nice but I see the point of being a bit of pointless.
Comment #13
alexpottCommitted 9aff04c and pushed to 8.0.x and 8.1.x. Thanks!
Comment #16
Wim LeersPer IS.
Comment #18
zaporylieI have created a very simple followup to this old-ish issue: #2917505: Drupal\Tests\system\Kernel\PathHooksTest uses incorrect @group