body doesnt work

try using

edit[body_filter][body]=this is the body

in the URL to set the body.

This is a quirk in the way Drupal forms are created, and not a bug in Drupal or prepopulate. I do think, however, that it's less than ideal (particularly since the HTML source of the page does not give a clue).

That it worked before was a consequence of the sub-optimal array walker; that it doesn't work now is a consequence of the code working properly.

Another thing to try might be:

.../node/add/image?edit[title]=hello%20there&edit[body]=bye%20bye

i.e. url-encode the spaces. drupal_urlencode() could help with this.

Even with a one-word body,

node/add/story?edit[body]=body

did not work, but

node/add/story?edit[body_filter][body]=body

did.

I'm thinking maybe the module should make an educated guess that edit[body] == edit[body_filter][body].

Curiouser and curiouser. I get the same behaviour as you when adding a story but exactly the opposite behaviour when adding an image, i.e.:

node/add/image?edit[body]=body

works but

node/add/image?edit[body_filter][body]=body

doesn't.

Discovered the reason why there is the discrepancy between image and everything else. The ['body_filter'] technique of making sure filters are applied in the same order isn't used in the image module. I'm don't know whether this is a bug in image module or not.

Anyway, I've come up with a slightly ugly solution that seems to work for the page body, story body and comment comment. (From the patch on http://drupal.org/node/45349 there is also ['comment_filter']['comment'] used in drupal core.)

The basic idea is that if prepopulate_form_alter() can't find ['body'] in the form array, it will look for ['body_filter']['body'] before giving up. _prepopulate_get_walk() does more or less the same, but has a safeguard against going into infinite recursion. I haven't tested the part of the code within _prepopulate_get_walk(), as it would need a form were the ['body_filter'] was at the second level, and I haven't encountered one or constructed one. Perhaps the modification to _prepopulate_get_walk() isn't necessary.

Hope this doesn't have any unexpected side-effects...

Hmm... thinking about this more, perhaps searching for 'body_filter' &c is not the best idea, since this naming scheme is only a convention. Perhaps it would be better to test whether the non-matching element is a container (but not a fieldset) and look for 'body' there.

Alternatively, perhaps http://drupal.org/node/45349 should be reopened?

I am also unable (4.7) to get either [body]=body or [body_filter][body]=body to work on all content types. I can access title just fine. I'm also a little unclear about how to access a form element within a section I've created in a module. So, if I create $form['foo']['bar'], is it just [foo][bar]=value? That doesn't seem to work for me.

Again, the rendered HTML now showing the whole form array doesn't help. Any ideas?

The general rule for finding out what to use in the URL for a form field is to look at the rendered HTML and use the value of the name attribute in the input tag. So, for example, if the HTML looks like

<input type="text" maxlength="128" name="edit[foo][bar]" id="edit-foo-bar"  size="60" value="" class="form-text required" />
 

then you want your URL to include edit[foo][bar]=value.

The issue with the body field is that the rendered HTML doesn't show the actual array element that the body is in. For built-in node types, it seems to be edit[body_filter][body], but other modules do different things, and there's no way to tell for sure (well, not without devel.module and some array printing).

Ah, I knew something was up when I checked the code and saw that it wasn't recursive. I pulled down the CVS version and it worked great!

This should now be fixed for Drupal 4.7.x with the new official release. Please verify and close.