New field formats are necessary in Prepopulate 6.x-2.x

Prepopulate has also stopped working for me on CCK fields since upgrading to version 6.x-2.0.

Same thing here. After updating to 6.x-2.0 CCK field prepopulation is not working any more.

yes, same problem here.

Same problem for me. Reverted to 6.x-1.1

Please help by posting any information and testing. Remember 6.x-1.1 is not secure as per http://drupal.org/node/880696

I use prepopulate on several calendars. I place links in the actual calendar and prepopulate automates the entry of several cck fields, including the date that was clicked and several text fields. When the links were used after the update, none of the data prepopulated.

In addition, if an entry was then made manually after following one of these links, users would get the error message "X is required", where X was the specific cck name of the date field for that particular calendar; and the new node would not be created. Reverting to 6.x-1.1 made both problems go away.

By the way, I love this module and I have gotten more positive feedback from my users about the time-savings from this module than from any other change I've made since I started our site.

6.x-1.1 is NOT secure and should not be used on sites.

there does seem to be a problem with the logic in _prepopulate_request_walk() which is leading to these problems.

Please test the patch in #360613-21: Prepopulating CCK Autocomplete Nodereference field this seems to be an elegant way to fix the problem and resolves this problem at the same time.

I can confirm the patch found here, http://drupal.org/node/360613#comment-3319884, works to correct this issue and the one found in #360613: Prepopulating CCK Autocomplete Nodereference field

I tried the mentioned patch for prepopulating dates in calendar, but I get the following error:

"There are errors in Day:
The dates are invalid."

My prepopulate link looks like this: node/add/node_type&edit[field_day][0][value]=2010-08-18

If I roll back to 6.x-1.1 everything works perfectly.

Edonnelly did you get it to work?

Thanks for help,

Piros

The patch does nothing for me, nothing prepopulates even after applying the patch from comment #21 (in the other referenced thread) to 6.x-2.0 .

Ok, I got it working with the patch from #9. I had to change my link and the date format.
With previous version I didnt have to pass any time with the date, now I have to.

Before this was working fine: node/add/node_type&edit[field_day][0][value]=2010-08-18
Now this is how it has to be: node/add/node_type&edit[field_day][0][value][date]=2010-08-18%2000:00

But it works now.

Thanks.

Thanks, Piros. This helps me get a lot closer, but what I need to do to get mine to work seems a lot different.

I have a conference calendar link that autopopulates the date clicked and puts in noon as the time:

Old syntax (works on 6.x-1.1): node/add/conference?edit[field_conference][0][value]=2010-08-07%2012:00

With 6.x-2.0 I have been able to get it to work only with the following syntax:

node/add/conference?edit[field_conference][0][value][date]=11%20Aug%202010&edit[field_conference][0][value][time]=12:00PM

This is the only syntax I've been able to get to work, and the date text has to be absolutely exact (even the PM has to be there or it reports that the value is invalid when I try to save the new node). There is also a strange delay between when the page loads and when the values appear. If I had to guess, it looks like previously I was passing an actual datetime variable, while now I am passing strings (any format for the date other than the exact string format I switched to causes it to report an invalid value).

[using the format Piros did, with the date and time passed together, fails for me now. I think this is because I do use the time, and it shows up as its own text box on the new node form. Now when I try to pass them together, both the date and time appear in the date box, causing it to fail as an invalid format. Previously, though, as you can see, I did pass the time and date together without a problem and each would appear in its appropriate box]

I switched to the new 6.x-2.x-dev 2010-Aug-18 and I still don't think it's quite working right. My above comment about the new syntax to get the date and time to work, and the fact that it is behaving like a string instead of date variable holds true with the -dev version. So, it's different but usable there. Text fields are also working fine. However, I am unable to get any version later than 6.x-1.1 to prepopulate a CCK select field. Anyone else able to do this?

The change in date fields is an understandable change based on the stage at which the field is now pre-populated. In version 1.x this happened early in the form building before the actual field was rendered. Now that it's happening, as it has to, at the end of the build the date and time fields are already separate.

For Select Lists this syntax is working for me:

node/add/page?edit[field_myfield2][value]=1

Note that the actual string is the key value in case the list of items has keys and values that are not the same.

Marking as needs work and a documentation related item as we'll collect the necessary documentation changes here and get a patch to update the documentation.

Taxonomy format for a vocabulary named tags:

add/page?edit[taxonomy][tags][1]=test

The -dev version fixed it for menus and taxonomy for me. The syntax for both of these is the same as in the 1.1 version:

node/add/foto?edit[menu][parent]=primary-links:4708&edit[taxonomy][tags][1]=Teun

This is really great and I appreciate all the work being done. With regard to a CCK field requiring selection, it works if I use the "Select Box" widget for the form, but if I use the "radio button" widget I cannot get it to work. Though I actually have several areas where I prepopulate radio buttons, I'm liking the select box better anyway, so I'm switching over to those anyway and this module now does absolutely everything I need it to do. But, someone may want to figure out what it takes to get a radio button selection to work when you do update the documentation.

Again, thanks so much for the excellent work on this incredibly useful module.

Updating to the newest dev version fixes this for me.

Added updates to usage.txt in 6.x-2.1 release which will be available shortly.

Posting in case this helps someone else...

for a radio option field to work with prepopulate:

example radio input fields:

<input type="radio" class="form-radio" checked="checked" value="event" name="field_date_entry_type[value]" id="edit-field-date-entry-type-value-event">Event
<input type="radio" class="form-radio" value="schedule" name="field_date_entry_type[value]" id="edit-field-date-entry-type-value-schedule">Schedule

To select the schedule option using prepopulate, you would need the following in the URL

edit[field_date_entry_type][value][schedule]=schedule

It takes me hours to find the way for prepopulate a nodereference with the 2.x version.

here is the url for prepupulate the field_noderef with the node 14. The only nodreference widget working is "select list"

http://supersite.com/node/add/document?edit[field_noderef][nid][nid]=14

I am still experiencing this problem on the latest 2.1 release. Noderef fields do not work on autocomplete and with the previous syntax anymore.

in 1.1
http://localhost/acquia619c/node/add/story?edit[group_optional][field_da... worked and populated the datefield with 13/10/2010
in 2.1 it fails unless you alter it tl
http://localhost/acquia619c/node/add/story?edit[group_optional][field_da...
BUT previously it automatically updated the format from dashes to slashes now as it leaves it as dashes when I save I get the error

Field date From date is invalid.

I am happy to add the extra [date] in but seeking guidance as to passing the correct format. The custom module that adds this

<?php
// This function adds a '+' next to each datebox with a link to the event node creation page,
// if the current user has permission to create events.
// Replace 'addplus' with the name of your module.
// Replace 'event' with the name of your CCK content type.
function addplus_preprocess_calendar_datebox(&$vars) {
    global $user;
  if (user_access('create event content', $user)) {
$options = array();
$options['query'] = array('edit[group_optional][field_date][0][value]' => $vars['date']);
$options['attributes'] = array('title' => 'Add an event for THIS day');
$vars['add_event_link'] = l('+', 'node/add/story', $options);
      
  }
}
// This function prepopulates the time field when the event is created.
// Replace 'addplus' with the name of your module.
// Replace 'story' with the name of your CCK content type.
// Replace 'time' with the name of your date field.
function addplus_form_alter(&$form, $form_state, $form_id) {
if ($form_id == 'story_node_form' && arg(3) != '') {
       $form['group_optional']['field_date']['#default_value']['value'] = arg(3) . ' 09:00:00';
     $form['group_optional']['field_date']['#default_value']['value2'] = arg(3) . ' 10:00:00';
    }
}
?>

Added in a link to this issue from the handbook page at http://drupal.org/node/228167

I also am experiencing issues with the node reference pre-populate field.

"/node/add/card-orders?edit[field_node_reference][0][nid][nid]=40"

Doesn't load 40 into the node reference field.

Setting category to "task" and priority to "normal" as this feels more like a documentation issue than a bug.

I've found Firebug very useful to get the exact field name, and have seen many of the issues get addressed through adjusting the format of what is passed into the field to be prepopulated, and/or adjusting the config of the field getting the prepopulated value.

@jbrauer - feel free to undo my status changes, and my apologies in advance if I've overstepped here, but this doesn't feel critical.

Well, after asking this:

>When the vocabulary is free tagging, above-mentioned edit[taxonomy][tags][1]=Teun format doesn't work for >me, neither for 6.x-2.1 nor 6.x-2.x-dev versions. If I change the vocabulary from free-tagging to plain, then the >only version working for me is:

/node/add/page?edit[taxonomy][8]=53 (with vocab-id and term-id). It doesn't accept vocabulary or term names.

>I am using the Unitag module and I have to use a free-tagging vocabulary. Any patches I am missing?
>Thanks in advance...

... I evaluated HTMl source of the form and found that free-tagging fields have an extra [tags] component (Not a vocabulary named 'tags'). So, the following worked for me:

edit[taxonomy][tags][6]=foo (but still only with the vocabulary id an tag string)