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.During the Panels upgrade sprint, I noticed that when panels_node.info looked like this:
name = Panel nodes
description = Create nodes that are divided into areas with selectable content.
package = "Panels"
dependencies[] = panels
configure = admin/build/panels
core = 7.x
then entry on the module page looked like this:
But when I added just one little line:
name = Panel nodes
description = Create nodes that are divided into areas with selectable content.
package = "Panels"
dependencies[] = panels
configure = admin/build/panels
core = 7.x
files[] = pooper.module
it works just fine:
Hopefully the problem here is obvious (there's no pooper.module!) - without at least one files[] entry, a module gets marked as invalid somewhere. When the full registry was in, this made sense, but since we've rolled the registry back to only encompasses class autoloading, I don't see why a class-less module ought to have to declare any files. Looking through other core .info files, it seems like we've just silently ignored the question of whether files without classes still ought to be listed in .info files. At the very least, the documentation isn't helpful, since it's really just a whole lotta strikethrough.
So, what's the verdict? Do we still need to list files[] even if there aren't classes in them? Or is it safe to loosen that requirement - in which case, we need to patch core so that modules aren't erroneously listed as incompatible?
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | update_remove_files_check.diff | 565 bytes | jmiccolis |
| #2 | info-files.patch | 1020 bytes | bleen |
Comments
Comment #1
sdboyer CreditAttribution: sdboyer commentedChanging to bug report.
Comment #2
bleen CreditAttribution: bleen commentedThis patch should fix the issue ... I can't see any reason why we still need the
if (empty($info['files']))hereLets see what testbot thinks
Comment #4
Damien Tournoud CreditAttribution: Damien Tournoud commentedIndeed, we don't need that anymore. That's a remainder of the removal of the function registry.
Comment #5
Dries CreditAttribution: Dries commentedGood catch. Committed to CVS HEAD. Thanks.
Comment #7
mattyoung CreditAttribution: mattyoung commentedBut the documentation is not fixed:
http://drupal.org/node/542202#files
and here
http://drupal.org/update/modules/6/7#registry
Comment #8
marcingy CreditAttribution: marcingy commentedOnly http://drupal.org/node/542202#files needs changing and has been updated to note that files are now optional. The other link is still correct as you still need still need to declare files containing interfaces and classes.
Comment #9
aspilicious CreditAttribution: aspilicious commentedI thought this was by design LOL
Comment #10
mattyoung CreditAttribution: mattyoung commented#8:
I still see in http://drupal.org/node/542202#files:
In http://drupal.org/node/394070
This is confusing. It's not required and it's not optional. Can we make it plainly clear when "files[]" are necessary? Is "files[] = mymodule.module" even necessary at all if there is no function registry anymore?
I feel this issue should be active until the documentation is fixed. I am beginning to update my modules to D7 and the first problem I run into is what to do with the .info file.
Comment #11
bleen CreditAttribution: bleen commentedthere is no reason not to reopen this for the docs
Comment #12
mattyoung CreditAttribution: mattyoung commentedOne of the thing that confuses me is "loadable code files", what are they? Aren't all php code files loadable? If that are files containing classes and interfaces, then just say that instead. It would make things much clearer.
Also how about removing the strike through text? They don't mean anything anymore and it just add confusion.
Comment #13
jmiccolis CreditAttribution: jmiccolis commentedIt appears that update.inc has a check for the files array as well. You can see this in action as modules with no entries for `files[]` will be disabled by a visit to `update.php`.
Comment #14
yhahn CreditAttribution: yhahn commentedI can confirm that this patch fixes the
update.phpproblem. Marking as major since the current bug causes many contrib modules to be turned off just by runningupdate.php.Comment #15
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Thanks.
Comment #16
jmiccolis CreditAttribution: jmiccolis commentedAs bleen pointed out in comment 11 - this still needs docs to be updated. Re-opening.
Comment #17
jhodgdonPlease just go edit those pages. This is not a Drupal Core / documentation issue. It is a Handbook documentation issue. So if you don't want to edit the pages yourself, please file a new issue in the Documentation project, so we can leave this one in Drupal Core for tracking.
Thanks!