normadize

I unchecked all the checkboxes for singular caps from all the roles and all the Notices are still there.

The URE plugin is the only piece of code in my setup that trigger these notices; the call stack I attached a few posts above shows that. It might not be at fault per-se; I’m still confused regarding the singular caps. See my question above.

Not sure whether you got a bit defensive regarding singular caps, but I created the caps using the available WordPress documentation:

http://codex.wordpress.org/Function_Reference/register_post_type

( see “capabilities” section, around mid-page )

which, as you can see, clearly shows singular caps of the kind “edit_post”, “read_post” etc. My setup has been working fine without any problems for months, except the notices triggered by your plugin.

Are you saying that the above documentation from WordPress is wrong and that singular caps are now deprecated? (wouldn’t be the first time that the WP docs are wrong or out of date, I actually think they are the worst docs I’ve ever encountered as a dev)

I confirm that the notices are there even without Xdebug. I just checked on a different server that does not have Xdebug installed.

Xdebug is nice as it shows the full call stack for the notice. Vanilla PHP only shows the final notice.

Here are all the notices with full call stacks straight from the URE capabilities page (copy/pasted the html code):
https://dl.dropboxusercontent.com/u/884148/xdebug.html

And the same ones for the other server without Xdebug:
https://dl.dropboxusercontent.com/u/884148/vanilla.html

Just open those html files in a browser (they lack a doctype and head but Firefox and Chrome display them just fine).

3.5.2 had only security updates and “updating” qTranslate for 3.5.2 meant just changing define('QT_SUPPORTED_WP_VERSION', '3.5.1'); to define('QT_SUPPORTED_WP_VERSION', '3.5.2'); in qtranslate.php … the plugin would have worked in 3.5.2 without this update, obviously.

I had no time even for my own web dev hobbies lately. I should make time to release my qtranslate improvements given that I said I would, my apologies for the non-honored hope. I should hope that’ll happen this month.

I need at least someone else to test it though before posting/releasing (it’s now too integrated with my plugin) so whoever is interested please email me at [ redacted ].

Cheers.

foreach loops with references (to modify directly the contents of arrays/objects) is definitely supported and has been supported for the longest time: http://php.net/manual/en/control-structures.foreach.php

The following tests were done on PHP 5.3.23, but should work just the same for lower versions.

$a = array ('foo', 'bar');
foreach ($a as &$value)
    $value .= ' here!';

Outputs, as expected:

Array
(
    [0] => foo here!
    [1] => bar here!
)

Same with objects:

class A {
    public $foo = 'foo';
    public $bar = 'bar';
}
$a = new A;
foreach ($a as &$prop)
    $prop .= ' here!';
print_r($a);

Outputs, as expected:

A Object
(
    [foo] => foo here!
    [bar] => bar here!
)

It seems there’s something fishy on your end.

I’ll try to find time to do this but I’m pretty heavily swamped with work at the moment.

Well, you can always hack the plugin code to fix it, e.g. suppress the error by using @, but I reported it so that the plugin author fixes it for everyone.

I this case, you can replace $url_block->header->args with @$url_block->header->args on line 115 in /W3/PageSpeed.php, and do the same trick for all other such errors.