The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Each field type should provide an exhaustive description of
- their columns and indexes (when #415044: Indexes for field storage. gets in)
- their additional behavior on hook_field_load() (additional 'columns', filtering of invalid references...)
- their field and instance settings
Each formatter and widget should provide an exhaustive description of
- their settings
- for widgets, their '#properties' (when #362058: Field Types: Make widget FAPI elements field agnostic. gets in)
Ideally, those informations should not be scattered in various PHPdocs, but gathered at the beginning of each field-type module. Not sure about the exact format and structure, proposals welcome :-)
Comments
Comment #1
Anonymous (not verified) commentedI will be posting the documentation for taxonomy term field's settings here, right? Then we can decide what structure and format is appropriate by making an object of my patch, ripping it apart and reassembling it.
Comment #2
erle commentedBeen working on this past few weeks, have some notes down. Will get down to putting down some ideas here to take this forward over this week sometime. Help, Ideas and Directions will be much appreciated, Documentation is not my forte.
Comment #3
kevindivdbyzero commentedHello... do either of you have any accumulated notes that might be useful for producing some interim documentation? There is a gaping void on this topic, and I'd love to contribute my bit towards filling the gap.
Comment #4
erle commentedhey I have some notes, been gathering info on it, I got stuck with some pressing matters and got sidetracked.
Will post sometime this weekend or early next week latest. If you have some stuff go ahead and post, or if u wish we could collaborate ?
What would be useful is if you have any ideas about the best way to present the info. ( Personally I find standard table listing hard to read ), but I suppose its where we start.
Also, thanks for the ping, Id actually forgotten about this :)
( hanging head in shame ) :)
Comment #5
erle commentedhey all, where do I post the information ?
do I just attach the file as a new post for review? Since this is doc oriented, its a listing of fields and their settings etc.. along with sample code I have used to build up stuff, which I have been collecting... could someone please point me in the right direction?
Thanks
Comment #6
yched commented@erle : great ! I'd suggest you attach what you have as a file upload in this thread (preferably in an opendoc format if it doen't fit in a plain txt file)
Also, tagging so that the documentation team can chime in about the best place to put this.
Comment #7
jhodgdonMoving to docs component, since this is apparently a purely docs issue.
So... Any file can have a @file header at the top, and this would probably be a good place to put some of this information. You can also make a group/topic for each field if that is easier.
That assumes you think the information should be on api.drupal.org. The other option would be to make a section in the online handbook for this information instead, which has advantages (easier to update, doesn't require a patch) and disadvantages (less likely to be updated if the code changes). Also, we don't want volumes of information on api.drupal.org (such as sample code, for the most part), so if you are planning on writing tutorials or code samples, drupal.org would be a better location.
Does that help?
Comment #8
erle commentedgot loads of help at the doc code sprint @ Drupalcon London 2011, thanks all . I can finally get down to contributing this in.
@jhodgdon I'm thinking, a split, a few essentials in the api not to clutter it as mentioned and will put some more detailed help, explanations and perhaps some examples too into the handbook section. I think that is the best way forward, since the docs which would into the handbook sections are mostly specific to 7.x and would likely require a change for future releases anyway.
Comment #9
jhodgdonerle: that sounds like a good plan... (#8)
And by the way, at this point you need to patch Drupal 8, and then backport to Drupal 7.
Comment #10
jhodgdonBump. Is anyone still thinking of working on this?
Comment #22
quietone commentedTriaged at a triage meeting in #documentation.
@jhodgdon asked for if anyone was interested in working on this 11 years ago and there has been no response. There I am closing.
If you are interested in adding documentation for field types, it is better to open a new issue. Thanks.