Prepopulate should be able to set numeric arrays as defaults

Has this patch been applied?

If not, what is the reason? I will make due with not being able to prepopulate multiple terms, or we will maintain the patch for now.

Thanks for the cool module. :)

The patch has not been applied because I have not tested it, nor have I heard from any testers. As you can see, the patch is labeled 'needs review.' Would you like to review it?

Ahh, actually after looking into this, I am using Taxonomy Super Select which organizes them as seperate checkboxes, instead of a select box array. I will place my comments in the taxonomy issue, http://drupal.org/node/113662.

In my test the patch works as advertised. The code style is not to the coding standards, but that is true of the whole module so I don't think that should hold up the patch.

I noticed that the prepopulation of taxonomy in README.txt is not thoroughly documented. Especially since this patch relies on an extra [] that might not be obvious based on the generic instructions in the README.txt I have provided some possible documentation for how to use prepopulate with taxonomies.

To prepopulate Taxonomy terms use one of the following formats:

Single taxonomy term:
  http://www.example.com/node/add/image?edit[taxonomy][1]=11

Multiple taxonomy terms in a select list:
  http://www.example.com/node/add/image?edit[taxonomy][1][]=11&edit[taxonomy][1][]=12

Freetagging terms:
  http://www.example.com/node/add/image?edit[taxonomy][tags][1]=sample

Note in all these examples that the value 1 has been placed for the taxonomy ID value: "[1]"  To make this work for your site you will need to substitute the taxonomy id value for the [1] to make the links work.  You can find the taxonomy ID in the page source.  For example, the taxonomy id for the select box with <select id="edit-taxonomy-5"...> is 5.

Given functioning code and documentation, I think this is ready to be committed.

While editing the README.txt you might also want to change from drupalsite.org to example.com

I only just now realized that this patch either breaks multiple select boxes or changes the syntax in a way that breaks backwards compatibility.

I was trying example.com/node/add/blog?edit[taxonomy][1]=1&edit[taxonomy][7]=16 and that works without the patch and is broken with the patch. I also tried the syntax example.com/node/add/blog?edit[taxonomy][1][]=1&edit[taxonomy][7][]=16 which also did not work.

So, I'm changing status to code needs work to reflect this seeming regression.

My preference would be for the style http://www.example.com/node/add/image?edit[taxonomy][1]=11,12. That's just much more intuitive to drupal admins who are used to building things like taxonomy/term/11,12

And I believe that this is a great module that suffers from a small lack of documentation (though eafarris has done lots of great work recently with the usage.txt file to make that less of a problem). So, yes, I think all new features for the moduleshould provide 1) documentation 2) CHANGELOG.txt patches as well.

Please, claim my work ;) As long as we move towards an improved module I'm very happy to have my work "stolen".

However, the ? : notation is not to drupal.org coding standards

It's a small thing, but the full if() { } else {} construct is preferred due to the improved readability.

That's a small problem, of course. I haven't tested the patch yet so I can't comment on it's suitability for committing in general.

Good point - my strict adherence to this was obviously quite wrong. In that case the code style looks fine to me (still havent' testing functionality).

Patch at #9 works as described on a Drupal 5 installation.
[Not sure why discussion stopped on this issue?]

useful, almost necessary, feature for preopopulate, IMO.

Thanks
Alan

OK
Patch at 9 causes other issues.
Basically, I had this working for node references before, but they stop working with this patch.

I'll keep plugging away, see whether I can sort it.

Alan

i had an issue with multi-options cck fields, and this is something i came up with. I've posted this in another ticket, but it may help others is if I'll post it in here as well...

values separated by |

function _prepopulate_get_walk(&$form, &$getslice) {
  if (!is_array($getslice)) {
    $form['#default_value'] = $getslice;

   if ( ( ( $form['#type'] == 'select' && $form['#multiple'] == 1 ) || $form['#type'] == 'checkboxes' ) && substr_count( $getslice, '|' ) > 0 ) {
      $form['#default_value'] = explode( '|', $getslice );
    }

  }
  else {
    foreach (array_keys($getslice) as $getvar) {

Has any more work been performed on this issue? I still notice that this functionality is missing in the latest dev version.

None of these patches work for me.. is there no way with prepopulate to select more than one taxonomy term?

I've found that in a taxonomy form that uses hierarchical select, I can pre-populate multiple terms by structuring the URL in the following format.

...node/add/page?edit[taxonomy][10][0]=587&edit[taxonomy][10][1]=366&edit[taxonomy][10][2]=686...

Is there any update on this issue? I can't figure out how to select multiple terms and the patches are no longer relevant for 6.x.2.x.

In Post #4, Greggles writes:
------------------------
Note in all these examples that the value 1 has been placed for the taxonomy ID value: "[1]" To make this work for your site you will need to substitute the taxonomy id value for the [1] to make the links work. You can find the taxonomy ID in the page source. For example, the taxonomy id for the select box with <select id="edit-taxonomy-5"...> is 5.
------------------------
What page source is he referring to? I cannot figure out how to find this taxonomy id. Is it to do with the field that is being populated or the vocabulary that the term is coming from?

I can find the term id by scrolling over the edit button in the vocabulary list. If I need to look up a file, can you give me an idea where to find it?

Thank You!

Just in case somebody else needs this for lts version 6.x-2.3 🙄.