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.

Comments

subscribe

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.

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

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.

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.

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

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

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

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

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

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

greatly solved diewaldfeee, thanks alot!

greets,
Castell

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];
}
?>

subscribe

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

subscribe.

#6 saved me for now
thanks

subscribe

subscribe

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

subscribing - still seeing the error messages as well.

subscribing

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

#6 works for me !

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.

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.

subscribe.

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

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

Can't this be committed permanently?

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

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

Jan

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

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

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.

subscribe

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

Thanks,

#6 works, THNX!

#6 worked for me too :))

big thanks ;)

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

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

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.

Subscribe

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

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.

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.

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.

subscribe

following.

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

subscribing.

subscribe

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

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

Could you create a new patch?

subscribing

StatusFileSize
new511 bytes

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

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.

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.

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

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

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.

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.

subscribing...

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.

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?

Warnings are less than error. Views still does works.

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

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

I suggest you to read the issue.

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.

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

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.

Status:Needs review» Reviewed & tested by the community

Looks fine for me

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

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

Same issue here man.

Same issue as junoe

Great, #52 worked for me.

Appreciated.

Title:Make Views compatible with PHP 5.3Views 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.

Please don't hijack issues.

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

Title:Views 2 compatibility with PHP 5.3 + Drupal 6.17Make 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.

Version:6.x-2.x-dev» 6.x-2.11
StatusFileSize
new776 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.

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.

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.

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.

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)

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

Yep! #78 == #82 works great!

Title:Make Views compatible with PHP 5.3Make 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.

subscribing

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

Status:Needs review» Needs work

#82 - PERFECT! Thanks :D

Status:Needs work» Needs review
StatusFileSize
new633 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.

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

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

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

Thanks. This has helped a lot.

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

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

i should not have posted here my excuse,

peace

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

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

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

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

* many different problems
* some subscribers
* many confused users

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

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

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

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?

+1

Subscribing.

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

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

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

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

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)

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

#90 worked for me.

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

PHP 5.3

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.

Status:Needs review» Reviewed & tested by the community

+1 to #90

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.

#90 addressed #85 by not altering the function signature

Status:Needs work» Reviewed & tested by the community

Sorry.

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.

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

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

Subscribing.

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

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

@klonos Thanks for the tip : )

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

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

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

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

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

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

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