In the Field module in field.module for the method field_bundle_settings the comment states an example for the array structure. For view_modes the example is view_modes->full->custom_display, but it should be custom_settings instead, since that is being used as you can see for example in the method field_view_mode_settings (line 653ff.).
Comment | File | Size | Author |
---|---|---|---|
#12 | 1454266-interdiff-12.txt | 1.44 KB | Niklas Fiekas |
#11 | D7-field-bundle-settings-docs-1454266-11-do-not-test.patch | 3.19 KB | Chaulky |
#11 | field-bundle-settings-docs-1454266-11.patch | 3.21 KB | Chaulky |
#8 | field-bundle-settings-docs-1454266-8.patch | 3.21 KB | Chaulky |
#5 | field-bundle-settings-docs-1454266-5.patch | 605 bytes | Chaulky |
Comments
Comment #1
Niklas Fiekas CreditAttribution: Niklas Fiekas commentedThanks, Volx!
Moving to 8.x. Patches need to get into D8 first and are then backported. Needs work and +Novice for the straight forward reroll.
Comment #2
jhodgdonfixing component and tags
Comment #3
Chaulky CreditAttribution: Chaulky commentedRerolled the patch against current 8.x (commit: 9e8d1e85) and 7.x (commit: f10acf95).
Comment #5
Chaulky CreditAttribution: Chaulky commentedOh yea... shouldn't ignore just because it's documentation. Still needs to actually apply correctly. Reattached patches with proper names
Comment #6
Chaulky CreditAttribution: Chaulky commentedComment #7
jhodgdonYou know, this whole documentation block is written in a non-standard way.
First off, it is describing the $settings parameter, so it should be part of the @param $settings section, not its own paragraph.
Second, normally we document structures like this using the documentation list format (see http://drupal.org/node/1354#lists), something like this (will need to be wrapped appropriately):
Could someone please make a patch with this rewrite in it? Thanks! And as usual, I would suggest just doing 8.x to start, and waiting until we have an accepted patch before embarking on 7.x (saves time and effort).
Comment #8
Chaulky CreditAttribution: Chaulky commentedRemoved the code example from the description section of the function documentation. Greatly enhanced the @param entry for $settings and added types to all @params and @return according to new D8 standards (http://drupal.org/node/1354#functions). Patched against latest 8.x (commit: faa63d22).
The language for $settings feels a little awkward to me, mostly because there are just so many arrays at work here. I think this patch gets the point across, but I'm open to suggestions for improvement.
Comment #9
Niklas Fiekas CreditAttribution: Niklas Fiekas commentedThank you, Chaulky. That looks awesome.
The missing
.
is the only flaw I could find. @jhodgdon: Can you find anything else? Otherwise I'd say RTBC, after that is fixed.Comment #10
jhodgdonI noticed this:
it's -> its
and this:
it's -> its; if -> is
Otherwise (and the missing period noted above) -- looks great, thanks!
Comment #11
Chaulky CreditAttribution: Chaulky commentedI've made the corrections from #9 and #10. I also attached a patch for D7 that makes the exact same changes. I left in the types on @params and @return even though technically that wasn't the standard recommendation in D7. I can remove those for D7 if necessary, but thought it couldn't hurt to leave it in.
Comment #12
Niklas Fiekas CreditAttribution: Niklas Fiekas commentedRTBC, because the interdiff looks just as good as the patch.
Comment #13
Chaulky CreditAttribution: Chaulky commentedNow that it's marked for backport to D7, should I attach the D7 patch with the correct name for testing and switch the version over to 7.x? Technically, the changes are exactly the same unless we want to remove the types from @params and @return.
Comment #14
Niklas Fiekas CreditAttribution: Niklas Fiekas commentedLet's first wait until it's committed. That's better than switching back and forth between 7.x and 8.x.
Comment #15
jhodgdonRight, it's best to wait until it's committed. Much of the time, the 8.x patch can be directly applied to 7.x, and you don't even have to create a 7.x patch. In other cases, the committer can find the 7.x patch with the odd name, and go ahead and commit it (especially if it's just documentation, not much worry about breaking core etc.).
Speaking of which... I just committed this to both 8.x and 7.x. Thanks!