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.So we've had several issues regarding the change to the extensionStorage::getComponentNames function where it now requires an array of Extension objects rather than just names. (see #2497155: getComponentNames must be of the type array)
However, now that we've patched the error messages, Features no longer works. After exporting stuff to a Feature, those components are not listed as part of the Feature when you try to edit it.
The problem is that the patch in #2513788: Fatal error when features added to site doesn't handle loading a non-enabled Extension. Looking into this now.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | features_cannot_read_existing-2532390-3.patch | 1.12 KB | mpotter |
Comments
Comment #1
mpotter CreditAttribution: mpotter commentedComment #2
mpotter CreditAttribution: mpotter commentedWow, it appears that drupal_get_filename() does not return any path info for a newly exported module because the file listing is cached. After a "drush cr" then this properly returns the path to the module.
Comment #3
mpotter CreditAttribution: mpotter commentedWhat a mess. So drupal_get_filename() relies on the system state system.module.files to determine if a module file exists. This state is set in system_rebuild_module_data() by running a scan for modules. However, the $listing->scan() function itself has a static cache using static class variables instead of drupal_static. Thus, there is no way to clear this static cache to force scan() to return a new list of files.
After the features are exported, the next page load will re-run the scan, but will not update the system.module.files state.
So, to fix this we are forced to update the system.module.files state variable itself as we export packages. That is done in this patch.
Seems kind of kludgy and I wonder if core is also going to run into issues with the way all of these file scans are being cached. There is a core Meta ticket about this mess here #2186491: [meta] D8 Extension System: Discovery/Listing/Info. Need to keep an eye on how this progresses in D8.
Another solution would be to replace drupal_get_filename() in FeaturesManager::listExtensionConfig() with something that didn't use the system.module.files state as a cache.
Comment #5
mpotter CreditAttribution: mpotter commentedOK, committed this to 3242f13. I'm not going to try and work-around the drupal_get_filename() since that fundamental to drupal.org. If they ever provide a way to properly clear this cache we can change the code in the Generation function, but for now it does what we need to update the cache.