devot:eeDevoted to ExpressionEngine

With a vanilla ExpressionEngine v2.4.0 installation, I installed the two ProForm (v 1.10) modules and then immediately received two errors in the similar to the following:

Message: Assigning the return value of new by reference is deprecated Filename: PEAR/Config.php

I was able to suppress this error by adding the following line to the proform/config.php file (adding it to the prolib/config.php did not work):

This doesn’t fix the bug, but merely suppresses the error message.

Thanks!

(This is running under a standard XAMPP install on Windows 7)

Hi there,

The filename cited in your error message - “PEAR/Config.php” - is not part of ProForm. What other third party extensions do you have installed? You may also have an unusual include path that is causing this Config.php file to be imported when proform’s own config.php file is instead expected. If that’s the case, ProForm likely will not function correctly.

None, just this one.  Talk to Brian, he’s trying to get a hold of you on this right now ;)
My install is completely vanilla across to board from XAMPP to EE.

By the way, turns out adding that line to the config.php file actually made the layout editor malfunction… by that I mean none of the stuff on the right showed up at all.  Didn’t notice that until after I posted, so disregard my supposed “solution” above.

After talking to Brian a bit, I believe that this issue is very likely caused by some sort of unusual configuration that ships with XAMPP. Since ProForm does not use Pear, and the line number 8,192 reported in the error message (screenshot http://screencast.com/t/b1cqXXNCXtpM) is far higher than the length of any files included with ProForm, I don’t believe this is caused by any issues in the module itself.

The problem you are seeing with the layout editor not working would likely be caused by a broken include of some kind. Make sure that there are no 404s reported when loading the layout editor.

My screencast is famous!  ;)

Well, good to know there are issues with XAMPP - may need to consider some alternatives for my local environment.  I didn’t have firebug open at the time unfortunately and now I can’t replicate the bug.  It was constantly showing me the “Preferences Updated” notification too, but that’s stopped as well.  The only error I see now is the Content Encoding Error problem on the template side.

Gzip was enabled in my EE settings—probably another XAMPP problem rather than something with the module.  Still, I only get these PEAR errors when ProForm is enabled.

Here’s a vid showing the process:
http://screencast.com/t/g8HYgKlwo4

Here’s an second showing it removed and re-installed:
http://screencast.com/t/KzdMygwVR

I looked through my apache and php logs and didn’t see anything relevant.

Hmm, well I would strongly recommend trying a different environment since I am almost certain this is being caused by XAMPP. Personally I prefer to use separately installed Apache, PHP and MySQL installations.

However, if you have xdebug installed with XAMPP, we can do some investigation to see if we can find where this is being thrown.

Open this file and find the show_php_error function:

system/codeigniter/system/core/Exceptions.php

Add this to the top of the function:

The =& convention is deprecated in PHP 5 because all objects are passed by reference.  I found a few of these in the ProForm code, but modifying it didn’t do anything (unless this was used somewhere I missed).  However, hacking the PEAR/Config.php file to change =& to = eliminated the error.

I would guess that XAMPP is shipping with an old version of PEAR.  That said, using =& in code for PHP5 is trying to send a reference by reference…  simply removing the & in all the =& and = & should be just fine.  I’m not sure why I was seeing this warning from the PEAR code, but not from the ProForm code even though it was present in both.

ext.proform.php:
47: $this->EE =& get_instance();

mod.proform.php:
79: $this->cache =& $this->EE->session->cache[‘proform’];

From ProLib (didn’t look through the Krumo files)

sfYamlParser.php:
94: $parser->refs =& $this->refs;
106: $parser->refs =& $this->refs;
148: $parser->refs =& $this->refs;
200: $parser->refs =& $this->refs;

bm_email.php:
55: $this->EE =& get_instance();

pl_email.php:
55: $this->EE =& get_instance();

Again, since ProForm does not use PEAR, this file is not part of ProForm.

The notation you are talking about only applies to returning a reference from the new operator through a constructor - it does not apply to other variable assignments, or assignments that are returned from a normal function or method.

Objects in PHP are not always passed by reference - they are copied by default - although new objects returned from a constructor are always passed by reference and therefore cannot use the & operator. ProForm has never had a single instance of a new/constructor being called with the & operator.

The examples you posted are allowed by PHP - and ProForm will not function correctly without them since the code expects that these objects will be passed by reference. The issue here was simply the incorrect usage of &new; in the PEAR/Config.php file, which is not part of ProForm. This is why you only saw the error in the PEAR code, but not in the ProForm code - the two usages are very different.

For reference, search through the rest of the EE code base and any other third-party add-on for use of the get_instance() function, and you will find many hundreds of usages similar to mine:

You can see this usage in EE 2.4.0’s own user manual here as well as on the CodeIgniter (the framework EE is based on) documentation here (scroll down to “Utilizing CodeIgniter Resources within Your Library”), among other places.

Note: I updated the subject of this thread to reflect the actual issue - XAMPP shipping a version of PHP that is not compatible with it’s own PEAR files (kinda weird, right?)

I fired up the XAMPP shell, ran:
# pear channel-update pear.php.net
then
# pear upgrade PEAR

From this I learned XAMPP 1.7.7 (the version I have) comes with PEAR 1.7.2 (the current version is 1.9.4)...  So, I upgraded PEAR and restarted Apache, and still, when I click on ProForm in the modules list, those errors appear (they don’t seem to appear anywhere else).  I have more than one EE instance (not MSM) on my machine, this is the only one with ProForm install, and it’s the only one showing these errors.

I get that ProForm doesn’t use PEAR directly, but is it possible that it’s calling a hook in EE or CI that does that otherwise isn’t being used?

(Side note for other XAMPP users:  in 1.7.7, the shell is implemented in xampp-control-3-beta.exe rather than the default control panel application)

When I introduce an error in the PEAR config.php file, I get this:
http://screencast.com/t/KavQXP0M

When I click on any other part of the CP on any other site running on this XAMPP server I don’t get an error.  It appears only when I click ProForm in the modules list.

Fixed it.

Changed line 20 in prolib.php to:

I think it was, for some random and crazy reason, confusing the prolib config file with the PEAR config file.

Crazy.

But, after making this change, the parse error I have in the PEAR config file no longer appears and the warnings are gone, and a quick click through the small demo form I created seems to show no errors.

I will update the require_once to be more explicit.

Sorry for the post spam..  but here’s the reason.  In XAMPP’s php.ini file:
include_path = “.;D:\XAMPP\php\PEAR”

I don’t know why it was skipping the config.php file in the current directory, might be some other weird or random XAMPP configuration, or maybe some weird Windows thing (wouldn’t be the only one).  Either way, making the require_once path absolute seems to work around any directory resolution issues.

No problem, post as much as needed. :)

It seems weird that the include path wasn’t working correctly. My expectation is that the one specified there would cause it to check the current directory - “.” first, before PEAR… very strange. Updating the file to be a fixed reference will help prevent any other XAMPP users from running into this. I do appreciate your help tracking the cause of this down. Unfortunately I can’t fully test in every development environment out there - hopefully no one actually uses XAMPP for production… their default settings and versions seem dangerously out of date to me.