CiviCRM 5.66 now calls for PHP 8.1. What's a safe way to do this upgrade? Using cPanel I changed to 8.1 while logged in to a test site, and all was well - I'm sure I've done this the same way before with no problems. However on another site - also a test site fortunately - upgrading to PHP 8.1 while logged in has broken it. So, is there a safe method to do a PHP upgrade? Is it flush caches, logout, backup, do the PHP upgrade, then log back in? Obviously, it's not as simple as I thought...

  • Does this mean by implication that all of the extensions that work with 5.66 are compatible with PHP8.1?
    – Graham
    Commented Oct 10, 2023 at 14:55
  • 2
    In our experience CiviCRM core wont cause serious problems, extensions however can, particularly when upgrading from php 7.x to 8.1. Obviously not all of the hundreds of extensions are compatible and many of them are not (officially) actively maintained by anone. Often code incompatibilities can be fixed rather easily by skilled developers but you could end up with many unsupported extensions that no one feels responsible for or needs funding in order to provide fixes.
    – Fabian
    Commented Oct 19, 2023 at 12:43

3 Answers 3


I'm going to jump in and give you my experience. First, no idea what platform you are using. Usually, I start off by saying: WordPress v6.4.1 CiviCRM v5.67.0 which is what I have right now.

MultiPHP is a bad idea even if you control your own Cloud unless you are in a bare blade like AWS, Google Cloud, Azure or whatever. Any host telling you that you have full control is lying. So, stick with PHP Version from your cPanel > Select PHP Version and set all of your deployments there. Second, most of the issues originate with the Extensions. For example, neither the Volunteer nor Area extensions comply with the revamped Angular Settings (Line 246 in both of those and then builds out crazy from there). Surprising, because Volunteers are the cornerstone of any nonprofit. You will get an "Array and string offset access syntax with curly braces is deprecated" with the 5.67.0 update.

Now, I am not really a coder, but I try to bring issues up. Some other items are that the OAuth, where the world is going on EVERYTHING, is kinda weak in the distro. I had to tweak some things to get it to fire up right. So, if you are running OAuth then that could be an issue and then how both say Google Cloud or whatever is booming that token back and forth.

If you are in WP, remember, go to your config file and change the WP_DEBUG from false to true. That is going to give you your error, generally. Building on that, make sure you go back in and tick it off, when done. Also, if your cron is set right in WP, it generally will spit out an error and email it to you if set to do such. I have a post somewhere in here on it.

Finally, and not to be rude, if you are having changes made to your .htaccess file you have real issues. That should NEVER happen on a WP deployment. Anything, really, changing that should be prevented along with protecting all manner of file folders, etc. I am sure there are plenty of articles on that and I don't know what platforms anyone is using so is what it is.


The angular profiles extension had/has a problem with PHP 8+. If this is enabled then things will not work. Other extensions (I believe CiviVolunteer) may be dependent upon the first extension. My experience is that all the extensions need to be tested. It may be (as in my case) you cannot move to PHP 8 at the moment if you are reliant on a particular extension. There is a blog entry on civicrm.org that records success or otherwise with a list of some extensions, but there are a lot of them.


I ran into another problem upgrading to PHP 8.1, again it gave the site a 500 internal server error and was inaccessible. The cause was the .htaccess file overwritten by MultiPHP, a cPanel untility - which was fixed by restoring the previous .htaccess file. There's more to this problem that I don't understand, frankly, but I think you can put this down to a hosting problem - and little to do with changing from PHP 7.4 to 8.1 - although that did trigger the problem.

  • What was the error, though? A 500 is simply a generic error. And what was your platform --- Drupal, WordPress or ... ? Generally, you would go into the logs and pull the actual error. Commented Nov 13, 2023 at 14:20
  • 1
    Drupal 7 and it was HTTP error 500. The logs didn't help. In fact, I've reverted all my sites to PHP 7.4 as there were a couple of other problems which really made PHP 8 a step too far - the problem with emails arriving as text, & scheduled jobs not working.
    – Andy Clark
    Commented Nov 13, 2023 at 18:56
  • I'm changing installs to PHP 8.1 but one of them gives a persistent HTTP error 500 - very frustrating. I've not been able to work out why..
    – Andy Clark
    Commented Dec 20, 2023 at 8:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.