PHP notice on admin/build/modules
sun - June 28, 2009 - 01:03
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | base system |
| Category: | bug report |
| Priority: | critical |
| Assigned: | sun |
| Status: | closed |
| Issue tags: | Registry |
Description
Fix that, please.
| Attachment | Size |
|---|---|
| dev.patch | 743 bytes |
| Testbed results | ||
|---|---|---|
| dev.patch | passed | Passed: 11853 passes, 0 fails, 0 exceptions Detailed results |

#1
We dug a bit deeper in IRC about this, and it turns out this only occurs the first time the page is loaded that a new module is in there it doesn't know about yet.
As best we can tell, this happens because http://api.drupal.org/api/function/system_get_files_database/7 is querying the database, and there's no record of the module there yet.
So while sun's patch will mask the issue, it seems like there might be something deeper...
#2
Not RTBC.
http://api.drupal.org/api/function/system_get_files_database/7 is invoked to apply further properties to each module, but the registry does not know of new modules at this stage. So file_scan_directory() returns modules the registry doesn't know of yet.
Tagging.
#3
We want to invoke system_get_module_data() here (once) to scan and update the available modules. Needs testing of the installer though.
#4
... but we also want to add a static of some sort to system_get_module_data() in order not to traverse the whole file tree twice in search of modules.
#5
@4
Actually, we do it 3 times already :) (twice with system_get_module_data() and the registry does it directly to save update queries that we don't execute anymore).
I tried to implement the static cache in #147000-30: Regression: Unify and rewrite module_rebuild_cache() and system_theme_data() already, but failed because simpletest had issues with that and I didn't wanted to delay that issue.
#6
The last submitted patch failed testing.
#7
I changed the registry_rebuild() function in #429132: Remove unecessary module_rebuild_cache() call from _registry_rebuild(), now that we optimized system_get_module_data() (And will hopefully further improve it), we can revert that, I think. Not that you can also remove the ini file parsing stuff then.
#8
Adding a static cache and getting the tests working seems to be hard, so I just reverted my patch in _registry_rebuild() for now.
#9
That was the wrong patch...
#10
And now the correct status...
#11
Looks clean and fixes issue.
#12
I like the resulting code much better. I think according to Berdir in #7 that the performance hit isn't as great anymore, but I'm sure catch will inform us if that's not the case. ;)
Committed to HEAD!
#13
Automatically closed -- issue fixed for 2 weeks with no activity.