Container elements and their children cannot be prepopulated in the 7.x-2.1 security update release

I'm having the same issue.

Looks like the `$limited_types` changed. In my case, I was using prepopulate on a node reference field using an autocomplete widget, although this would apply to an entity reference field as well.

Those fields have a `#type` of `container` and get excluded from processing right at the root of the array, rather than cycling through array items to get to the actual field.

Not sure if this is by design, can someone provide some insight there? Are all container types meant to be excluded, or do we need to find another way of walking through the array?

This is a somewhat unfortunate side-effect of hardening the field types. It would be ideal that instead the module whitelist the fields that can use prepopulate. In the alternative in the meantime it's possible we can come up with a means of allowing some specific container cases.

Same issue here.. I mostly use prepopulate for entity reference fields but use it for various other fields as well none of which are working..

Is a roll back to the previous version the quickest fix for now to get things working again?

I do not recommend rolling back. Since the security advisory has been released it's now public how one could exploit the previous versions if they were determined to do so.

I hope to have a patch with an option posted today that will allow sites to override the type check for specific fields they want to allow being pre-populated. In the meantime if you urgently need to allow certain types of fields and are willing to accept the risk you can of course modify the blacklist in the module until other options exist.

Similar issues, tweaking the blacklists did work for the time being.

Forms built using Entityforms is whats causing issues for me. The "container" type which is blacklisted wraps every field on Entityforms. I'm sure we can find a better way to exclude this one.

$limited_types including the 'container' type broke every instance of use here. Pretty much every field there is comes in a container which has neutered the module's functionality.

For now I've commented this out as I already have extra code in place to indirectly give protection for this path. I'm guessing it'll need an update if there's a major change to how this module works.

Thanks for tip on commenting out "container" from the $limited_types.
I will use this for now.

Confirming that commenting out 'container' band-aids the issue.

Attached a temporary patch for users who find this issue and need a quick fix.

marked the patch as hidden so it's not found without reading the issue and understanding it is not a fix for the issue and is not a good general solution but something sites may consider in the short term.

Have the same issue.
Module has become unusefull so I would suggest putting this to Major.

Will try and see if I can create a patch for this in a couple of days.

Also my previous patch does not work any more since the update:
https://www.drupal.org/node/1424774#comment-10821574

Added a check that checks container children if they are in the allowed types.

This patch does not work for my instance - Entity Forms + Fields - as what is being searched for does not match. This should be the same on all Entity + Field situations. Have returned to commenting out 'container'.

As an example, this is my $_REQUEST['edit'] array that does not work with this patch.

Array
(
    [field_ENTITYREFERENCE] => Array
        (
            [und] => Array
                (
                    [0] => Array
                        (
                            [target_id] => Text Label (344)
                        )
                )
        )

    [field_TEXTOPTION] => Array
        (
            [und] => text_key_value
        )

    [field_DATEFIELD] => Array
        (
            [und] => Array
                (
                    [0] => Array
                        (
                            [value] => Array
                                (
                                    [date] => 15/03/2016
                                )
                        )
                )
        )
)

And these are the relevant parts of their field defs.

$form[field_ENTITYREFERENCE] => Array
(
    [#type] => container
    [#attributes] => Array
        (
            [class] => Array
                (
                    [0] => field-type-entityreference
                    [1] => field-name-field-NIX
                    [2] => field-widget-entityreference-autocomplete
                )
        )
    [#weight] => 0
    [#tree] => 1
    [#language] => und
    [und] => Array
        (
            [0] => Array
                (
                    [target_id] => Array
                        (
                            [#entity_type] => entityform
                            [#entity] => Entityform Object
                            [#bundle] => nux
                            [#field_name] => field_NIX
                            [#language] => und
                            [#field_parents] => Array
                                (
                                )
                            [#columns] => Array
                                (
                                    [0] => target_id
                                )
                            [#title] => NIX
                            [#description] =>
                            [#required] => 1
                            [#delta] => 0
                            [#weight] => 0
                            [#type] => textfield
                            [#maxlength] => 1024
                            [#default_value] =>
                            [#autocomplete_path] => entityreference/autocomplete/single/field_NIX/entityform/nux/NULL
                            [#size] => 30
                            [#element_validate] => Array
                                (
                                    [0] => _entityreference_autocomplete_validate
                                )
                        )
                )
            [#theme] => field_multiple_value_form
            [#field_name] => field_NIX
            [#cardinality] => 1
            [#title] => NIX
            [#required] => 1
            [#description] =>
            [#prefix] => <div id="field-NIX-add-more-wrapper">
            [#suffix] => </div>
            [#max_delta] => 0
            [#after_build] => Array
                (
                    [0] => field_form_element_after_build
                )
            [#language] => und
            [#field_parents] => Array
                (
                )
        )
    [#access] => 1
)

$form[field_TEXTOPTION] => Array
(
    [#type] => container
    [#attributes] => Array
        (
            [class] => Array
                (
                    [0] => field-type-list-text
                    [1] => field-name-field-NIX
                    [2] => field-widget-options-select
                )

        )

    [#weight] => 1
    [#tree] => 1
    [#language] => und
    [und] => Array
        (
            [#entity] => Entityform Object removed
            [#entity_type] => entityform
            [#bundle] => nux
            [#field_name] => field_NIX
            [#language] => und
            [#field_parents] => Array
                (
                )

            [#columns] => Array
                (
                    [0] => value
                )

            [#title] => NIX
            [#description] =>
            [#required] => 1
            [#delta] => 0
            [#type] => select
            [#default_value] => Array
                (
                )

            [#multiple] =>
            [#options] => Array
                (
                    [_none] => - Select a value -
                    [nux] => nux
                    [nax] => nux
                )

            [#value_key] => value
            [#element_validate] => Array
                (
                    [0] => options_field_widget_validate
                )

            [#properties] => Array
                (
                    [strip_tags_and_unescape] => 1
                    [optgroups] => 1
                    [empty_option] => option_select
                    [filter_xss] =>
                    [strip_tags] =>
                )

            [#after_build] => Array
                (
                    [0] => field_form_element_after_build
                )

        )

    [#access] => 1
)

$form[field_DATEFIELD] => Array
(
    [#type] => container
    [#attributes] => Array
        (
            [class] => Array
                (
                    [0] => field-type-datetime
                    [1] => field-name-field-NIX
                    [2] => field-widget-date-popup
                )

        )

    [#weight] => 1
    [#tree] => 1
    [#language] => und
    [und] => Array
        (
            [0] => Array
                (
                    [#entity_type] => entityform
                    [#entity] => Entityform Object removed
                    [#bundle] => nux
                    [#field_name] => field_NIX
                    [#language] => und
                    [#field_parents] => Array
                        (
                        )

                    [#columns] => Array
                        (
                            [0] => value
                        )

                    [#title] => NIX
                    [#description] =>
                    [#required] => 1
                    [#delta] => 0
                    [#weight] => 0
                    [#type] => date_combo
                    [#theme_wrappers] => Array
                        (
                            [0] => date_form_element
                        )

                    [#default_value] => Array
                        (
                            [value] =>
                            [timezone] => TZ
                            [timezone_db] => TZ
                            [date_type] => datetime
                            [value2] =>
                        )
                    [#date_timezone] => TZ
                    [#element_validate] => Array
                        (
                            [0] => date_combo_validate
                        )

                    [#date_is_default] => 1
                    [#date_items] => Array
                        (
                            [value] =>
                            [timezone] => TZ
                            [timezone_db] => TZ
                            [date_type] => datetime
                            [value2] =>
                        )

                )

            [#theme] => field_multiple_value_form
            [#field_name] => field_NIX
            [#cardinality] => 1
            [#title] => NIX
            [#required] => 1
            [#description] =>
            [#prefix] => <div id="field-NIX-add-more-wrapper">
            [#suffix] => </div>
            [#max_delta] => 0
            [#after_build] => Array
                (
                    [0] => field_form_element_after_build
                )

            [#language] => und
            [#field_parents] => Array
                (
                )

        )

    [#access] => 1
)

Not a nice way, and the code is not really maintainable since it gets quite complex.

But what is the motivation behind setting text_format as limited type?

I'm sorry, I don't know where you've picked up 'text_format' as key a key piece of the pie - none of my fields have anything to do with text_format.

I haven't read back further to see if I've missed a comment in this thread the uses it, but I can't find it in a text search of the page.

If this patch is to allow the single type of field of 'text_format' to be used in a container, it's a bit not useful for all of the other fields out there. I'd have thought something that steps into a container and did the same walk inside it would be the way to go, but I'm afraid I haven't scraped enough free time together to look into coding anything here.

#17 sadly doesn't work for me when prepopulating a Relation Add field. The following error message is shown as well:

Notice: Undefined index: #type in _prepopulate_request_walk() (line 80 of /var/aegir/platforms/panopoly-7.x-1.32/sites/{SITE}/modules/prepopulate/prepopulate.module).

Edit: The #10 band-aid does not work for me either.

Edit 2: Reverting to 7.x-2.0 temporarily fixes the issue.

@ #18
text_format is in the array list in de code as limited values. Which is why text_format does not work as well as the container field. This is changed since the security update. I'm not sure why it has changed but it is the 'cause' of this issue.

Kind regards,

scuba_fly

Module not working anymore after security update. Rolling back is not an option. This issue is critical.

Marked #2691065 as duplicate of this issue

Applied patch from #17 and received the same error message as #19. The field I was trying to prepopulate was a title field from the Title Field module.

Error msg:

Notice: Undefined index: #type in _prepopulate_request_walk() (line 80 of /sites/all/modules/prepopulate/prepopulate.module).

The url to populate an entity reference field has changed. Where it used to be edit[name_of_field][und]=id_value now it works as name_of_field=id_value

Thanks Robert! What's the syntax when the referred field is multivalued? I'm trying name_of_field[0]=id_value but it doesn't work.

Sorry, dpico. I could only find out this one. term reference field is not working either.

Thanks Robert! Let's see if someone can say something about this.

By the way, if this is a critical bug for version 2.1 and it's still not solved, shouldn't that version NOT be offered as the standard download version in the project's webpage? This is the version that everyone is downloading right now.

dpico, you can use hidden patch at #11 to solve this for now. It is not a fix, yet.

Sadly 2.1 should be offered, since it fixed an exploit. Luckily, in my case the project is an intranet site, where anyone outside of the network will not have access to the site.

That's my case as well. Do you think if will be safe to revert to a previous version? I'm afraid the database would be corrupted or that something disastrous like that can happen if I revert. If I do, is it enough to install 2.0 and execute update.php?

Downgrading isn't a problem, since an update.php wasn't necessary when updating from 2.0 to 2.1 (no tables were changed).

Just for future reference though, if a database update is ever required then a downgrade is not possible with any module. In those cases, an uninstall of the updated module is required, and then a re-install of the downgraded version.

Luckily the prepopulate module doesn't have any settings, so uninstalling and re-installing the older version is an option as well, without needing to configure anything.

With any module change, you should however always clear all cache (via Performance), and run a database cron.

For those that use Prepopulate on only Entity Reference fields, you can instead use Entity Reference Prepopulate Token module in combination with the dev version of the Entity Reference Prepopulate module.

Using those two modules, you have the choice to use either tokens, panels substitutions, URL query parameters, or Organic Group Contexts. In addition to this, you can specify whether the field should be hidden or disabled when prepopulated. Also, you can specify that the field should only be shown when prepopulated. Lastly, you can configure it to redirect to a page if the prepopulate value is not available.

The Entity Reference Prepopulate module works when creating nodes and also optionally when editing nodes. However, the Entity Reference Prepopulate Token module only works when creating nodes for now. I however created a feature request issue for edit support as well: #2723867: Apply action on edit

1. +++ b/prepopulate.module
   @@ -63,13 +63,25 @@ function _prepopulate_request_walk(&$form, &$request_slice) {
   -    'text_format',
   +//    'text_format',
   

   Why is this not deleted

2. +++ b/prepopulate.module
   @@ -63,13 +63,25 @@ function _prepopulate_request_walk(&$form, &$request_slice) {
   +           && !in_array($form[$request_variable][$form[$request_variable]['#language']]['#type'], $limited_types)
   

   What is the meaning of this? I guess to check for the language variant. I do get
   

   Undefined index: #type in _prepopulate_request_walk()

   on it.

I want to propose another patch based on #17 but written differently which has probing/debug for user-1. We can remove those if needed. That still needs the fix mentioned above.

And it does not fix setting a 'container' integer field.

My field is failing on

$form[$request_variable][$form[$request_variable]['#language']][0]['#type']

is not numeric but a Drupal Commerce Price field. So which fields will break.

Another rewrite could be something like

        $or = !isset($form[$request_variable]['#type']);
        // If type in $limited_check if we should check the 'subcontainer'.

        if (!$or) {
          $or = isset($form[$request_variable]['#language'])
              && isset($form[$request_variable][$form[$request_variable]['#language']]['#type'])
              && !in_array($form[$request_variable][$form[$request_variable]['#language']]['#type'], $limited_types)
          ;
        }
        if (!$or) {
          $or = $form[$request_variable]['#type'] == 'container' && $form[$request_variable][$form[$request_variable]['#language']][0]['#type'] == 'text_format';
        }
        if (!$or) {
          $or = !in_array($form[$request_variable]['#type'], $limited_types);
        }

which gives some debugging options why it is not working as expected.

The patch from comment #33 works for me but generates a warning because a certain value isn't checked before it's used. I've attached another patch to fix this. This may be part of a larger issue (though it's not causing me any problems), see clemens.tolboom's comment.

Patch #36 works well for my use case (prepopulating date fields). Thanks!

I had luck with just removing 'container', i'm not sure which scenario uses text_format as a type, maybe that's a separate issue?

Try this patch

@joelpittet: Thanks, but this temporary fix was also suggested as shown in #10. It is only a quick fix supposedly, but isn't a permanent solution to the problem. Sadly, it also only works for some people, in my case my Relation Add fields did not work.

It would appear that #36 is the closest to the real solution so far.

The logging doesn't need to be added in #36, a debugger should be able to get you through this better with much more context variables for the problem. That patch assumes devel module is installed.

I kind of know what it was doing before, but the patch in #36 (and before) is kind of confusing to follow what it's doing. That could likely be just me though...

#36 is working for me

#10 (#38) worked for us. It will be necessary to apply this to live sites temporarily until better fix. Thanks!

Re: various comments here about text_format, I ran into a similar issue (using the Drupal Commons distro, not sure if it's reproducible using Drupal core). My body field, for some reason, had type text_format. I noticed, however, that it also had a #base_type element that passed muster. So, I propose this edit:

diff --git a/prepopulate.module b/prepopulate.module
--- a/prepopulate.module
+++ b/prepopulate.module
@@ -69,7 +71,7 @@ function _prepopulate_request_walk(&$form, &$request_slice) {
   if (is_array($request_slice)) {
     foreach (array_keys($request_slice) as $request_variable) {
       if (element_child($request_variable) && !empty($form[$request_variable]) &&
-       (!isset($form[$request_variable]['#type']) || !in_array($form[$request_variable]['#type'], $limited_types))) {
+       (!isset($form[$request_variable]['#type']) || !in_array($form[$request_variable]['#type'], $limited_types) || !in_array($form[$request_variable]['#base_type'], $limited_types))) {
         if (!isset($form[$request_variable]['#access']) || $form[$request_variable]['#access'] != FALSE) {
           _prepopulate_request_walk($form[$request_variable], $request_slice[$request_variable]);
         }

I needed to extend to patch, to also remove the text_format property from the limited types. The reason is, that textfields using the "Text processing = Filtered text" in the field configuration, injects the #type = text_format into the field instance.

Could someone help me install the patch referenced in comment #36?

I've never installed a patch before.

The issue I'm having is trying to pre-populate a field in a dropdown.

Are there any detailed instructions on how to install the patch, what module files need to be edited and where in the file or is the whole file just updated?

Regards,

John

You'll find instructions here: https://www.drupal.org/patch/apply

suncorjohn,

The patch itself from #38 looks like this.

diff --git a/prepopulate.module b/prepopulate.module
index d024385..c61262e 100644
--- a/prepopulate.module
+++ b/prepopulate.module
@@ -56,7 +56,6 @@ function _prepopulate_request_walk(&$form, &$request_slice) {
   $limited_types = array(
     'actions',
     'button',
-    'container',
     'token',
     'value',
     'hidden',

To manually do this, you would go to the module directory "prepopulate" then to the file "prepopulate.module", then go to about line 56 and look for the first part which is "$limited_types = array (".

A minus sign in front of a line is a removal. A plus sign in front of a line is an addition. In this case you simply just remove the line 'container',

Save the file. Flush all caches. Try it out.

Keep in mind this is just a temporary fix.

Of course #36 would be more tedious to do manually but can be done manually.

Thanks crutch,

Removed the 'container' line in the file "prepopulate.module" per your instructions.

Still having issues pre-populating field in dropdown select list.

The field key is product_name. The fields in the webform are:
product_1|Product 1
product_2|Product 2
product_3|Product 3

Tried the following links, which did not work:

<a href="/webform-pre-fill-test?product_name=product_2" target="_self">LINK TO PRE-FILL DROPDOWN</a>
<a href="/webform-pre-fill-test?current-page:query:product_name=product_2" target="_self">LINK TO PRE-FILL DROPDOWN-2</a>

Do I need to select a default value?

Here is a link to the test page: http://www.atlantisrail.com/test-pre-fill

Any assistance would be appreciated.

Regards,
John

Try this tutorial it may help. http://drupalwoo.com/content/blog/webform-passing-info-through-url

Work with the "default value" of the webform field itself and make sure token module is installed.

Note the comments regarding webform 7.x-3 vs 7.x-4

crutch,

Went through the tutorial, noted comments regarding webform 7.x-4. As I mentioned, it works for text field but does not work for dropdown select options. When I set the default value and save the form, the default value is not set?

I set the default value for the select options dropdown to:[current-page:query:product_name].

My link URL is set to: <a href="/webform-pre-fill-test?product_name=[product_2]" target="_self">LINK PRE-FILL DROPDOWN</a>

I give up, this just does not work, thanks anyway everyone.

#36 worked for me.

Shame that a security fix is causing this much problems and that it seems to be so difficult to get around this.
Maybe this is a silly thought, but might it not be a better options to revert the security update and find another solution for that problem?

Just my two cents. Shame to see this module in this state though, useless with entityform at least.

Patch #36 successful on Drupal 7.52, Prepopulate 7.x-2.1

Updated patch from #36 that just removes all the logging, because I don't want that.

Patch #36 successful on Drupal 7.52, Prepopulate 7.x-2.1

But I don't understand: why this module is out if it not works?
If this patch works why it is not been yet committed?

Looks like #36 is RTBC

But #55 is a far more maintainable code. Can we get reviews on #55?

Ok, I've tested also #55 and seems work perfectly.

I've just run into this issue with entityreference autocomplete and the patch in #55 worked perfectly. The patch applied without issues and prepopulating the field works as expected.

#55 works for me. Thanks!

just tested #55 and can confirm it working

had been using #10 to solve this as a temporary measure but now with proper solution no need.

I too confirm that patch #55 works!

I've tested the patch in another project and seems work perfectly

#55 is working. We should release it, the 7.1 version marked as stable does not work! In case anyone still has doubts, try it out on simplytest.me.

+1 for patch #55.
Works great, Thanks!

#55 works good. thanks!

#55 works, hurray! Can we get it rolled into a release?

+1 for patch #55.
It's working.

could the patch be at least included in the Dev Version?

Dev version at simplytest.me

https://simplytest.me/project/prepopulate/7.x-2.x

doesn't seem to work either...

Patch in #55 works for me too.

Patch #55 works for me.

Merged thanks.

I am feeling this module is totally broken while using it...
Seems like that many value handlers of the arrays and the form formats are changed in the newest drupal core.
I've followed all the introductions from the module handbook page，
but end up finding out only the value of title and options（publishing status etc.)can be passed through the url ,
except for these two fields, I've tried all the suggestions about Taxonomy and CCK fields but sadlly nothing just happends at all!
Agree with #56
why this module is out if it not works?
If this patch works why it is not been yet committed?
Spending all my afternoon working on this issue.
Sincerely hope the author could write some tips about the " verision broken issue" to whomever wants to try this module.Especially the new ones for drupal.Wish others don't have to spend their all day on it ...

Hi Wildsonic, looks like this patch has been committed to the latest dev version. Maybe check that you're using the up to date dev version of this module?

The patch works for me too. Too bad the stable version doesn't work. Spend half a day searching for the reason. I still think it's misleading to have 2.1 as green..

Gave up on this module since last time's failure,tested the dev-version today, works fine for taxonomy ,thanks !

+1 for pushing the dev to a new release.

I ran into this problem trying to prepopulate a Profile2 field on a Profile2 Registration Path and after a few hours of head-scratching and then debugging the prepopulate managed to find the container line that was causing the problem, and I'm happy to say the dev version fixed it without introducing security issues.