Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Hello i catch warning on php 5.4
Warning: Illegal string offset 'data' in template_preprocess_calendar_month() (line 44 of /var/www/***/htdocs/sites/***/modules/contrib/calendar/theme/theme.inc).
Comment | File | Size | Author |
---|---|---|---|
#78 | calendar-illegal_offset-1471400-78.patch | 1.96 KB | Garrett Albright |
Comments
Comment #1
KarenS CreditAttribution: KarenS commentedCan't reproduce this. Make sure you are testing the latest dev versions of both Date and Calendar and clear the caches.
Comment #2
dizarter CreditAttribution: dizarter commentedSame thing here, only in calendar Multiday. Latest versions of date and calendar modules.
On one test machine it doesn't show this error, while on the other (exact same drupal instance on both) it throws this
Seems to have something to do with PHP 5.4, since that is the version of PHP installed on the second machine (other then that, environment is the same)
Comment #3
dizarter CreditAttribution: dizarter commentedThere are occasions when key index "data" doesn't exist for some rows in $vars['rows'].
This simple check fixed the things for now until I find more time to backtrace what's causing the key to sometimes not be set in the first place.
File "calendar/theme/theme.inc", "function template_preprocess_calendar_month", line 197 reads
change to
Comment #4
dcoulombe CreditAttribution: dcoulombe commented@dizarter, I think it would be better this:
Comment #5
benhelps CreditAttribution: benhelps commentedYep #4 worked for me.
Comment #6
johnweston CreditAttribution: johnweston commentedI found this issue in php 5.4.4 MAMP latest date module, 7.x-2.6 latest calendar module, 7.x-3.4 but the error message was line 37 - used #3 -works ok now. Fantastic modules btw.
Comment #7
ksignorini CreditAttribution: ksignorini commentedMe too. But I found it at line 38 I believe.
Thanks.
Comment #8
Sdhooge CreditAttribution: Sdhooge commentedI also have the issue with 7.3.4.
The template_preprocess_calendar_month function is called twice. The first time $rows contains an array of "cached values" of what will be created by the second call (I guess) -- this is at this time that the warnings are printed. The second call is provided with the expected structure of values.
First call:
Second call:
My workaround is to put the following test before using the 'data' key.
I can provide you with additional var_dumps if you want.
Cheers
Comment #9
njogz CreditAttribution: njogz commented#3 worked like a charm. Thanks. Loving the drupal community!
Comment #10
ParisLiakos CreditAttribution: ParisLiakos commentedadding tag
Comment #11
zeineddin CreditAttribution: zeineddin commented#3 or #4 worked fine for me... thanks...
Comment #12
rickmanelius CreditAttribution: rickmanelius commented#3 and #4 in patch form... I just got snagged with this on D7 as well.
Setting to needs review...
Comment #13
clearviz CreditAttribution: clearviz commented#3 worked for me as well!!!
Thanks!
Regards,
Arnold
Comment #14
IreneKraus CreditAttribution: IreneKraus commentedI was pointed over to this thread from: http://drupal.org/node/1591388#comment-6660914
So I see there is a patch up now, as I still can't see where to put these patches into the current release version. Now I have to remember how to install a patch.
Comment #15
Anonymous (not verified) CreditAttribution: Anonymous commentedThe patch worked for me. Thanks, rickmanelius.
Irene Kraus, here is some info on applying patches:
http://drupal.org/patch/apply
http://youtu.be/i-oe7_qHreY
The video is nice to hear someone talk you through it. It helped to clarify for me to save the patch in the module dir. Basically, you need to use the command line and if you're:
cd module
)then just use
patch -p1 < file.patch
Comment #16
IreneKraus CreditAttribution: IreneKraus commentedPatch in #12 worked perfectly! Thanks for pointing out how to install patch info too. Got Netbeans IDE re-installed here for that purpose and (I think) setup as outline here for use with Drupal:
http://drupal.org/node/1019816
That page probably needs an update as the template they mention for use inside Netbeans never made it out of development. In any case, once I did have Netbeans up and running, following the directions here did the job:
http://drupal.org/node/60179
Thanks everyone! One more issue resolved and a few more to work out, like why Subscriptions suddenly stopped sending out notices like it should when it went from my test server over to the actual one... Never ends!
Comment #17
insignis CreditAttribution: insignis commentedGot this on calendar month view only, lines 38 and 43, upgrading Drupal from 7.11 to 7.17 and the latest ubuntu-bitnami platform. #4 fixed me right up.
Comment #18
insignis CreditAttribution: insignis commentedComment #19
PhilY#4 works for me with MAMP and PHP 5.4
Thank you
Comment #20
mindfullsilence CreditAttribution: mindfullsilence commented#4 worked for me. MAMP - PHP 5.4.4
Comment #21
phoohtoo CreditAttribution: phoohtoo commentedyes.. thanks.
is worked for me.
Comment #22
davidneedhamPatch in #12 works for me as well.
Comment #23
Zyfraglover CreditAttribution: Zyfraglover commented#12 worked like a charm, thx :-)
Comment #24
erifneerg CreditAttribution: erifneerg commentedpatch removed the error for me too. thanks alot!
Comment #25
rickmanelius CreditAttribution: rickmanelius commentedHey KarenS! Any chance we can get this committed? It looks like we've had several successful reviews!
Comment #26
marcvangendI'm seeing the same error.
I haven't looked into the technical side of this problem, but I can understand that Karen did not commit this patch yet. A patch that gets rid of a warning does not necessarily fix the problem. If template_preprocess_calendar_month() is called twice (as said in #8), we need to know why. Maybe that function should not be called twice in the first place - I don't know.
Patched should always be rolled against the development branch, so I'm setting the version to 3.x-dev. The patch from #12 should still apply to that branch.
Comment #27
IreneKraus CreditAttribution: IreneKraus commentedPardon my confusion as I ask for a bit of clarification! Although I've been using Drupal to run sites for more than 5 years, I'm still VERY new to the testing and committing of patches process. From what I gather, once the patch has been tested favorably by the community, then a change need to be made to suggest integration into the latest development version?
This does make sense as (I'm assuming) it means the patch is ready for review by the maintainer(s) to ensure it integrates smoothly into the next release. Assuming that aspect of things goes well, then the doubled errors should finally be resolved in the next release. Please forgive my belaboring what may seem an obvious point, but understanding how to organize contributions from so many great 'cooks' coordinating their additions to the 'stew (code)' in our pots that is a typical Drupal site is pretty amazing!
Comment #28
marcvangendIrene, your understanding of the development process is mostly correct. Every project (like in this case "calendar") has one or more maintainers. The community can test and review patches, but the maintainer acts as gatekeeper, deciding if a patch proposed by the community is good enough to become a part of the code. There are several criteria to judge a patch. Of course it needs to solve the problem, but there's more. It needs to do so correctly, in readable code, without introducing new problems, respecting the coding standards, etc etc.
That's why I wrote my comment in #26: I can see that the patch removes the warning, but I cannot judge if it's good enough to be committed.
If you want to know more about this topic, let's not derail this issue but find me (or someone else) in the #drupal channel on IRC.
Comment #29
pingers CreditAttribution: pingers commentedThe issue seems to be that E.g. calendar_build_month() goes through and renders rows of the calendar, then at the end adds the headers.
The headers are not rendered, so they're still a renderable array when template_preprocess_calendar_month() is called.
I agree with isset() solution in #4 - just skip already rendered items, which code just after attempts to do as well...
I don't know of the case when this logic would actually apply though - didn't get that far.
(closed a bunch of duplicate issues too)
Comment #30
fredfab CreditAttribution: fredfab commentedPatch #12 works like a charm!
Thanks.
Comment #31
jbrown CreditAttribution: jbrown commented#12 works! please commit
Comment #32
mcnicholl CreditAttribution: mcnicholl commentedpatch #12 worked for me too :-D
Comment #33
savithac CreditAttribution: savithac commented#4 worked for me. thank you so much.
Comment #34
fcedillo CreditAttribution: fcedillo commented#4 works for me
that is the solution in code
thanks dcoulombe
Comment #35
A-snowboard CreditAttribution: A-snowboard commented#12 perfect.
Tank you.
Comment #36
thekevinday CreditAttribution: thekevinday commentedThe above patch only hides the actual problem.
Here is part of what is happening:
- (somehow) the $rows data is being rendered/preprocessed before the template_preprocess_calendar_month() function is executed.
- during the template_preprocess_calendar_month(), the unprocessed and the processed versions of the same data get merged together.
- The foreach loop ends up trying to render the already rendered content, thus producing the described error message.
This can be easily be observed by simply deleting the entire foreach loop inside of the template_preprocess_calendar_month() function. You will notice that the month calendar still gets rendered despite the code removal!
After deleting the foreach array, I noticed that the "year" calendar view stopped functioning properly. The year view calls the month preprocess view, but for some reason, does not have the already processed rows.
As a workaround and a proof of problem, I created a patch that does the mentioned code removal from the month preprocess function and also adds the removed code to the year preprocess function.
This patch does not address the problem with the rows in the month view being pre-pre-processed. I am not sure what is going on there but it looks like it might be happening somewhere in the render() function of includes/calendar_plugin_style.inc
Comment #37
RoySegall CreditAttribution: RoySegall commented#12 didn't fix all of the problem - i had the same problem that @pingers(#29) complained about.
We can just use is array or something like this to solve this but i must say that @thekevinday also fix the errors problem. but it seem to be a big patch with to much logic (why use sizeof($rows)? you can use count($rows))
Comment #38
thekevinday CreditAttribution: thekevinday commentedThe nice thing about diff is that it uses the most efficient way to show the changes.
The bad thing about diff is that it uses the most efficient way to show the changes.
In this case, that patch in #36 does not show what is actually being done.
I did not add any new code, but instead used existing code and moved (or copied) it around between two distinct functions.
The chunk that has the sizeof() call is from the top of the function: template_preprocess_calendar_month().
Compare the functions template_preprocess_calendar_month() and template_preprocess_calendar_mini() both before and after my patch (from the file: theme/theme.inc).
I think that to properly solve this issue someone needs to figure out why template_preprocess_calendar_month() already has the calendar month data built before that function is even called to build the calendar month data.
Comment #39
fquran CreditAttribution: fquran commentedI added this instruction in function template_preprocess_calendar_month in theme.inc and fix all of the problem.
$month_rows = $rows;
foreach ($rows as $weekno => $row) {
foreach ($row as $day => $data) {
+ if (!is_array($data)) {
+ continue;
+ }
}
Comment #40
RoySegall CreditAttribution: RoySegall commented@fquran - Any patch?
Comment #41
ToRum CreditAttribution: ToRum commented@RoySegall: look at #12 for an ignoring but working workaround.
Patch #36 works fine for me.
Think you're right but I'm not able to find the core reason.
Comment #42
RoySegall CreditAttribution: RoySegall commented@ToRum - #36 works for me, that's why i'm using him and #12.
Any way, i'll try to hit the debugger and see what's wrong.
Comment #43
bblancha CreditAttribution: bblancha commentedI don't know if this helps but maybe we are missing something else here. I have PHP 5.2 using calendar (latest versions of everything) on an active site and do not get the error on the Month page.
Changing to PHP 5.4 causes this problem to appear. I know there is a change in behavior between the two versions especially w.r.t. string array indexes. Is there something about the change in PHP that affects the intended logic?
Comment #44
csmcreative CreditAttribution: csmcreative commentedI apologize for posting too fast. I guess everything has been fixed because now there are no issues. I didn't have to do any fixes or edits to the code. I created a new view from the calendar template and it seems I am good to go. Thanks.
Comment #45
hmartens CreditAttribution: hmartens commentedThank you, #12 worked for me...I wish this important module could be more actively maintained?
Comment #46
hmartens CreditAttribution: hmartens commentedBUT, kudos to the maintainers for building and maintaining this amazing powerful module!!!
Comment #47
bblancha CreditAttribution: bblancha commentedI have resorted to #4 with success. I still think it masks a couple of problems. First PHP 5.4 does not support the same behavior as PHP 5.2 when using object indexes [see PHP 5-4 release notes] so it I possible that PHP 5.2 behavior masked the second issue of rendering an already rendered object.
In anycase, I tried the latest Dev code without luck. Edited and checked all views date field settings etc.
No luck. So I reverted to released code 7.x-3.4 and edited the theme.inc file as in #4. OK for now.
I only wish I could help but it is daunting to try to figure out what is going on. Thanks to all for putting eyes on this.
Comment #48
yann64 CreditAttribution: yann64 commentedMaybe some more information that could help trace pack the problem:
The same problem happened to me after upgrading the date_ical module to the7.x-2.8 version, not after upgrading the calendar module. Requirement for the date_ical module have PHP 5.3.16 so I upgraded my website to that version, and did the date_ical module upgrade at the same time, so I don't know what the source of the problem is (PHP version? date_ical 'interference'?).
Comment #49
sonicthoughts CreditAttribution: sonicthoughts commentedSame issue on PHP 5.4 upgrade. Can't determine best course from this thread - will try several approaches.
--- Update. Applied seems to work!
Comment #50
ParisLiakos CreditAttribution: ParisLiakos commentedComment #51
ParisLiakos CreditAttribution: ParisLiakos commentedand the tag again
Comment #52
gaofeng CreditAttribution: gaofeng commentedUsing the latest version of Drupal, latest version of the Calendar module and using PHP 5.4.16.
Same problem here. Added the lines mentioned in #4, works like a charm now. Thanks dcoulombe.
Comment #53
sonicthoughts CreditAttribution: sonicthoughts commentedHope @KarenS or another maintainer is looking at this thread. Seems like many of the patches will address the problem but hope it makes it into dev/release.
Comment #54
webengr CreditAttribution: webengr commentedwell, this problem is still around.. a year and half later ?
In the past I have manually created views and did the 'calendar' without "Add View from Template"
But I tried the template and got this error 8/27/2013 with stable, updated with the 2012 dev... still an issue.
SO like is this really not a problem so no need to fix or update the devel with #4 or #12 ?
Did this on the dev-
Comment #55
thekevinday CreditAttribution: thekevinday commentedSo far all we have are workarounds.
#12 is supposed to be #4.
#12 is considered to not work according to: #37
(and didn't work for me as well).
Don't forget #36.
All the patch does is relocate code.
There is actually no new code added, just existing code is relocated or removed.
Comment #56
madbull CreditAttribution: madbull commentedComment #4 worked for me in the month tab of the calendar.
However in the year tab I have the same error now. Any updates on this issue?
Comment #57
thekevinday CreditAttribution: thekevinday commentedmadbull, thats the issue mentioned and workaround in #36.
Comment #58
RoSk0I think there is nothing wrong with logic of this file, at least there is nothing we can do right now, but there is what to do for major version change.
As for now to fix PHP 5.4 issue we just simply move data check just couple lines above and that's all.
Patch attached.
Comment #59
edvanleeuwenSuccesfully tested the patch with PHP 5.5.
Comment #60
RoySegall CreditAttribution: RoySegall commented@edvanleeuwen Did you apply any patch? If so, which one?
Comment #61
edvanleeuwenYes, I applied the patch of #58.
Comment #62
colanThe code looks good, and it works for me.
Comment #63
jlea9378 CreditAttribution: jlea9378 commentedWorked for me also on PHP 5.4
Comment #64
idflood CreditAttribution: idflood commentedHad the same issue and after applying the patch in #58 the problem was solved.
Comment #65
k.skarlatos CreditAttribution: k.skarlatos commentedworks for me as well, thanks!
Comment #66
gbirch CreditAttribution: gbirch commentedI can confirm this is a PHP 5.4 problem. I have the exact same site running on 2 boxes, one with 5.3, the other with 5.4. Errors appear only on the 5.4 box.
Patch from #58 works for me too. Thanks!
Comment #67
pingers CreditAttribution: pingers commentedPlease stop posting. The 40th confirmation was enough. Thanks.
Comment #68
mattsmith3 CreditAttribution: mattsmith3 commented@pingers- can we get a commit?
Comment #69
rick3455 CreditAttribution: rick3455 commentedThanks a lot guys...dcoulombe & dizarter
Comment #70
MXTPatch in #58 works for me also.
Can this be committed please?
Thank you very much
Comment #71
fenstratAlso confirming that #58 is RTBC.
Comment #72
ExTexan CreditAttribution: ExTexan commentedContrary to what @gbirch stated in #66, I got this error running PHP 5.3.27. Applying the patch in #58 fixed it.
Just in case someone else finds this thread who is *not* on 5.4.
Comment #73
steinmb CreditAttribution: steinmb commentedPHP 5.5.6
Drupal 7.24
Calendar 7.x-3.4
Confirm this patch remove the warnings and does not seems to break anything. RTBC from me though I did not try applying this on top on HEAD.
Comment #74
stephenebersole CreditAttribution: stephenebersole commentedAvoid "Notice: Array to String Conversion in calendar-mini.tpl.php
I am no PHP expert, but if it helps anybody else, I found that by applying patch #58 to calendar/theme/theme.inc I then got "Notice: Array to string conversion... in calendar-mini.tpl.php" on the page I had installed the calendar mini display in a block.
The code in #3 which was posted by @dizarter was the code that worked without any errors.
I tried #4 where @dcoulombe suggested the use of:
but I found that it still gave me the Notice.
it seems that if you are using the calendar-mini display you need to replace
$cell = $data['data'];
with
as posted in #3.
Comment #75
kingfisher64 CreditAttribution: kingfisher64 commented#3 worked. It's line 37 in the latest dev version dated 2013-Sep-30.
@KarenS - can the fix in #3 be committed to a new stable release please :). It was suggested almost 2 years ago in April 2012 (feels odd saying that).
Comment #76
crutch CreditAttribution: crutch commentedA stable release would be great. I'm still on 7.x-3.4 for multiple sites with this error on month view. Calendar still works but just repeating errors.
Comment #77
edvanleeuwenI second that. As @pingers already said, the 40th confirmation was enough, but we would really want this to be committed.
Comment #78
Garrett Albright CreditAttribution: Garrett Albright commented#58 doesn't work for me, but this does. PHP 5.4. plz 2 commit.
Comment #79
Garrett Albright CreditAttribution: Garrett Albright commentedComment #80
SyneX CreditAttribution: SyneX commentedPatch in #78 works for me.
Comment #81
fenstratConfirming that #78 works. Marking as RTBC.
Comment #82
highfellow CreditAttribution: highfellow commentedPatch #78 works for me. Tested week, day, and year tabs as well as month.
Comment #83
Christopher Riley CreditAttribution: Christopher Riley commentedPatch 78 worked like a champ for me thanks.
Comment #84
deggertsen CreditAttribution: deggertsen commentedConfirmed. #78 works.
Comment #85
JollyDonky CreditAttribution: JollyDonky commentedApology in advance for "newbie" rant:
I'm a new user, but have enjoyed learning Drupal to maintain a website for my town's "Prairie Arts Center",
doing everything successfully (so far) through Windows FTP,
and everything else through the website's admin menu.
http://frontdoor.biz/pac
It has been a lot to learn for someone with no previous experience, but so far everything has worked GREAT!
The little town of Princeton, Illinois is happy.
but...
Now my host service (Bluehost) has upgraded PHP to 5.4 and the Calendar is messed up.
The main purpose of this website is to show the Calendar!,
but it seems like the only solution is that I have is to learn UNIX and figure out how to get to a shell command prompt on Bluehost to manually fix our site?
Every single Calendar user has to individually fix their version of Calendar as soon as they are forced into PHP 5.4 by their host system?
It seems insane to me, knowing how many people are using this module.
Forgive my naivete', but can't someone just patch Calendar? At least in the dev version?
Is this module still being maintained?
Is there a good alternative to Calendar?
Should I switch host service?
sorry for publicizing my frustration,
Jack (aka "the new guy)
Comment #86
ExTexan CreditAttribution: ExTexan commented[Edit: mis-read the previous comment - so I removed my follow-up question. Apologies.]
Comment #87
Garrett Albright CreditAttribution: Garrett Albright commentedYou could patch the necessary file on your local system and then just upload the patched file over the original on the server - no need for a shell account on the server if it would be bothersome for you.
Comment #88
gapa CreditAttribution: gapa commented#78 works for me to.
Comment #89
JollyDonky CreditAttribution: JollyDonky commentedoh, is that all it is?
THANK YOU #87 Garrett!
The Princeton Arts Center website is fixed!
sorry for the panic,
60% of newbie rant rescinded... (smile)
Jack (aka "the new guy")
Comment #90
bohemier CreditAttribution: bohemier commented#78 works for me as well. Thanks. Commit?
Comment #91
nmc CreditAttribution: nmc commented#78 has also worked for me so far.
Comment #92
stevenx CreditAttribution: stevenx commented#78 works. Thanks!
Comment #93
yce CreditAttribution: yce commented#78 works for me too. Thank you!
Comment #94
colanFolks: We don't need any more works-for-me type comments. All they're doing at this point is spamming everyone that's subscribed to the issue. If you'd like the patch committed, please either contact one of the maintainers directly, or become one yourself.
Comment #95
deryck.henson CreditAttribution: deryck.henson commentedTwo top maintainers have both been notified. Now we play the waiting game.
Comment #96
colanThanks. Actually though, this should stay at RTBC. "Patch (to be ported)" would be useful after the patch goes into the D7 branch, and we then want to port it to D6. As this hasn't been committed yet, we can't use that state.
Comment #97
deryck.henson CreditAttribution: deryck.henson commented@colan thanks didn't know that. I really should take a minute to read the docs...
Hopefully the two I e-mailed don't ignore messages on a daily basis.
Comment #98
cmwelding CreditAttribution: cmwelding commented#78 worked for me. Thanks.
Comment #99
flyingchris CreditAttribution: flyingchris commented# 3 worked for me.
Calendar 7.x-3.4+1-dev
Date: 7.x-2.7+6-dev
PHP 5.5.6
Thx
Comment #100
drlakshan CreditAttribution: drlakshan commentedHi Everyone, I had the same problem and patch 12 worked completely.
Thanks a lot!
Comment #101
fenstrat@drlakshan Can you test the patch in #78? Because that's the one that is RTBC, thanks.
Comment #102
Johann Wagner CreditAttribution: Johann Wagner commentedPatch #12 works, thanks.
Comment #103
fenstrat@Johann Wagner Please test the patch in #78 as it (not #12) is Reviewed & tested by the community (RTBC), thanks.
Comment #104
Hooligan CreditAttribution: Hooligan commented#78 worked for me. Thanks.
Comment #105
kyuubi CreditAttribution: kyuubi commented#78 worked for me.
Comment #106
rosborn CreditAttribution: rosborn commented#78 worked for me. Thanks for the work. I would argue that this deserves a full release as soon as possible. This bug destroyed the functionality of our calendar.
Comment #107
steinmb CreditAttribution: steinmb commentedThis have been ready for a while though this module needs help - https://drupal.org/node/92594/commits as you can see, no commits lately. So someone needs to step up else patches like this will "never" make it in.
Comment #108
cmedina CreditAttribution: cmedina commented#78 worked for me, too.
Thanks.
Comment #109
fizk CreditAttribution: fizk commentedCommitted #78. Thanks everyone!
Comment #111
fenstratThanks @fizk, great to see this finally committed.
Comment #112
IreneKraus CreditAttribution: IreneKraus commentedYes! Great work everyone and so glad to see this fix committed.
? - Assuming we want the 'fixed' version then, we should install the .dev one for now? Before I do that on my actual sites, I think I'll still do a test for each of those using this module on my test server using a backup database, etc. If anything should go wrong then I haven't screwed up an actual working site!
Comment #113
Garrett Albright CreditAttribution: Garrett Albright commentedIrene: If what you have now with just a patch is working and you don't need any other features or bug fixes introduced since the last "normal" release, I'd just stick with what works for now - you may encounter bugs or unexpected behavior with the dev release. You can then upgrade when the next full release comes out.
fizk, thanks for finally getting this committed!
Comment #114
lnh92 CreditAttribution: lnh92 commentedI'm having the issue as well. I'm new to using Drupal. I installed git, downloaded the patch, and followed the directions on the version control tab of the Event Calendar page. When I try to apply the patch, I get "error: theme/theme.inc: No such file or directory". I was wondering if anyone could help me out. Thanks!
Comment #115
fizk CreditAttribution: fizk commentedlnh92, the patch has been committed, you can try testing the latest dev release.
Comment #116
lnh92 CreditAttribution: lnh92 commentedThanks fizk!
Comment #117
Bobop CreditAttribution: Bobop commented#78 worked perfectly for me
Comment #118
JamesOakleySmall request: Please can people now stop posting that the patch in #78 works for them.
It's been established that #78 works, to the point where the (new) maintainer has committed the patch. (Big thanks for that).
The issue is marked as "fixed". Either apply the patch in #78 to the current released version, or switch over to use the -dev release until a new point release is made.
If everyone can refrain for adding "works for me" comments for two weeks, this issue will get moved automatically from "fixed" to "closed". Otherwise, we'll be here some time..!
Thanks again to fizk for becoming a maintainer, and committing this (and a few other) patch(es).
Comment #119
colanI'd recommend having the thread locked by the site maintainers if we get any more "me too" comments.
Comment #121
fazni CreditAttribution: fazni commentedThank u guys work for me (y) #3 #4
Comment #122
sanjaykaronjiya CreditAttribution: sanjaykaronjiya commentedThanx,
comment #3 worked for me!....
Comment #123
ballboy CreditAttribution: ballboy commented#3 worked for me too :-) thanks!
Comment #124
fenstrat@fazni @sanjaykaronjiya @ballboy *please* read #118.
Comment #125
nanomn CreditAttribution: nanomn commented#3 worked for me...
Comment #126
asirjacques CreditAttribution: asirjacques commentedPatch works for me too. (version 7.x-3.4)
Thanks
Comment #127
colanI just created #2354363: Lock issue thread (too many "me too" comments). Hopefully the admins will get to it soon.
Comment #128
dddave CreditAttribution: dddave commentedVersion 3.5 has this fix included.