This falls under "stupid, pedantic crap that probably doesn't bug anyone other than a core maintainer." ;)
When you create a Feature through the interface, the .info file you get back looks like this:
core = "6.x"
dependencies[] = (list of dependencies)
...
description = (description)
features[content][] = (list of features)
...
name = (name)
package = "Features"
If you paw through Drupal core, however, you'll see that most .info files follow a consistent format of:
name = (name)
description = (description)
package = (package)
core = 6.x
dependencies = (dependencies)
...
...after which, I would expect things like features[], content[], variables[] and whatnot to appear.
This is just a little inconsistency that drives me nuts, so I figured I would file a feature request for it. ;P
Comment | File | Size | Author |
---|---|---|---|
#9 | features-913890-9.patch | 728 bytes | tim.plunkett |
#7 | features.913890-7.patch | 944 bytes | joshuajabbour |
#6 | features.913890-6.patch | 1.28 KB | Grayside |
#5 | features.913890.c5.patch | 902 bytes | joshuajabbour |
#4 | features.913890.patch | 870 bytes | Grayside |
Comments
Comment #1
drewish CreditAttribution: drewish commented+1... took a look at features_export_prepare() and it's doing a ksort on the whole array. i suppose we could add as some code to special case those 5 items ahead of everything else.
Comment #2
yhahn CreditAttribution: yhahn commentedYes, the ksort is so that we're not spamming repos with arbitrary key order changes. If the order above is canonical (is it documented somewhere?) I'm down with special casing these 5 lines.
Comment #3
webchickIt's semi-documented over here I guess: Writing .info files (Drupal 6.x) It's just a convention that's evolved over time.
Thanks for considering this!
Comment #4
Grayside CreditAttribution: Grayside commentedComment #5
joshuajabbour CreditAttribution: joshuajabbour commentedIt would be nice to also add php, version, and project to the special cases (otherwise they get placed near the bottom of the list. (I know version and project are discouraged, but for custom (and features) modules, they're often added manually.)
Comment #6
Grayside CreditAttribution: Grayside commentedTested #5 and it appears to work. Elements not defined in $export do not show up in the extruded .info file.
As long as we're dabbling in this area, does it make sense to slide an extra carriage return after the standard info just to help the eye run down the list or find the start of the export components? Maybe even with a heading?
Comment #7
joshuajabbour CreditAttribution: joshuajabbour commentedAttached is a reroll of #5 which checks to ensure that the export info array contains each of the listed properties. This suppresses a php error that would occur if one of them wasn't set.
@grayside: I left out your whitespace patch. I support it (actually, I think each new group within the features section should also be separated out)... but maybe it should go into another issue so as not to derail this one?
Comment #8
hefox CreditAttribution: hefox commentedHot
Patch looks good and seems to work nicely; could someone else other than joshuajabbour give it a quick test?
Comment #9
tim.plunkettWorks as advertised.
Reroll without prefixes, this applies cleanly to both D6 and D7. I guess I could just commit it to D6, but I'll give febbraro/hefox a chance at it first.
Comment #10
tim.plunkettKept #1287594: Don't wrap .info file values in double quotes as a separate issue, but same idea.
Comment #11
febbraro CreditAttribution: febbraro commentedI love nits like this. Committed to 7.x http://drupalcode.org/project/features.git/commit/2bd35f0
Tim/hefox feel free to drop it in 6.x
Comment #12
febbraro CreditAttribution: febbraro commentedComment #13
tim.plunketthttp://drupalcode.org/project/features.git/commit/8bd4231
Comment #14
webchickNice! Thanks. :)
Comment #16
Grayside CreditAttribution: Grayside commentedComment #17
Grayside CreditAttribution: Grayside commentedOops, had old version running.
Comment #18
dropfen CreditAttribution: dropfen commentedSorry for reopening this Issue, but I have to ask, do we really need to generate this "project" property in the .info file?
Since, we use features to deploy our settings, we generate lot of features. You now, the quantity of them are about 70 - 80. And when you run your update script in drush or look to the Update list in Reports, you'll see all these features you created. And them generates these notices, that the Update Information wasn't found and blabla..
So, do we really need this "project" property in the .info file? Maybe it should be a nice to have "feature" if you want it, but by default it's not needed, I think.
Thank you, dropfen
Comment #19
dropfen CreditAttribution: dropfen commentedsomeone else find it worth, to think about it?