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.The current implementation breaks with Commerce Product UI as well as various other modules which expect certain array keys in their entity_info_alter() implementation without explicitly checking for their existance.
The attached patch solves the problem by doing a more verbose and exact check using a full (but fake) entity info array for the checks.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | uuid_features-array_replace_recursive-2342803-8.patch | 2.35 KB | Peacog |
| #5 | fix_array_merge-2342803-5.patch | 476 bytes | MatthewHager |
| uuid-features-dependency-discovery.patch | 4.41 KB | fubhy | |
Comments
Comment #2
das-peter CreditAttribution: das-peter commentedInteresting and complex approach.
Committed to latest dev.
@fubhy Is this something we might need to extend to other entity types as well?
Comment #3
fubhy CreditAttribution: fubhy commentedI was actually wondering why there wasn't a generic approach for dependency detection for all supported UUID Features Entity Types. At the same time I didn't want to overdo it in this issue as I was not trying to extend the functionality but merely to fix the error that appeared in conjuction with Commerce Product UI.
Dependency detection could actually also be extended to automatically support other modules that fiddle with the entity property info. Like entity cache, various i18n related stuff, etc.
Comment #4
MatthewHager CreditAttribution: MatthewHager commentedThis doesn't support multiple entities in multiple FPP bundles. On line 138, there is a specific check for an array that is part of fieldable_panels_panes that causes a white screen.
PHP Fatal error: Unsupported operand types in /var/aegir/platforms/test/sites/all/modules/contrib/fieldable_panels_panes/fieldable_panels_panes.module on line 138Comment #5
MatthewHager CreditAttribution: MatthewHager commentedI've fixed the issue. When you have multiple FPP bundles the array merge on line 186 causes all sorts of duplicates that don't need to be there and cause issues in later lines where strings are expected instead of arrays that get created by the merge. I've replaced that function with array_replace_recursive which won't create duplicates where the keys are the same. This has resolved all the issues and the module appears to work properly.
This is my first patch attempt ever :D, if accepted will also be my first Drupal contribution.
Comment #6
das-peter CreditAttribution: das-peter commented@MatthewHager There's one slight problem:
array_replace_recursivewas introduced in php 5.3, the official requirement for Drupal is 5.2.5 (although 5.3 is recommended).But what about
drupal_array_merge_deep, could do this the trick? Would be great if you could give it a test.Comment #7
JonMcL CreditAttribution: JonMcL commentedThis patch, which is currently in DEV, is triggering a rash of notices for me:'
It might just be a matter of adding a
isset($backup[$bundle])to line 240, but I don't know enough about this module (or of Features internals') to suggest that is the right solution.Comment #8
Peacog CreditAttribution: Peacog commentedThanks for the array_replace_recursive() fix. I've included a fix that defines an alternative version of the function for PHP versions lower than 5.3 (with code taken from the Language Dropdown module). Is this an acceptable solution?
I also fixed another bug that was writing a weird line:
__drupal_alter_by_ref[][fieldable_panels_pane][fieldable_panels_pane] = fieldable_panels_paneinto my feature's .info file.I've haven't seen the errors mentioned in #7.
Comment #10
das-peter CreditAttribution: das-peter commented@Peacog Thanks for the updated patch. I've replaced the implementation of
array_replace_recursivewith one actually handles all arguments and not just two. If we mock a php function we have to ensure it works as expected (I hope this one does).