Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Currently, there is only one known issue: The 3rd argument of function views_ui_ajax_form should not be exclicitly marked as "passed by reference". PHP 5.3 chokes on this.
Comment | File | Size | Author |
---|---|---|---|
#90 | 452384-201009161131+1000_90.patch | 633 bytes | sammys |
#78 | views-6.x-2.11-php53-v3.patch | 776 bytes | Manuel Garcia |
#52 | views-6.x-2.8-php53-v2.patch | 511 bytes | marvil07 |
#40 | views-6.x-2.7-php53-1.patch | 1.01 KB | thekevinday |
Comments
Comment #1
thekevinday CreditAttribution: thekevinday commentedSee: http://drupal.org/node/569724
Comment #2
donquixote CreditAttribution: donquixote commentedsubscribe
Comment #3
drasgardian CreditAttribution: drasgardian commentedAlso a similar issue here:
warning: Parameter 3 to views_ui_build_form_state() expected to be a reference, value given in [site_path]/drupal-6.14/sites/all/modules/views/includes/admin.inc on line 1591.
Comment #4
nicoknaepen CreditAttribution: nicoknaepen commentedI'm also having the same issue:
Parameter 3 to views_ui_ajax_form() expected to be a reference, value given in D:\web\custom sites\kazerne_dossin\includes\menu.inc on line 348.
PHP 5.3
Drupal 6.14
Comment #5
bobsather CreditAttribution: bobsather commentedI kept getting an error that would pop-up saying i had an error in my views_ui_ajax_form()....
I found the error on line 1565 of includes/admin.inc
I removed the & in front of &$views. As of now, it's working.
Comment #6
DieWaldfee CreditAttribution: DieWaldfee commentedviews/includes/admin.inc
on line 1559:
function views_ui_ajax_form($js, $key, &$view, $display_id) {
to:
function views_ui_ajax_form($js, $key, $view, $display_id) {
it works fine.
Comment #7
donquixote CreditAttribution: donquixote commented@diewaldfee:
The & on object-valued parameters is needed for PHP 4, unfortunately.
I wish Drupal 6 had never tried to be PHP 4 compatible... but now it's too late.
Comment #8
thekevinday CreditAttribution: thekevinday commentedTo my surprise the below code works.
If I set the $my_var[0] == "5" test while using php 5 series, then the last printed line will be "hi" instead of "bye"
The problem I see with this is the duplication of code..
I wonder if there is a way to truly do a #ifdef/#endif style coding as seen in C and C++ such that only the function name line gets changed based on php versions.
FYI: http://us3.php.net/manual/en/function.phpversion.php
Comment #9
merlinofchaos CreditAttribution: merlinofchaos commentedWell, we could have them both pass-through to the real function, so the duplicated code would be fairly short.
Or something along those lines.
Comment #10
thekevinday CreditAttribution: thekevinday commentedWouldn't the error still happen with php < 5?
After all, the internal function's $view is still _not_ getting passed by reference.
Comment #11
Castell CreditAttribution: Castell commentedgreatly solved diewaldfeee, thanks alot!
greets,
Castell
Comment #12
donquixote CreditAttribution: donquixote commentedCould we make a list about where each of the problem functions is called? This would help to move forward.
For views_ui_ajax_form, the only place I find is as a menu callback. The $view object is generated by views_ui_cache_load(). I think menu callbacks don't support by-reference parameters, anyway. Maybe the trick in #9 could avoid one object copying in PHP 4. If we really want by-ref in a menu callback, we need something like this:
Comment #13
fpdiver CreditAttribution: fpdiver commentedsubscribe
diewaldfeee - borrowed your fix for the moment until something is patched. Many thanks.
Comment #14
highfellow CreditAttribution: highfellow commentedsubscribe.
Comment #15
hamsterbacke42 CreditAttribution: hamsterbacke42 commented#6 saved me for now
thanks
Comment #16
bas.hr CreditAttribution: bas.hr commentedsubscribe
Comment #17
vasikesubscribe
Comment #18
marktheshark CreditAttribution: marktheshark commentedAfter updating from the stable version to the dev version, 2 warnings remain, and view editing does not work properly.
Will the fixes be committed soon, or should users manually edit the module code for the time being?
Thank you
Comment #19
Bilmar CreditAttribution: Bilmar commentedsubscribing - still seeing the error messages as well.
Comment #20
W32 CreditAttribution: W32 commentedsubscribing
Comment #21
mmbee888 CreditAttribution: mmbee888 commentedI spent all morning looking for answers and finally found it here.
Ajax error fixed.
Thank you so much. :D
Comment #22
pduchateau CreditAttribution: pduchateau commented#6 works for me !
Comment #23
obelus CreditAttribution: obelus commentedI can't solve this warning warning: Parameter 3 to views_ui_ajax_form() expected to be a reference, value given in localhost..\includes\menu.inc on line 348
there is no ampersand on this line and I don't know exactly, where can I put the written code here.
Comment #24
obelus CreditAttribution: obelus commentedafter night spent trying to solve it I finally did it. Warning always come from localhost\mysite\includes\menu.inc on line 348. this confused me. then I try to serch for "&$view" in modules\view\includes and the in file admin and view deleted all ampersands befor "$view" and warning disappeared. maybe for this time is it ok, if there will be some problem again, I will search for ampersands in other files of includes folder of viewa module. for this time, everything is working.
Comment #25
somanyfish CreditAttribution: somanyfish commentedsubscribe.
Comment #26
JeppeM CreditAttribution: JeppeM commented#6 did it for me as well.. Thanks :)
Comment #27
marktheshark CreditAttribution: marktheshark commentedNew snapshots on the dev branch keep having the problematic code.
Can't this be committed permanently?
Comment #28
dawehnerThe problem is caused because by the compabiltiy to php4. Afaik Drupal itself does not support php 5.3. either.
Comment #29
jzigbe CreditAttribution: jzigbe commenteddiewaldfeee #6 ... you are a genius!
Many Thanks,
Jan
Comment #30
peterjmag CreditAttribution: peterjmag commented#28: D6 supports php 5.3 as of 6.14. http://drupal.org/node/360605
Comment #31
XerraX CreditAttribution: XerraX commentedCan sb commit this please? Its extremly bothering to change this manually on every update -.-
Comment #32
merlinofchaos CreditAttribution: merlinofchaos commentedOk, I finally got around to getting a PHP4 install (pain in the wazoo, let me tell you) and tested without the & there, and things seem to be ok in PHP4. So I think that reference was not actually necessary. Things work fine without it in PHP5. Committed to all branches.
Comment #33
romainpi CreditAttribution: romainpi commentedsubscribe
#6 worked fine for me on windows xp with Apache 2.2.11, MySQL 5.1.36 and PHP 5.3.0!
Thanks,
Comment #34
WSRyu CreditAttribution: WSRyu commented#6 works, THNX!
Comment #35
Rollaz CreditAttribution: Rollaz commented#6 worked for me too :))
big thanks ;)
Comment #36
blitux CreditAttribution: blitux commented#6 Wonderful! This fix works for me (PHP 5.3)
Comment #37
nguyenxuannghia CreditAttribution: nguyenxuannghia commented#6 Wonderful! This fix works for me . i from Viet Nam hehehe
Comment #38
sutch CreditAttribution: sutch commentedmerlinofchaos: Thank you. 6.2-2.x-dev now seems to now be mostly working. I encountered the following warnings in a live preview of a view:
* warning: Parameter 3 to views_ui_build_form_state() expected to be a reference, value given in [site_path]\sites\all\modules\views\includes\admin.inc on line 1591.
* warning: call_user_func_array() expects parameter 1 to be a valid callback, no array or string given in [site_path]\includes\form.inc on line 371.
* warning: Invalid argument supplied for foreach() in [site_path]\sites\all\modules\views\includes\admin.inc on line 1527.
* warning: Attempt to assign property of non-object in [site_path]\sites\all\modules\views\includes\admin.inc on line 1598.
Comment #39
xslim CreditAttribution: xslim commentedSubscribe
Comment #40
thekevinday CreditAttribution: thekevinday commentedThis patch fixes both the original problem and the latest problem that caused this to be reopened
edit: I want to emphasize: Please make sure that it is safe to remove the & at this location.
Comment #41
merlinofchaos CreditAttribution: merlinofchaos commentedArgh! I wish I saw this yesterday. Oh well. Changing status so this shows up in the right place, will get to this as soon as I can.
Comment #42
thekevinday CreditAttribution: thekevinday commentedPlease consider not using my patch from #40, see my post here:
http://drupal.org/node/360605#comment-2340170
You may want to reconsider patch from #6 as well to any who applied that patch.
Comment #43
merlinofchaos CreditAttribution: merlinofchaos commentedFor #6, I tested with PHP4 and confirmed that a reference was never actually needed there. I'll have to do the same for #40.
Comment #44
wernerglinka CreditAttribution: wernerglinka commentedsubscribe
Comment #45
sepla CreditAttribution: sepla commentedfollowing.
Comment #46
jboeger CreditAttribution: jboeger commentedsubscribing.
Comment #47
m@rtijn CreditAttribution: m@rtijn commentedsubscribe
Comment #48
sunHm. Everything seems to run fine for me on PHP 5.3 -- I did not apply the latest patch.
Comment #49
marvil07 CreditAttribution: marvil07 commentedI notice the same problem on 2.7(on removing display).
After upgrading to 2.8 I did not have the problem, and making a diff, I notice the 2nd hunk is already applied on 2.8, so here we only need to review if we really need the 1st hunk(which I am still not able to reproduce a bug with):
Comment #50
dawehnerCould you create a new patch?
Comment #51
YK85 CreditAttribution: YK85 commentedsubscribing
Comment #52
marvil07 CreditAttribution: marvil07 commenteddereine: sure, here it is the last patch including only the first hunk(the 2nd is already applied in 2.8).
Comment #53
thekevinday CreditAttribution: thekevinday commentedWhat bothers me is that views gets passed as a reference inside that function for the patch mentioned in #52.
view' => &$view,
If this reference is removed, does anything break?
It just worries me that the patch might produce and hide a bug.
Comment #54
denica001 CreditAttribution: denica001 commentedThere is a little mismatch here because in the Notes of this version said that this bug is already solved and I'm pretty sure that the fix didn't ship with this version.
Comment #55
marvil07 CreditAttribution: marvil07 commenteddcaldelas: like I mention on #52 one of the two hunks of the patch at #40 is already commited, so I suppose that was the reason this nid appears on the changelog; but there is still a pending review about the first hunk of the patch in #40, which I rerolled individually at #52
Comment #56
merlinofchaos CreditAttribution: merlinofchaos commented#54: What shipped in this version was up to comment #34 -- so stuff identified after that comment is not in the current version.
Comment #57
Fa-sum CreditAttribution: Fa-sum commentedI'm having problems with Views UI after upgrading to PHP 5.3.
My actual version is the last 2.x-dev; I tried downgrading (to 2.8) and upgrading to 3.0-alpha3. Nothing went.
The error I have is this: http://nopaste.info/187ba95ae9.html
It appears as an error in the browser when trying to use the interface for creating a new block/page, etc in a display, trying to modify or add records etc.
Nothing appears in drupal logs with 2.x-dev. The only error I have is when updating:
Multiple primary key defined query: ALTER TABLE views_display ADD PRIMARY KEY (vid, id) in /home/facens3/webtelevideo/drupal/includes/database.mysql-common.inc alla riga 374.
In 2.8 the error is:
call_user_func_array() expects parameter 1 to be a valid callback, function 'views_import_access' not found or invalid function name in /home/facens3/webtelevideo/drupal/includes/menu.inc alla riga 452.
I also tried to apply the patch suggested in this topic, but nothing goes.
Thanks in advance for the helping.
Comment #58
Fa-sum CreditAttribution: Fa-sum commentedI add to have done also other changes to my drupal installation. Upgrading php is the major, but it could also be something else.
Thank you for your job and for any possible answer.
Comment #59
Fa-sum CreditAttribution: Fa-sum commentedComment #60
klonossubscribing...
Comment #61
mpisano CreditAttribution: mpisano commentedI have these errors....
warning: Parameter 3 to views_ui_build_form_state() expected to be a reference, value given in C:\xampp\htdocs\fincasa\modules\views\includes\admin.inc on line 1603.
warning: call_user_func_array() expects parameter 1 to be a valid callback, no array or string given in C:\xampp\htdocs\fincasa\includes\form.inc on line 372.
warning: Invalid argument supplied for foreach() in C:\xampp\htdocs\fincasa\modules\views\includes\admin.inc on line 1539.
warning: Attempt to assign property of non-object in C:\xampp\htdocs\fincasa\modules\views\includes\admin.inc on line 1610.
Comment #62
victoria_b CreditAttribution: victoria_b commentedI've just upgraded today to Views 6.x-2.x-dev and have the same 4 errors as mpisano. Is the module still safe to use? Are these warnings non-critical?
Comment #63
dawehnerWarnings are less than error. Views still does works.
Comment #64
g4b0 CreditAttribution: g4b0 commentedSame problem for me (views-6.x-2.9). Is there a patch out there?
Comment #65
dawehnerNo. http://drupal.org/node/452384#comment-2678668
I suggest you to read the issue.
Comment #66
Sera CreditAttribution: Sera commentedHello everyone,
I updated views to version 6.x-2.10 now. Sadly I still got the php5.3 related warning messages.
How to reproduce:
If you created a view, change access (access restriction) within the basic settings to role (choose a role you desire). If it does not appear immidiately, update the default display. If also appears if you edit the view and change the access restriction setting to permission.
The warnings are:
warning: Parameter 3 to views_ui_build_form_state() expected to be a reference, value given in [site]/sites/all/modules/views/includes/admin.inc on line 1603.
warning: call_user_func_array() expects parameter 1 to be a valid callback, no array or string given in [site]/includes/form.inc on line 372.
warning: Invalid argument supplied for foreach() in [site]/sites/all/modules/views/includes/admin.inc on line 1539.
warning: Attempt to assign property of non-object in [site]/sites/all/modules/views/includes/admin.inc on line 1610.
Furthermore if you change the style within the basic settings from e.g. table to unformatted and update your default display, the same warnings appear.
Comment #67
kais.bejaoui CreditAttribution: kais.bejaoui commentedHi,
I am using 6.x-2.10 with php 5.3.2 on linux and I am having the same errors as in #61 and #66.
The warnings occur when I try to change the style of a view under basic settings.
I applied the fix from http://drupal.org/node/452384#comment-2678668 (the line is now 1511) and the warnings disappeared.
Don't know if this really fixed the issue though ...
Comment #68
astro87 CreditAttribution: astro87 commentedI'm using Drupal 6.16 and Views 6.x-2.10 with PHP 5.3.1
I had 4 warnings like in #66.
I applied the fix from #52 and I don't see any warnings now.
Sorry for my English.
Comment #69
dawehnerLooks fine for me
Comment #70
jimshreds CreditAttribution: jimshreds commentedstill having this issue even going so fas as replacing all instances of &$view with $view.
Comment #71
junoe CreditAttribution: junoe commentedI'm not sure if I'm experiencing the same issue discussed here, but it seems so similar that I want to post and get your feedback.
I'm hosting at GoDaddy.
PHP ver. 5.2.8
Drupal ver. 6.16
Views ver 6.x-2.10
At Page: Home › Administer › Site building › Views [Edit]
* I can click a link to show the settings in the lower area - the settings update form is properly displayed
* When I make a change in the resulting form in the lower area, I get an error when updating.
I've tried several fields and get the same error:
There are no entries in the log related to this action.
If I turn off JavaScript in the browser, then the UI doesn't attempt AJAX and it loads the edit form in a new page. Making changes here works without any problem.
Is this problem related to the one discussed here or is it addressed somewhere else?
Thanks,
Eric
Comment #72
nicanorflavier CreditAttribution: nicanorflavier commentedSame issue here man.
Comment #73
Docc CreditAttribution: Docc commentedSame issue as junoe
Comment #74
mari3.14 CreditAttribution: mari3.14 commentedGreat, #52 worked for me.
Appreciated.
Comment #75
patrick_IRE CreditAttribution: patrick_IRE commented*Edited* Thought this was the same issue.
Comment #76
dawehnerPlease don't hijack issues.
Make your own new issue for this bug, this is definitive fixable.
Comment #77
Manuel Garcia CreditAttribution: Manuel Garcia commentedPatch #52 fails to apply on views 6.x-2.11, wich is understandable I guess, since the patch is for views-6.x-2.8.
And the code from the admin.inc.rej:
I'm seeing the following php warnings when switching row style, please do slap me with a large trout if I should've opened a new issue for all this...
Comment #78
Manuel Garcia CreditAttribution: Manuel Garcia commentedI've recreated the patch for the current version (checked out 2.x-dev from CVS), find it attached.
After applying it the warnings I mention above went away. Keep in mind I only redid what the previous patch did, no clue if this is the way to go or not.
Comment #79
Manuel Garcia CreditAttribution: Manuel Garcia commentedAlso, this is a problem in the 2.x branch (no clue about 3.x). It applies fine on 6.x-2.11 though.
Comment #80
Carlos Miranda Levy CreditAttribution: Carlos Miranda Levy commentedI confirm that patch #78 works fine on Views Versión: 6.x-2.11 - 17-Jun-2010.
Comment #81
parasox CreditAttribution: parasox commentedI was unable to apply the patch on my installation, it failed. I am also running 6.x-2.11
I'm a noob though and it may not mean anything.. Anyways my current error looks like this:
warning: Parameter 3 to views_ui_build_form_state() expected to be a reference, value given in /var/www/sites/all/modules/views/includes/admin.inc on line 1606.
warning: call_user_func_array() expects parameter 1 to be a valid callback, no array or string given in /var/www/includes/form.inc on line 372.
warning: Invalid argument supplied for foreach() in /var/www/sites/all/modules/views/includes/admin.inc on line 1542.
warning: Attempt to assign property of non-object in /var/www/sites/all/modules/views/includes/admin.inc on line 1613.
Comment #82
Sera CreditAttribution: Sera commentedRemoving the & in line 1511 in includes/admin.inc in
function views_ui_build_form_state($js, $key, &$view, $display_id, $args) {
helped! (#78; Views 6.x-2.11)
Comment #83
rkdeveloper CreditAttribution: rkdeveloper commented#82
solved my problems....!
warning: Parameter 3 to views_ui_build_form_state() expected to be a reference, value given in /var/www/sites/all/modules/views/includes/admin.inc on line 1606.
warning: call_user_func_array() expects parameter 1 to be a valid callback, no array or string given in /var/www/includes/form.inc on line 372.
warning: Invalid argument supplied for foreach() in /var/www/sites/all/modules/views/includes/admin.inc on line 1542.
warning: Attempt to assign property of non-object in /var/www/sites/all/modules/views/includes/admin.inc on line 1613.
Comment #84
RdeBoerYep! #78 == #82 works great!
Comment #85
donquixote CreditAttribution: donquixote commentedIt seems we need to put a hint to PHP 4.x in the title, or otherwise we will see a lot more comments like the above.
@people above:
PHP 4.x does not treat object variables as pointers/references, which is why we need to keep the & in the method/function signature.
Comment #86
Maedi CreditAttribution: Maedi commentedsubscribing
Comment #87
wouters_f CreditAttribution: wouters_f commentedin the acquia version
changing views_ui_ajax_form did it for me.
(solution described in #6)
only the location is different : modules/acquia/views/includes/admin.inc
Comment #88
dawehnerBased on #452384-85: Make Views compatible with PHP 5.3 (but don't break it for PHP 4.x) this needs work.
Comment #89
klynch3 CreditAttribution: klynch3 commented#82 - PERFECT! Thanks :D
Comment #90
sammys CreditAttribution: sammys commentedSince this needed work I figured I'd fix it up as best I can. I rejigged the code in there so converts the view parameter for views_ui_build_form_state() into a reference before calling call_user_func_array(). That seems to do the trick.
Comment #91
jcharlesberry CreditAttribution: jcharlesberry commentedsammys, where in the function does your code go? After or before current statements? Thanks!
Comment #92
jcharlesberry CreditAttribution: jcharlesberry commentedAnd what do the '+' signs mean on those two middle lines? Thanks.
Comment #93
klonos@jcharlesberry: Hey JC, the .patch files are special difference files that hold information of what has changed between two versions of the same file. Using this info one can upgrade the old file to the new one. The first lines of these files usually hold information of which files are to be patched and which lines have changed. All you have to do is find the 3 lines of code without any marking at their start in the old file and then either add lines that have a '+' sign after these lines or delete any lines with a '-' sign. Then simply save the file and you have 'manually' patched it to the new version!
More info here: Applying patches and Applying a patch manually (has some nice examples too)
Cheers mate!
Comment #94
jcharlesberry CreditAttribution: jcharlesberry commentedThanks. This has helped a lot.
Comment #95
klonosNo problem mate. Just share the knowledge next time someone asks the same thing ;)
Comment #96
ecoment CreditAttribution: ecoment commented#82 worked fine for me on views 2.x.11 and osx, great!
Comment #97
Pieter Maes CreditAttribution: Pieter Maes commentedi should not have posted here my excuse,
peace
Comment #98
dawehner#97
I would have looked into the issue, but you spammed the issue queue, sorry :)
Comment #99
Pieter Maes CreditAttribution: Pieter Maes commentedspammed ? i just added my observations its only 2 posts extra so if someone helps it can help, even if its a little help
or is there an other reason wy you say i spammed the issue queue ?
i do not have any bad intentions
to the people who think that i spamm i want to apologise and i do not expecct this to change anything towards help
i helped on other post concerning sql error and this is the first time i ask for help
Comment #100
klonos[...risking this to be considered spam too - or at least off-topic]
@pms81: I believe that when Daniel uses the term 'spam' in #98 he refers to you posting a link to another issue to this issue. The linked issue is a support request that obviously got no attention for a while and I understand why you might got frustrated and how that has led you to your post in #97, but that is not the way to go. In other words, your post here does not help this issue, thus is considered 'spam'. Bottom line is we do not try to gain attention by posting/spamming other issues. Do try to remember this and be patient instead.
@dereine: Daniel, did I get you right (regarding the use of the term 'spam' I mean)? If yes, then let me tell you ahead that I do understand you as well, but 'punishing' d.o newcomers (Pieter is a member for less than three months) is not helping us grow. Perhaps instead of being harsh on him we could just give him a hint on how to (not) behave in the issue queue and how we work here. I did notice the smile on your comment, so I think/trust that eventually you will take a look at the other issue when time permits.
Peace be with you both brothers ;)
Comment #101
dawehnerI'm sorry for what i said. This is a quite unproductive issue, sadly:
* many different problems
* some subscribers
* many confused users
Comment #102
klonosI understand Daniel. Is there any way I can help (other than code I mean, cause I cannot). I can go through the whole issue and get a summary together if you think it will help help you. Let me know ;)
Comment #103
dawehnerThis would perhaps help people so they don't have to read the full issue.
Comment #104
nickgs CreditAttribution: nickgs commented#6 seems to work for me... but is this going to be included in base any time soon?
Comment #105
klonosHi Nick,
in order to help patches move in we need to make sure we test the latest ones (but I am pretty sure you already know that - being a member for more than 4 years and all). The latest one for this issue is in #90. Did you give it a try? Or do you mean that you did try it but it didn't work for you while #6 does?
PS: I am only half way though the summary I said I'd provide in #102. Please be patient with me as my time is really limited lately. To that end... Nick can you please let us know what symptoms you had exactly that #6 solved for you?
Comment #106
miaoulafrite CreditAttribution: miaoulafrite commented+1
Comment #107
akanouras CreditAttribution: akanouras commentedSubscribing.
Removing the ampersands from function variables obviously fixed the problem for me too in views-6.x-2.11.
Comment #108
nickgs CreditAttribution: nickgs commentedHi Klonos,
Just saw your comment. I did not get to test the patch in #90. I was in the progress of migrating a bunch of sites to a new server that is PHP 5.3 and came across the same problem described in the beginning of this thread:
Parameter 3 to views_ui_ajax_form() expected to be a reference.
I will be bringing over some more sites to this server in the next few weeks. I will be sure to give this latest patch a shot.
Thanks.
Nick
Comment #109
joehudson CreditAttribution: joehudson commented@ #90 patch removed warnings for me, but the views cache behaviour seems to be very odd now. The result of using it is that page generation times quadruple (according to xhprof), not exactly the desired effect. I disabled the cache of my views to check whether the patch had the same effect on page render times without it and it seems to be a combination with the views cache (mix of blocks and pages, but the blocks take the longest to render). Strangely enough, accoring to the xhprof graphs it's affecting the load times of all the modules too. I hope that helps.
Comment #110
klonos@nickgs: no problem mate, it's just that #6 was more than one year ago! I usually read an issue from top to bottom (even the ones with too many posts) and once I need to apply patches I start from bottom to top trying the latest patches as I go (if the latest doesn't work, I then usually give a go to the previous). I guess what I am trying to say is that it stroke me kinda strange that you chose to apply #6.
Comment #111
joehudson CreditAttribution: joehudson commentedMy issue went away when I also turned on drupal page caching :) and the overall load times were about cut in half then with views cache enabled on my blocks, so I'm happy to use this patch. (still, I'm surprised that without the page cache, views cache caused such a huge increase on load times)
Comment #112
appaulmac CreditAttribution: appaulmac commentedI just downloaded Views 6.x-3.x-dev and this solves my problems with javascript errors on admin/build/views/edit/xxxx and also the warnings that were coming up. I'm using PHP 5.3
Comment #113
Maciej Lukianski CreditAttribution: Maciej Lukianski commented#90 worked for me.
I was getting the errors when using ViewsSlideshow module and changing Basic Settings > Style to "Slideshow"
PHP 5.3
Comment #114
Maciej Lukianski CreditAttribution: Maciej Lukianski commentedI patched 3 different sites with various views types till today with #90 and used them in 2 separate environments. Each time everything seems to work.
Comment #115
MustangGB CreditAttribution: MustangGB commented+1 to #90
Comment #116
dawehnerSee http://drupal.org/node/452384#comment-3328628 again
6.x-3.x does currently support php4.
Comment #117
MustangGB CreditAttribution: MustangGB commented#90 addressed #85 by not altering the function signature
Comment #118
dawehnerSorry.
Comment #119
merlinofchaos CreditAttribution: merlinofchaos commentedsammys' patch committed. Thanks!
Comment #121
nixter CreditAttribution: nixter commented"sammys' patch committed. Thanks!"
Does that mean that the patch is in the latest view code? I am getting this error still with php5.3.3 and Views 6.x-2.12. Should I be running the beta?
Below is the error.
Comment #122
klonos@nixter, #121: you need to use latest dev (look at the 'Development releases' section in the project's download list).
Comment #123
el_reverend CreditAttribution: el_reverend commentedSubscribing.
Comment #124
silkAdmin CreditAttribution: silkAdmin commented@ 122 I am running PHP 5.3.3 on and latest Dev worked for me.
Although. It didn't work right after update, i had to disable, then re-enable the view module to see changes.
Comment #125
klonos@nixter & silkAdmin: ...I generally use devs for almost every module I use, but in Views' case specifically the release cycle is kinda slow. In the 6.x-3.x branch in particular -that is the case here- there has not been a 'stable' release for a year now. So, if you want to see things marked as 'fixed' for this branch actually work, then use the dev builds since they include these fixes. The same goes for other modules with slow 'stable' release cycles too.
Comment #126
silkAdmin CreditAttribution: silkAdmin commented@klonos Thanks for the tip : )
Oh and dis-activating the development module seems to have fixed all problems!!
Comment #127
Amir Simantov CreditAttribution: Amir Simantov commented#78 worked for me on 6.x-2.12 version.
@silkAdmin
As I do not want to switch into 3.x version yet, using the DEV was not an option. I think 2.x newest version must have the patch applied just as well.
Comment #128
MustangGB CreditAttribution: MustangGB commentedSo what we need is for #90 to be back-ported
Comment #129
dawehnerThis patch is commited to 6.x-2.x already, but isn't part of the release 6.x-2.12
Comment #130
Amir Simantov CreditAttribution: Amir Simantov commented@dereine #129
But 6.x-2.x is not listed in the version list on the module page, hence obscured.
Comment #131
MustangGB CreditAttribution: MustangGB commentedHe means it's in 6.x-2.x-dev, so either use this or wait for a 6.x-2.13 release
Comment #132
Dave Kopecek#90 Worked for me. Re #131 I don't see 6.x-2.x-dev anymore, just 6.x-3.x-dev. Will 6.x-2.13 be released, or are do we have to go to 6.x-3.x-dev ?
Comment #133
jfcolomer CreditAttribution: jfcolomer commented#6 worked for me.
views/includes/admin.inc
on line 1559:
function views_ui_ajax_form($js, $key, &$view, $display_id) {
to:
function views_ui_ajax_form($js, $key, $view, $display_id) {
Thanks DieWaldfeee!
Comment #134
MustangGB CreditAttribution: MustangGB commentedIt is in 6.x-2.x-dev (and also 6.x-3.x-dev).
Here is the commit: http://cgit.drupalcode.org/views/commit/includes?h=6.x-2.x&id=3322be9084...
Comment #135
Rob T CreditAttribution: Rob T commented#6 worked for me on an old legacy installation. If other issues arise, I may revert and try some of the other proposed fixes.