This is a followup to my previous posting (http://drupal.org/node/637998) about adding a debug feature to prepopulate that make it much easier to figure out what the edit[] parameters are. Attached are a patch to the dev version of 2009-Oct-28 (and a full version of the module) that dumps out a nicely formatted list of all the possible edit[] parameters that looks something like this:
edit[nid] (value)
edit[vid] (value)
edit[uid] (value)
edit[created] (value)
edit[type] (value)
edit[language] (value)
edit[changed] (hidden)
edit[title] (textfield)
edit[body_field][teaser_js] (textarea)
edit[body_field][teaser_include] (checkbox)
edit[body_field][body] (textarea) <-- note that this shows the body_field exception!
edit[body_field][format] (fieldset)
edit[body_field][format][1] (radio)
edit[body_field][format][2] (radio)
edit[body_field][format][4] (radio)
edit[base] (fieldset)
...
edit[base][dimensions][dim_length] (textfield) <-- here's an example of an ubercart field
...
edit[field_aspect][0] (text_textfield) <-- and this is a CCK field
...
This info is only displayed if there is at least one edit[] parameter in the url, plus a "prepopulate-debug" parameter.
Enjoy!
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | prepopulate.zip | 11.61 KB | MadOverlord |
| prepopulate.module.zip | 1.25 KB | MadOverlord | |
| debugpatch.patch | 1.46 KB | MadOverlord |
Comments
Comment #1
MadOverlord commentedAh, something's screwed up. The above patch kills the ability to edit nested fields (ie: edit[title] works, edit[blah][dork] doesn't).
No idea why it's doing that, the only difference between a version based off the current main release and the dev release seems to be that the dev release is using $_REQUEST instead of $_GET. This may be a bug in the dev release not related to my patch.
In any case, here is a hacked version of the current main release that implements the prepopulate-debug feature properly (I hope!)
Comment #2
MadOverlord commentedOne headsup - this debugging output apparently does not give info about multiple-entry fields such as images and links -- the kind of thing where there's a button to add more fields, and you can drag the fields around. These are internally implemented in a different way and my walk routine doesn't find them.
However, in this situation you can just look at the raw html and find the info pretty easily, it'll end up being something like "edit[field_reviews][0][title]", "edit[field_reviews][1][title]", etc.
Comment #3
jbrauer commentedThis looks like an interesting patch. The use of $_REQUEST instead of $_GET is an intentional change and not a bug. It was added in #242749: Support for POST method. What I'd like to do with this concept is implement it similar to the way FCKditor shows the field name next to each field in the input form.
Comment #4
MadOverlord commentedSorry for the miscommunication, I wasn't implying that use of $_REQUEST was the bug, just that it was the most obvious change. But you might want to check the current dev release to see if nested field editing still works. Probably some screwup of mine but you never know.
My implementation is of course a quick-and-dirty hack and no doubt there's a more elegant presentation.
Oh, one other thing I noticed yesterday: on those multiple entry reorderable fields (mentioned in post #2 above), you can prepopulate the first of the two fields that are presented as default, ie: edit[field_reviews][0][title]=derf, but not the second. The obvious argument (from the html), edit[field_reviews][1][title]=derf does not work.
Comment #5
scuba_fly