CiviCRM Community Forums (archive)

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

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

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:

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

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:

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:

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:

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

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

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.

Bump?
Civi 4.4- with PHP 5.425 ? anyone?

Thank You Don!