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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

thekevinday’s picture

donquixote’s picture

subscribe

drasgardian’s picture

Also 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.

nicoknaepen’s picture

I'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

bobsather’s picture

I 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.

DieWaldfee’s picture

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) {

it works fine.

donquixote’s picture

@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.

thekevinday’s picture

To my surprise the below code works.

<?php
  print('Current PHP version: ' . phpversion() . "\n");
  $my_var=phpversion();

  if ($my_var[0] == "4"){
    function views_ui_ajax_form() {
      print("hi\n");
    }
  } else {
    function views_ui_ajax_form() {
      print("bye\n");
    }
  }

  views_ui_ajax_form();
?>

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

merlinofchaos’s picture

Well, we could have them both pass-through to the real function, so the duplicated code would be fairly short.

  if (version_compare(phpversion(), 5, '<') {
    function views_ui_ajax_form($js, $key, &$view, $display_id) {
      return _function views_ui_ajax_form($js, $key, $view, $display_id);
    }
  } else {
    function views_ui_ajax_form($js, $key, $view, $display_id) {
      return _function views_ui_ajax_form($js, $key, $view, $display_id);
    }
  }

Or something along those lines.

thekevinday’s picture

Wouldn't the error still happen with php < 5?

After all, the internal function's $view is still _not_ getting passed by reference.

Castell’s picture

greatly solved diewaldfeee, thanks alot!

greets,
Castell

donquixote’s picture

Could 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:

<?php
// called by menu system
function views_ui_cache_load($arg) {
  ...
  return array(&$view);
}

function views_ui_ajax_form($js, $key, $view_packed, $display_id) {
  $view = &$view_packed[0];
}
?>
fpdiver’s picture

subscribe

diewaldfeee - borrowed your fix for the moment until something is patched. Many thanks.

highfellow’s picture

subscribe.

hamsterbacke42’s picture

#6 saved me for now
thanks

bas.hr’s picture

subscribe

vasike’s picture

subscribe

marktheshark’s picture

After 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

Bilmar’s picture

subscribing - still seeing the error messages as well.

W32’s picture

subscribing

mmbee888’s picture

I spent all morning looking for answers and finally found it here.
Ajax error fixed.
Thank you so much. :D

pduchateau’s picture

#6 works for me !

obelus’s picture

I 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.

obelus’s picture

after 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.

somanyfish’s picture

subscribe.

JeppeM’s picture

#6 did it for me as well.. Thanks :)

marktheshark’s picture

New snapshots on the dev branch keep having the problematic code.

Can't this be committed permanently?

dawehner’s picture

The problem is caused because by the compabiltiy to php4. Afaik Drupal itself does not support php 5.3. either.

jzigbe’s picture

diewaldfeee #6 ... you are a genius!
Many Thanks,

Jan

peterjmag’s picture

#28: D6 supports php 5.3 as of 6.14. http://drupal.org/node/360605

XerraX’s picture

Can sb commit this please? Its extremly bothering to change this manually on every update -.-

merlinofchaos’s picture

Status: Active » Fixed

Ok, 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.

romainpi’s picture

subscribe

#6 worked fine for me on windows xp with Apache 2.2.11, MySQL 5.1.36 and PHP 5.3.0!

Thanks,

WSRyu’s picture

#6 works, THNX!

Rollaz’s picture

#6 worked for me too :))

big thanks ;)

blitux’s picture

#6 Wonderful! This fix works for me (PHP 5.3)

nguyenxuannghia’s picture

#6 Wonderful! This fix works for me . i from Viet Nam hehehe

sutch’s picture

Status: Fixed » Needs work

merlinofchaos: 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.

xslim’s picture

Subscribe

thekevinday’s picture

FileSize
1.01 KB

This 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.

merlinofchaos’s picture

Status: Needs work » Needs review

Argh! 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.

thekevinday’s picture

Please 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.

merlinofchaos’s picture

For #6, I tested with PHP4 and confirmed that a reference was never actually needed there. I'll have to do the same for #40.

wernerglinka’s picture

subscribe

sepla’s picture

following.

jboeger’s picture

Version: 6.x-2.x-dev » 6.x-2.8

subscribing.

m@rtijn’s picture

subscribe

sun’s picture

Hm. Everything seems to run fine for me on PHP 5.3 -- I did not apply the latest patch.

marvil07’s picture

I 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):

-function views_ui_build_form_state($js, $key, &$view, $display_id, $args) {
+function views_ui_build_form_state($js, $key, $view, $display_id, $args) {
dawehner’s picture

Could you create a new patch?

YK85’s picture

subscribing

marvil07’s picture

FileSize
511 bytes

dereine: sure, here it is the last patch including only the first hunk(the 2nd is already applied in 2.8).

thekevinday’s picture

What 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.

denica001’s picture

There 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.

marvil07’s picture

dcaldelas: 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

merlinofchaos’s picture

#54: What shipped in this version was up to comment #34 -- so stuff identified after that comment is not in the current version.

Fa-sum’s picture

I'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.

Fa-sum’s picture

Version: 6.x-2.8 » 6.x-2.x-dev

I 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.

Fa-sum’s picture

klonos’s picture

subscribing...

mpisano’s picture

Version: 6.x-2.x-dev » 6.x-2.10

I 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.

victoria_b’s picture

I'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?

dawehner’s picture

Warnings are less than error. Views still does works.

g4b0’s picture

Same problem for me (views-6.x-2.9). Is there a patch out there?

dawehner’s picture

No. http://drupal.org/node/452384#comment-2678668

I suggest you to read the issue.

Sera’s picture

Hello 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.

kais.bejaoui’s picture

Hi,

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 ...

astro87’s picture

I'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.

dawehner’s picture

Status: Needs review » Reviewed & tested by the community

Looks fine for me

jimshreds’s picture

still having this issue even going so fas as replacing all instances of &$view with $view.

junoe’s picture

I'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:

An error occurred at http://.../admin/build/views/ajax/display/News_List/default/items_per_page.

Error Description: 0:

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

nicanorflavier’s picture

Same issue here man.

Docc’s picture

Same issue as junoe

mari3.14’s picture

Great, #52 worked for me.

Appreciated.

patrick_IRE’s picture

Title: Make Views compatible with PHP 5.3 » Views 2 compatibility with PHP 5.3 + Drupal 6.17
Component: Code » Views Data
Category: task » support
Priority: Normal » Critical
Status: Reviewed & tested by the community » Needs review

*Edited* Thought this was the same issue.

dawehner’s picture

Please don't hijack issues.

Make your own new issue for this bug, this is definitive fixable.

Manuel Garcia’s picture

Title: Views 2 compatibility with PHP 5.3 + Drupal 6.17 » Make Views compatible with PHP 5.3
Component: Views Data » Code
Category: support » task
Priority: Critical » Normal
Status: Needs review » Reviewed & tested by the community

Patch #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.

patching file includes/admin.inc
Hunk #1 FAILED at 1496.
1 out of 1 hunk FAILED -- saving rejects to file includes/admin.inc.rej

And the code from the admin.inc.rej:

--- includes/admin.inc
+++ includes/admin.inc
@@ -1496,7 +1496,7 @@
  * Build up a $form_state object suitable for use with drupal_build_form

  * based on known information about a form.

  */

-function views_ui_build_form_state($js, $key, &$view, $display_id, $args) {

+function views_ui_build_form_state($js, $key, $view, $display_id, $args) {

   $form = views_ui_ajax_forms($key);

   // Build up form state

   $form_state = array(

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...

    * warning: Parameter 3 to views_ui_build_form_state() expected to be a reference, value given in /home/manuel/htdocs/context/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 /home/manuel/htdocs/context/includes/form.inc on line 372.
    * warning: Invalid argument supplied for foreach() in /home/manuel/htdocs/context/sites/all/modules/views/includes/admin.inc on line 1542.
    * warning: Attempt to assign property of non-object in /home/manuel/htdocs/context/sites/all/modules/views/includes/admin.inc on line 1613.
Manuel Garcia’s picture

Version: 6.x-2.x-dev » 6.x-2.11
FileSize
776 bytes

I'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.

Manuel Garcia’s picture

Version: 6.x-2.10 » 6.x-2.x-dev
Status: Reviewed & tested by the community » Needs review

Also, this is a problem in the 2.x branch (no clue about 3.x). It applies fine on 6.x-2.11 though.

Carlos Miranda Levy’s picture

Version: 6.x-2.11 » 6.x-2.x-dev

I confirm that patch #78 works fine on Views Versión: 6.x-2.11 - 17-Jun-2010.

parasox’s picture

I 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.

Sera’s picture

Removing 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)

rkdeveloper’s picture

#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.

RdeBoer’s picture

Yep! #78 == #82 works great!

donquixote’s picture

Title: Make Views compatible with PHP 5.3 » Make Views compatible with PHP 5.3 (but don't break it for PHP 4.x)

It 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.

Maedi’s picture

subscribing

wouters_f’s picture

in 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

dawehner’s picture

Status: Needs review » Needs work
klynch3’s picture

#82 - PERFECT! Thanks :D

sammys’s picture

Status: Needs work » Needs review
FileSize
633 bytes

Since 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.

jcharlesberry’s picture

sammys, where in the function does your code go? After or before current statements? Thanks!

jcharlesberry’s picture

And what do the '+' signs mean on those two middle lines? Thanks.

klonos’s picture

@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!

jcharlesberry’s picture

Thanks. This has helped a lot.

klonos’s picture

No problem mate. Just share the knowledge next time someone asks the same thing ;)

ecoment’s picture

#82 worked fine for me on views 2.x.11 and osx, great!

Pieter Maes’s picture

i should not have posted here my excuse,

peace

dawehner’s picture

Version: 6.x-2.x-dev » 6.x-3.x-dev

#97
I would have looked into the issue, but you spammed the issue queue, sorry :)

Pieter Maes’s picture

spammed ? 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

klonos’s picture

[...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 ;)

dawehner’s picture

I'm sorry for what i said. This is a quite unproductive issue, sadly:

* many different problems
* some subscribers
* many confused users

klonos’s picture

I 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 ;)

dawehner’s picture

This would perhaps help people so they don't have to read the full issue.

nickgs’s picture

#6 seems to work for me... but is this going to be included in base any time soon?

klonos’s picture

Hi 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?

miaoulafrite’s picture

+1

akanouras’s picture

Subscribing.

Removing the ampersands from function variables obviously fixed the problem for me too in views-6.x-2.11.

nickgs’s picture

Hi 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

joehudson’s picture

@ #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.

klonos’s picture

@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.

joehudson’s picture

My 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)

appaulmac’s picture

I 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

Maciej Lukianski’s picture

#90 worked for me.

I was getting the errors when using ViewsSlideshow module and changing Basic Settings > Style to "Slideshow"

PHP 5.3

Maciej Lukianski’s picture

I 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.

MustangGB’s picture

Status: Needs review » Reviewed & tested by the community

+1 to #90

dawehner’s picture

Status: Reviewed & tested by the community » Needs work

See http://drupal.org/node/452384#comment-3328628 again

6.x-3.x does currently support php4.

MustangGB’s picture

#90 addressed #85 by not altering the function signature

dawehner’s picture

Status: Needs work » Reviewed & tested by the community

Sorry.

merlinofchaos’s picture

Status: Reviewed & tested by the community » Fixed

sammys' patch committed. Thanks!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

nixter’s picture

"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.

warning: Parameter 3 to views_ui_build_form_state() expected to be a reference, value given in /home/webapps/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 /home/webapps/includes/form.inc on line 378.
warning: Invalid argument supplied for foreach() in /home/webapps/sites/all/modules/views/includes/admin.inc on line 1542.
warning: Attempt to assign property of non-object in /home/webapps/sites/all/modules/views/includes/admin.inc on line 1613.
klonos’s picture

@nixter, #121: you need to use latest dev (look at the 'Development releases' section in the project's download list).

el_reverend’s picture

Subscribing.

silkAdmin’s picture

@ 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.

klonos’s picture

@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.

silkAdmin’s picture

@klonos Thanks for the tip : )

Oh and dis-activating the development module seems to have fixed all problems!!

Amir Simantov’s picture

#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.

MustangGB’s picture

Version: 6.x-3.x-dev » 6.x-2.x-dev
Status: Closed (fixed) » Patch (to be ported)

So what we need is for #90 to be back-ported

dawehner’s picture

Status: Patch (to be ported) » Closed (fixed)

This patch is commited to 6.x-2.x already, but isn't part of the release 6.x-2.12

Amir Simantov’s picture

@dereine #129
But 6.x-2.x is not listed in the version list on the module page, hence obscured.

MustangGB’s picture

He means it's in 6.x-2.x-dev, so either use this or wait for a 6.x-2.13 release

Dave Kopecek’s picture

#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 ?

jfcolomer’s picture

Issue summary: View changes

#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!

MustangGB’s picture

It 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...

Rob T’s picture

#6 worked for me on an old legacy installation. If other issues arise, I may revert and try some of the other proposed fixes.