Posted by antix on October 15, 2009 at 2:52am
60 followers
| Project: | Webform |
| Version: | 6.x-2.10 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
Default values (for example, profile data pulled with %profile_) don't work as of this update. The fields auto-populate with the %profile_ code.
Comments
#1
I can confirm this with both Drupal 5 and 6, though from looking at the code this isn't immediately clear why this has occurred. Patches would be appreciated here, as I'm unable to afford much time to Webform currently.
#2
Same issue here after updating. Subscribing...
#3
Unfortunately, I got the same problem.
#4
Me too. Subscribing.
#5
Same here, unfortunately. Subscribing
#6
Here's a quick and mostly untested fix. Just posting code for now. I can roll a patch later if this looks good.
Apologies for the pseudo patch.
Starting with line 2140 in webform.module
<?php
// Provide a list of candidates for token replacement.
// Note these tokens are not cached as they may change frequently.
if ($user->uid && module_exists('profile')) { //Added
profile_load_profile($user); //Added
} //Added
$special_tokens = array(
'safe' => array(
'%get' => $_GET,
),
'unsafe' => array(
'%cookie' => $_COOKIE,
'%session' => $_SESSION,
'%post' => $_POST,
'%request' => $_REQUEST,
'%profile' => $user, //Added
),
);
// User replacements.
if (!array_key_exists('%username', $replacements['unsafe'])) {
$replacements['unsafe']['%username'] = isset($user->name) ? $user->name : '';
$replacements['unsafe']['%useremail'] = isset($user->mail) ? $user->mail : '';
$replacements['unsafe']['%ip_address'] = ip_address();
if ($user->uid && module_exists('profile')) { //Removed
profile_load_profile($user); //Removed
} //Removed
// $special_tokens['unsafe']['%profile'] = $user; //Removed
// Doesn't really belong here with user things, but works.
$special_tokens['unsafe']['%server'] = $_SERVER;
}
?>
#7
Same thing as awolfey... not a patch, because it's not a fix, but a way around :)
The problem is that it will only pass the if statement the first time:
// User replacements.if (!array_key_exists('%username', $replacements['unsafe'])) {
Therefor, only the first time the $special_tokens will be added.... and only the first $string will be checked in
if (strpos($string, $token) !== FALSE) {I'm not really sure what the design was of this code, so wouldn't know what the proper fix would be :)
<?php foreach ($special_tokens as $safe_state => $tokens) {foreach ($tokens as $token => $variable) {
// if (strpos($string, $token) !== FALSE) { /* Comment this rule */
foreach ($variable as $key => $value) {
// This special case for profile module dates.
if ($token == '%profile' && is_array($value) && isset($value['year'])) {
$replacement = format_date(strtotime($value['month'] .'/'. $value['day'] .'/'. $value['year']), 'custom', 'F j, Y', '0');
}
else {
$replacement = (string) $value;
}
$replacements[$safe_state][$token .'['. $key .']'] = $replacement;
}
// } /* Comment this rule */
}
}?>
Commenting the if statement does get the profile fields working.
#8
Subscribing.
#9
I've been using my solution in #6 in a development site with no problems. I have not tested it with the new security improvements in mind.
#10
Subscribing.
#11
While #6 works, and #7 probably does too, #6 over does it. To fix the issue, simply move the 'profile' functions outside of the User replacements logic.
Change this:
// User replacements.
if (!array_key_exists('%username', $replacements['unsafe'])) {
$replacements['unsafe']['%username'] = isset($user->name) ? $user->name : '';
$replacements['unsafe']['%useremail'] = isset($user->mail) ? $user->mail : '';
$replacements['unsafe']['%ip_address'] = ip_address();
if ($user->uid && module_exists('profile')) {
profile_load_profile($user);
}
$special_tokens['unsafe']['%profile'] = $user;
// Doesn't really belong here with user things, but works.
$special_tokens['unsafe']['%server'] = $_SERVER;
}
To this:
// User replacements.
if (!array_key_exists('%username', $replacements['unsafe'])) {
$replacements['unsafe']['%username'] = isset($user->name) ? $user->name : '';
$replacements['unsafe']['%useremail'] = isset($user->mail) ? $user->mail : '';
$replacements['unsafe']['%ip_address'] = ip_address();
// Doesn't really belong here with user things, but works.
$special_tokens['unsafe']['%server'] = $_SERVER;
}
if ($user->uid && module_exists('profile')) {
profile_load_profile($user);
}
$special_tokens['unsafe']['%profile'] = $user;
This is due to $replacements being a static array, '%username' isn't in the array the first time, so the 'profile' replacements gets loaded the first loop, but never gets loaded again.
Edit: Changed slightly,
$special_tokens['unsafe']['%profile'] = $user;now outside of the$user->uidlogic to prevent an issue that arose, causing unused %profile tokens to not be removed.Cheers,
Deciphered.
#12
While #11 is working and more probably 'right' then #6 or #7, it does do the profile_load_profile($user) each time a string gets passed through.
Again, I don't know if this is by design, but that doesn't feel right.
#13
@ #12,
The problem that was occurring was that it wasn't being run every time. So to solve that, you make it run every time.
Three options I can see are:
- Make $special_tokens a static array, but I don't know enough about static arrays.
- Wrap some extra logic around the code so that it only runs if there is a %profile token in the string for replacement.
- Replace the the replacement code section with tokens module support.
While all three options are valid, the fix I posted works for me at this stage and I have no time, nor I suspect does quicksketch, so if you have the itch, feel free to scratch it.
Cheers,
Deciphered.
#14
Subscribing.
#15
Subscribing.
#16
#17
Slight modification to #11
<?php
// User replacements.
if (!array_key_exists('%username', $replacements['unsafe'])) { $replacements['unsafe']['%username'] = isset($user->name) ? $user->name : '';
$replacements['unsafe']['%useremail'] = isset($user->mail) ? $user->mail : '';
$replacements['unsafe']['%ip_address'] = isset($_SERVER['HTTP_X_FORWARDED_FOR']) ? $_SERVER['HTTP_X_FORWARDED_FOR'] : $_SERVER['REMOTE_ADDR'];
// Doesn't really belong here with user things, but works.
$special_tokens['unsafe']['%server'] = $_SERVER;
}
// if we have a user and module profile and the %profile key doesn't exist
if ( $user->uid && module_exists('profile') && !array_key_exists('%profile', $replacements['unsafe']) ) {
profile_load_profile($user);
$special_tokens['safe']['%profile'] = $user;
}
?>
#18
Same issue here. Thanks for the work on this issue so far. Subscribing.
#19
Subscribing.
#20
Subscribing.
#21
#17 worked for me.
#22
Actually, #17 doesn't work.
If you have a %profile token as a default for a field, the non-existent default won't be removed, that is the exact reason why I edited my code in #11.
$special_tokens['safe']['%profile'] = $user;has to be run whether or not there is a $user->uid.#23
subscribe
#24
subscribing
#25
Subscribing
#26
subscribing
#27
seeing this also with the 5.x version
#28
suggested change in #11 or #17 makes it work - BUT then profile_load_profile() is executed many times for each webform
#29
Here's a 5.x patch that seems to fix the issue and the code is only executed once - it relies on the fact that uid is always a $user field.
Should be essentially the same for 6.x
#30
Above patch still seems to break for anonymous users.
This works, but not sure if it's really right... populates profile fields also for anonymous
#31
no, this one is better
#32
Thanks pwolanin, #31 looks good to me.
#33
subscribing. #11 worked for me BTW.
seems to me the bug was introduced in 6.x.2.8 as I had a slightly older copy of the same site at my localhost which had Webform 6.x.2.7, where all was fine.
#34
Whilst I appreciate everyone's efforts to provide patches, I am concerned that there has been no official fix for this in 2 weeks. We now have a choice between production sites running 6.x-2.7 which is not secure, and 6.x-2.8 where there is a choice of unconfirmed patches. This is a pretty serious problem and I feel it deserves time from the module maintainers, and a 6.x-2.9 to correct this.
#35
We are running #31 in production.
#36
chris.cohen: I would like to say that I've offered co-maintainership of this module to 4 different people over the last 6 months, only one has accepted and it hasn't been enough to handle the massive amount of requests that come through the Webform issue queue. There's an open issue for exactly this problem #604930: Webform Needs Another Maintainer. Hopefully some other developers will step forward to help with the project, until then we can expect long response times and limited release cycles.
#37
Patch in #31 is broken
Change
if (!isset($replacements['unsafe']['%profile[uid]'])) {
to
if (!isset($replacements['unsafe']['%profile'])) {
--glen
#38
#35 and #37 go quite some way to establish the perils of deploying patches in a production enviroment, although I am sure the patch in #31 was created in good faith and does work in some situations. Passing a good set of simpletests would go a long way to assuring robust patches, as is the way now in core.
#39
@glen -
#13#31 is a D5 version patch, so may be slightly different for D6#40
@pwolanin... Dyslexic much? :) I'm guessing that was meant to be #31, not #13.
#41
Subscribing.
#42
#31 converted to 6.x works for me too. I did not need to do #37. Here is the same patch, but for 6.x.
#43
subscribe
#44
It looks like patches in #31 and #42 are correct. #37 will work but it doesn't server the purpose of preventing multiple profile loading. %profile is never set as a key in the $replacements variable, so it would always return FALSE and load the profile again for every replacement. I've committed #31 to the 2.x branch for D5/6 and the 3.x branch for D6.
As I'm sure this is a problem for a lot of users I'll be putting out 2.9 shortly with the fix.
#45
hm, just tried the new 2.9 branch. The %profile - default tokens now are working fine for authenticated users, however still appear as token-code for anonymous users accessing the webform (instead just displaying clean form fields).
Any chance to fix that soon?
#46
I have also experienced this behavior in 2.9
#47
I put this patch together based on several others found on this page. It fixes both anonymous and authenticated user profile tokens on my site. This patch is based on the 6.x-3.x webform module as of today.
#48
I just noticed comment #37 ... that is a much better way to handle the token issue with anonymous users than adding to the special_tokens array. Please find a new patch attached.Disregard this patch...as pointed out below it does not deal with static caching ... the previous one is better for head.
#49
Sorry I thought I had committed #42 to 3.x but I had not. Comment #37 is incorrect and does not do any static caching at all (see my comment in #44). I've now committed #42 to 3.x (HEAD).
#50
Reverted back to my patch at #11 as the committed patch still shows '%profile[field]' if the field hasn't got a value.
May not be the best patch, but it just works.
#51
Agreed, the committed patch still shows '%profile[field]' if the field hasn't got a value.
#52
This looks to be permission related somehow.
When I log in under User 1 the field defaults correctly from the users profile entries. When I use an 'administrator' log in credentials it still works. When I use an ordinary authenticated user it's broken. I've tried changing the permission settings but can't seem to get the authenticated user details to pass over.
For what it's worth. Might help someone figure it out.
#53
Well, looks like I spoke too soon. #11 works fine for logged in users but not for anon users (I thought I had checked that, but apparently not). To get it to work for anon users as well, I had to do the modification in #37. Now everything works OK (tested by me and the client now).
#54
Subscribing. Thanks for your work, quicksketch. Wish I could help - I'm just a php newbie, though.
#55
I applied the fix in #11 to a 6.x-2.9 site (this fix has been edited) and it got rid of the problem for anonymous and authenticated users.
#56
Subscribe. Hoping for a 2.10 release that fixes this. otherwise will be submitting a patch by wednesday.
#57
A patch would be appreciated.
#58
Note: The same problem happens with %server[key] values. They are no longer processed. It is useful when displaying webforms in blocks, for example to know from which page the webform submission was made thanks to %server[REQUEST_URI].
#59
I confirm that %server[REQUEST_URI] has stopped working.
#60
Updating the title to reflect more accurately the issue.
#61
Hey
I just installed the webform module and tried to access some profile fields but in the results i only get %profile[profile_****]...does this have to do with this bug or am I doing something wrong??
Kindly,
P
#62
Could anyone please answer?
When submitting a form, the first default value field filled with a profile value is blank and the rest of the fields are filled with %profile[profile_****]. Has this to do with this bug or am I doing something wrong??
Kindly,
P
#63
Hi filpet, yes it sound very much like that happens because of this bug.
#64
Will this bug be fixed soon? I really need this to work until christmas!
#65
filpet,
I have been using the fix I wrote at #11 on a production site for some time now and have had no issues. While it is entirely up to you, if you need something to work by a certain time it's often best to take matters into your own hands and deal with any of the potential consequences.
Cheers,
Deciphered.
#66
I hope this issue is fixed soon. I am getting %profile tokens in my fields when I load the webform as anonymous user.
I will try the fixes mentioned above...
edit: #11 fix works for me
#67
I think the problem with #11 is potentially in terms of performance the same tokens are generated many times. So, it may be funcitonal, but not really correct in terms of a commitable fix.
#68
pwolanin,
I completely agree with you, and think I also stated as much in the post itself, but the fact that it is the only functional fix means that it is the only fix anyone can use at this time, and while it shouldn't be committed neither should the non-functional fix have been committed.
If I have some time I will attempt to look at the issue again, but as it is working for me at the moment it isn't on the top of my priority list.
Cheers,
Deciphered.
#69
I'm using my fix in #6 on a site that just went into production.
#70
I have version 2.9 installed, and it seems almost like a patch from #47, with 1 (obviously very significant) difference - 1 line is missing...
So, I've put this extra line:
'%session' => $_SESSION,'%post' => $_POST,
'%request' => $_REQUEST,
+ '%profile' => $user,
),
);
(it is line 2171 in my file...)
and everything seems to work fine...
#71
Subscribing.
I tried #11 with custom markup and hidden form elements with no luck.
#72
Subscribing
#73
Using Webform 2.9, still broken (for me).
#74
Has anyone seen a behavior where tokens work in one browser but not in others? I'm experiencing an issue where %request values work in Firefox but not in IE or Chrome. I can post this as a separate ticket, but it seems related to this one, anyone have any insight?
#75
The micropatch in #70 works for me (using webform 6.x-2.9). Anonymous users now don't get to see the %profile[fieldxxx] placeholders. Authenticated users have their fields prefilled. Perfect.
Any chance to get a blessing on this from the maintainers?
#76
I also can confirm the one-line fix in #70 works for me for webform 6.x-2.9, exactly as described above.
#77
Great, #70 solved it all for 5.x-2.9. Thanks for this 1-liner!
#78
Actually, regarding #70: I do not understand why %profile is set to $user. Setting it to array() should be enough, I think:
'%session' => $_SESSION,'%post' => $_POST,
'%request' => $_REQUEST,
+ '%profile' => array()
),
);
Patch file attached.
#79
#6 just work well for me, thanks for sharing.
#80
#78 with array() fixes %profile[xxx] appearing in fields for me.
#81
Subscribing.
#82
#78 with array() fixes %profile[xxx] appearing in fields for me, too.
#83
uhmm so which of these patches should i use for d6?
#84
@ #83 current dev version works
#85
Thanks =]
#86
Thank you frodo looijaard, it works for me too :)
Julie
#87
is #78 the whole patch OR is it a revision of #70 and is #70 a patch of a patch and which patch?
it ought to be illegal to post patches to patches. could someone who understands the patch that
best solves the problem please post the patch in its entirity?
#88
another curious observation.
in my case the it also print '%profile[x]' in the webform field for the anon user...BUT it does not do it for all the fields!
Some of the fields for which I had specificed %profile default fields are blank just as they should be.
I wonder how that could be?
#89
@webmaster_prwa
If you'd read the text in #70, you would realize it is not the patch of a patch, but just 1 single line I've added to the original file... ;-)
So is the later solution, I guess.
#90
Sorry about that @LUTi I just was having a bit of trouble following the thread.
As I understand your fix it simply adds %profile to the list of 'unsafe' meta words.
Anyway I added the one line patch proposed in #78 and it works great.
Thanks for the fix!
#91
I understand you perfectly - with many modules / issues I have the same problem. I've even gave up with TinyMCE module (at that time; I think it is WYSIWYG or something like that now, but I am happily using TinyTinyMCE...) due to that. And, there are some other (quite messy ones) here, but (unfortunately) can not get rid of them that easy... ;-)
It is important that you've fixed it.
BTW, it was not my patch (have no idea what it actually does, nor I care much about that...). It was just a (diff) comparison of some previous versions with the recent (problematic) one. I've tried to revert a piece of code back (to where this was not an issue, and it seemd to resolve it - so, I've just reported that (in case someone else wants to try it, or work further on it...).
Rgds,
LUTi
#92
Has anyone gotten %server[HTTP_REFERER] to work? Looking through this issue, it looks like people have figured out the profile stuff, but I need to collect referers and user agent strings.
#93
@ #92 - profile stuff works - HTTP_REFERRER doesn't - as i recall, this is intentional to plug a security hole, so don't bother trying...
in the end what i did is give up on webform and used a content type instead (with autofill fields to get HTTP_REFERRER, etc.), hardly ideal for data capture and you can't make use of other webform goodies, but also has some advantages (like more flexibilty in views, etc) - hope that helps!
#94
In order to fix the %profile[profile_last_name] issue for Anon users (see screen-shot), is there a suggested/recommended solution for 6.x-2.0-beta6?
Can't seem to marry up patch/diff line numbers within webform.module for beta6.
#95
I don't support old versions of the module. You'd need to update to the latest version of the branch you're using.
#96
subscribe
#97
if connect and submit form with user "admin", works correcly. But if i have user anonymous and submit form, not works correcly.
this happens with the last version.
#98
@eloiv The %server, %post, and %profile tokens intentionally do not work for anonymous users, as they may cause information disclosure if page caching is turned on. See #605572: %server variable no more accessible by anonymous users
#99
Patch in #78 worked for my site running 6.x-2.10. Anon users no longer get the %profile{...} codes.
#100
confirmed #70 worked for me (using webform 6.x-2.10 - line 2190 in webform.module add line 2191: " '%profile' => $user," )
#101
thanks for information :)
#102
The 2.x version is no longer supported and I won't be making any further releases. The officially recommended approach is to upgrade to 3.x, in which this problem has been fixed.