Prepopulate should be able to set numeric arrays as defaults
| Project: | Prepopulate |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
It should be possible to prepopulate multiple items from a select box, for example multiple terms in a taxonomy. The attached patch does this, so that you can, for example, prepopulate terms 11 and 2 from a vocabulary selection box like this:
http://www.example.com/node/add/image?edit[taxonomy][1][]=11&edit[taxonomy][1][]=2
The patch assumes that the end of $_GET['edit'] has been reached when the slice has only numeric elements and has at least 2 elements. This means that trying to set one taxonomy term with a 1 element array will not work, e.g. in the above example
http://www.example.com/node/add/image?edit[taxonomy][1][]=11
would do nothing, but
http://www.example.com/node/add/image?edit[taxonomy][1]=11
(note absense of []) would select tid 11 from the selection box.
I've searched the php pages for a neater way of checking whether an array is all numeric, but can't find one in PHP4 (though there is something a bit neater in PHP5).
| Attachment | Size |
|---|---|
| numeric_array.patch.txt | 1.18 KB |
#1
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. :)
#2
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?
#3
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.
#4
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
#5
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.
#6
Hmm... before I look into this, would I wonder if it might be worth thinking what the most desirable syntax for numeric arrays is:
The current method is vanilla PHP IIRC, but perhaps something like:
http://www.example.com/node/add/image?edit[taxonomy][1]=11,12
instead of
http://www.example.com/node/add/image?edit[taxonomy][1][]=11&edit[taxonomy][1][]=12
would be desirable?
Given that I expect most prepopulate URLs will be machine-generated, I don't suppose the extra code required would be worth the aesthetic gain, but I'm willing to be convinced otherwise -- the decision should be made now rather than later!
Thanks for the documentation changes greggles. If I resubmit the patch, should I put them in the patch too?
#7
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.
#8
The attached patch uses the http://www.example.com/node/add/image?edit[taxonomy][1]=11,12 syntax and seems to work with multiple vocabularies in the form too. It's also smaller, and in my view neater, than the previous patch.
There's no worrying about whether an array is numeric or not. Instead the logic is to look at the type of form for which the default_option is being set. If it is a "select" form, then explode a comma-separated string into an array a la taxonomy terms.
If you think it's OK, I'll provide docs.
P.S. I've looked at the coding standards and tried to follow them, but any pointing out of errors in the standards would be gratefully accepted.
#9
A new version of the patch. By using ? : notation, the patch now results in no increase in line count.
I have tested this with multiple select boxes and single select boxes. It degrades gracefully in the case of a single select box (the first element of the array is the chosen value).
I have also patched USAGE.txt along the lines greggles suggested earlier in the thread -- not wanting to claim your work, but thought it might as well go in.
#10
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.
#11
I'd be happy to revert the code to the if () {} else {} construct (and keep the doc changes I stole from you :-)
However, I did look at the coding conventions, and while it does recommend the if () {} else {} construct, I couldn't see that it discouraged the ? : notation explicitly.
I also took a lead from core modules, where the ? : notation does seem to be used frequently (e.g. comment.module). By my reckoning it occurs about 263 times in core modules (in drupal 5):
$ find . -name '*.module' -exec perl -n -e "if (/\?.*:/) { print ; }" {} \; | wc -l
263
Or perhaps there are particular circumstances in which it is used in core modules that don't apply here?
It would be good to know for sure what the policy is, and to make the coding conventions clearer (unless I've been stupid and missed something).
#12
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).
#13
I think there's a good argument for using if () {} else {} instead of ? : as the ? : can be quite hard to read. On the other hand, it does keep down the line count and in this case feels preferable to me -- but it's not a mega-strong preference.
Anyway, either manifestation of the logic should work - I think this patch should be pretty safe, as it only changes the behaviour of prepopulate in the case of a select form item.
#14
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
#15
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
#16
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) {
#17
Has any more work been performed on this issue? I still notice that this functionality is missing in the latest dev version.
#18
None of these patches work for me.. is there no way with prepopulate to select more than one taxonomy term?
#19
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...