CiviCRM on PHP 5.4?

[Martin.Schwenke]

Are there any known problems running CiviCRM on PHP 5.4?  I'm looking to upgrade my system that runs CiviCRM 4.1.1 (on Drupal 6) to PHP 5.4, given that Debian testing has made the jump to this version of PHP. 

I notice that http://au2.php.net/manual/en/migration54.incompatible.php says things like:

set_magic_quotes_runtime() raises an E_CORE_ERROR level error.

Some of the files in the packages/ subdirectory potentially call this function (i.e. grep finds reference to it)....and this scares me... although I would guess that I'd be seeing lots of errors in the logs if I were using such deprecated features.

Any advice greatly appreciated...

[Donald Lobo]

4.1.x will definitely not incorporate support for 5.4

will be good for 4.2 to do so. If you can try it out and see what works / what does not that would be great and help us a whole lot. None of us have installed or planning to install 5.4 in the near future

lobo

[Martin.Schwenke]

The good news is that I've tried this out today and have encountered no problems.  I've tried out various functions on generic contacts, contributions, membership, mail, ...  It seems fine.

The only weirdness I see at all is with the Drupal contributed "masquerade" module.  When I come back from masquerading as a less privileged user the CiviCRM admin menu doesn't get refreshed.  I haven't seen this before but then I rarely use CiviCRM when I'm masquerading.  However, given the lack of PHP errors, I can't see this having anything to do with PHP 5.4.

In hindsight, you wouldn't expect any fatal errors unless the web server logs already contained errors about using deprecated features when running on PHP 5.3... if the changes due in 5.4 were well managed.

I might try my luck and upgrade the production site.  I can't see this being anywhere near as bad as what happened to me a year or 2 ago when our server admin asked if I was running anything that wouldn't like an upgrade to PHP 5.3, me not checking the release notes for CiviCRM and then having to run SVN versions until the version that supported PHP 5.3 went into alpha.  It was a bit of work but it wasn't the end of the world.  Compared to that, this looks like a walk in the park...  ;-)

I'll let you know if I have any problems...

[Donald Lobo]

the masquerading stuff is not a php 5.4 issue. It came up on IRC yesterday also

Cool, thanx for pushing this forward. If your experiments continue to go well, we'll consider supporting 5.4 for CiviCRM v4.2

lobo

[Martin.Schwenke]

Oops, I called it too early.  There are a lot of warnings being logged in the Drupal log table.  When I turn on syslog they become much easier to see.  There are so many of these that the logging tables would become ridiculously large in no time...  :-(

Most of the errors are like these:

Code: [Select]

Non-static method CRM_Activity_BAO_Activity::exportableFields() should not be called statically, assuming $this from incompatible context in /home/martins/share/drupal/modules/civicrm-4.1.2-drupal6-hacked/CRM/Contact/BAO/Query.php on line 433.
Non-static method CRM_Activity_DAO_Activity::export() should not be called statically, assuming $this from incompatible context in /home/martins/share/drupal/modules/civicrm-4.1.2-drupal6-hacked/CRM/Activity/BAO/Activity.php on line 1971.

Nearly all of the error I saw were scattered thoughout the CRM subdirectory.  There are a handful in packages/{DB/,HTML/,Log.php} ...

I'll do some digging and see how easy these are to fix...

Incidently, the "hacked" in my directory name for CiviCRM just refers to the fact that I remove packages/{Mail/,Mail.php,PEAR/} and link those to the system-installed versions, otherwise things get ugly.  Just so you know the hacking I've done is minimal...  :-)

[Martin.Schwenke]

OK, this isn't so bad after all.

http://au.php.net/manual/en/migration54.other.php says:

E_ALL now includes E_STRICT level errors in the error_reporting configuration directive.

That seems to be why the warnings are "new".  They've always been there but PHP reports "strict" errors now by default, so we see them.

Doing this in my Apache config shuts it up:

Code: [Select]

php_value error_reporting "E_ALL & ~(E_NOTICE | E_STRICT)
That said, they're all apparently errors that need to be fixed.  Some can be fixed by marking methods as "static" but others look tricker...

[Martin.Schwenke]

We upgraded our server to PHP 5.4 today.  CiviCRM 4.1.2 on Drupal 6 seems to be running just fine.  I haven't tried the full range of functionality (there are many components of CiviCRM that we don't use), but I did various contact and member operations, and did a test-drive contribution.  It seems OK.

I set error_reporting in my Apache virtual host config to stop the E_STRICT errors from being logged:

Code: [Select]

php_value   error_reporting      "E_ALL & ~(E_NOTICE | E_STRICT)"
This worked fine when using CiviCRM interactively in a browser but when I ran cron jobs from cli.php I got pages of
errors in the Drupal log.

My first attempt at working around this was to add the following into civicrm.settings.php:

Code: [Select]

error_reporting(E_ALL & ~(E_NOTICE | E_STRICT));
This didn't work.  In fact, it meant that I started seeing the E_STRICT errors logged due to interactive browser use too!  I may have misread the PHP documentation for error_reporting().

However, adding the following to civicrm.settings.php seems to do the trick for both interactive browser use and CLI:

Code: [Select]

ini_set('error_reporting', 'E_ALL & ~(E_NOTICE | E_STRICT)');
I'll post again if anything actually stops working...   

[JoeMurray]

Heh Lobo,
I notice that the current table releases for PHP are 5.4.3 and 5.3.13. Might be nice to consider experimental support at least for PHP 5.4 in CiviCRM 4.2.

[Donald Lobo]

a few folks have tried it and it seems to work.

however we've not upgraded to it as yet and dont have the time/energy to do so at this stage. I suspect we'll do the switch once 4.2 is out

I know u have a lot of stuff on your plate, but if you want more stuff, feel free to add this project also . A good first  test would be to ensure all the tests run on 5.4.x

lobo

[Donald Lobo]

I did spend a few hours on this last nite and its a bit non-trivial. I suspect its a 10-40 hour project if you want to get the tests to run etc. Seems like some pretty big changes with regard to strict warnings and notices that catch a few of the bigger isues with Civi (definitely worth fixing though)

lobo

[The Next Wave]

So is civi 4.3.3 ready for PHP 5.4?
No one seems to have said anything lately- and cpanel never made it to 5.3.3 for php- stopping at 5.3.26

need to know.

[The Next Wave]

Bump? Anyone- PHP 5.4 with Civi 4.3.3? Does it work?

[The Next Wave]

Bump?
Civi 4.4- with PHP 5.425 ? anyone?

[Donald Lobo]

many of us run civi 4.4.x with php 5.5.x

lobo

[The Next Wave]

Thank You Don!