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
\Drupal\Core\Plugin\Discovery\YamlDiscovery
fails to handle empty files.
The result of the YAML-parsing is NULL
for empty files but YamlDiscovery
performs a foreach
of the parsing result. (See line 50.)
Proposed resolution
Add a check for NULL
and skip the file in this case.
Remaining tasks
User interface changes
API changes
Comment | File | Size | Author |
---|---|---|---|
#17 | drupal_2331407_17.patch | 4.07 KB | Xano |
#17 | interdiff.txt | 685 bytes | Xano |
Comments
Comment #1
tstoecklerComment #2
dawehnerShould we mention that this can happen also in case you have just comments in your file? On addition we could fix this also in the component itself, so check in findAll() that the result is actually an array.
Comment #3
damiankloip CreditAttribution: damiankloip commentedYes, I was going to say the very same. Is this something we generally want. However, this will just make the whole key for x module disappear. Is that what we really want? Rather than just an empty array for x module that has an empty file?
Comment #4
tstoecklerI'm not 100% sure I understood #3 correctly, but I think this patch is what #2 and #3 are referring to.
I like the suggestion a bit better than #1 myself, so thanks for that! I tested that this also fixes the mentioned use-case.
Still needs tests, though.
Comment #5
damiankloip CreditAttribution: damiankloip commentedComment #7
dawehnerMh, so according to Yaml::decode this could throw an exception, should we maybe catch here and convert it to an array? (just curious)
<3
Comment #8
tstoecklerRe #7: Actually the exceptions that are thrown are if either the file is not readable or if the YAML is invalid, (i.e. if you use tabs, or if you mix maps and sequences in a single array, etc.) which I think we should not silence, but which should surface, just as they do now.
Comment #9
damiankloip CreditAttribution: damiankloip commentedAgreed, that sounds like the behaviour we want.
Comment #11
XanoDude, a ternary operator without short array syntax? ;-)
Nice one!
Comment #12
alexpottI think this falls into the trap that http://fabien.potencier.org/article/48/the-php-ternary-operator-fast-or-not details. Potentially the array could be very large.
Comment #13
XanoThanks for the link! I removed the ternary operator and explained why we thought it was a bad idea to use it.
Comment #14
dawehnerGood point!
Comment #15
tstoecklerRe #12: Because we are not saving the file contents into a variable, the ternary should not be slower, as there is no copying involved.
Can still stay this way, of course, regardless.
Comment #16
XanoIf there are no actual reasons to go with one approach or the other, we shouldn't introduce code comments that say there are. I tested by rebuilding caches using the following code and the differences are usually no more than several tens or hundreds of seconds, with the occasional >1s difference, but nothing that significantly indicates one approach is faster than the other.
Comment #17
XanoHere's #5, but with short array syntax.
Comment #19
damiankloip CreditAttribution: damiankloip commentedSo in light of tstoeckler's comment in #15 and Xano's comparisions, I think this is good.
Comment #20
alexpottIt appears this problem has been solved in php5.4 - see http://3v4l.org/QuDvY/perf#tabs.
This issue is a normal bug fix, and doesn't include any disruptive changes, so it is allowed per https://www.drupal.org/core/beta-changes. Committed e8e84d7 and pushed to 8.0.x. Thanks!