WordPress Crashes after PHP Upgrade
Hi Experts,
I have a few WordPress sites, like www.aces-project.com that are running on Windows Plesk.
The site is running PHP 7.1.33, but as soon as I select PHP 7.2.34 (highest available version under my Plesk), on the frontend of www.aces-project.com I get
How can I resolve this?
I have a few WordPress sites, like www.aces-project.com that are running on Windows Plesk.
The site is running PHP 7.1.33, but as soon as I select PHP 7.2.34 (highest available version under my Plesk), on the frontend of www.aces-project.com I get
How can I resolve this?
gr8gonzo
First thing to do is check your PHP error log. It'll probably tell you right away what the problem is.
It looks like it is working now.
Make sure wordpress themes and all plug-ins are up to date before converting the PHP version. Also, enable failed request tracing in plesk for both 400 and 500 errors. Run the site and immediately go back to failed request tracing in plesk to stop the tracing and view your report.
Because this is Wordpress, it should be using up to date coding unless you have a theme or plug-in that is no longer supported. I find sometimes when switching PHP versions in plesk, there is a PHP in setting that did not get copied over. You can view this in your PHP settings in plesk and also look at your actual php.ini file that is in your PHP folder in windows.
The failed request tracing will show you the exact issue.
Make sure wordpress themes and all plug-ins are up to date before converting the PHP version. Also, enable failed request tracing in plesk for both 400 and 500 errors. Run the site and immediately go back to failed request tracing in plesk to stop the tracing and view your report.
Because this is Wordpress, it should be using up to date coding unless you have a theme or plug-in that is no longer supported. I find sometimes when switching PHP versions in plesk, there is a PHP in setting that did not get copied over. You can view this in your PHP settings in plesk and also look at your actual php.ini file that is in your PHP folder in windows.
The failed request tracing will show you the exact issue.
You'll be checking many logs here.
First, enable WP_DEBUG to capture WordPress diagnostics.
Then refer to your Apache + PHP log files to debug the 500 error.
The only way to debug this is reviewing your log files.
If you get stumped, attach your full Apache log + PHP FPM log, covering one instance of the error.... as text files (not images)... with no redactions...
First, enable WP_DEBUG to capture WordPress diagnostics.
Then refer to your Apache + PHP log files to debug the 500 error.
The only way to debug this is reviewing your log files.
If you get stumped, attach your full Apache log + PHP FPM log, covering one instance of the error.... as text files (not images)... with no redactions...
Aside: http://www.aces-project.com is currently non-responsive.
Doing a quick nmap scan shows the entire machine down... no services responding on any ports...
Doing a quick nmap scan shows the entire machine down... no services responding on any ports...
I just realized from David's link using HTTP that you have both HTTP and HTTPS allowed. Using HTTPS everything works, using HTTP images are not loading and it does choke at first. To fix this, in Plesk, under hosting settings, you can check the box, "Permanent SEO-safe 301 redirect from HTTP to HTTPS" This way if somebody does get to your site using HTTP, it will revert to HTTPS.
You can see from the errors using https the reason is your links are using https and when you use http, you get a cross origin issue.
You can see from the errors using https the reason is your links are using https and when you use http, you get a cross origin issue.
@Scott - Good catch!
Even the following command hangs forever... both from my residence + all other machines I manage online...
This is curious. If Scott sees content (wherever he's located on the Net) + many other places show the entire site offline... this suggests something is very wrong... likely with DNS...
Likely best to first vet/check your DNS to ensure all's well, then start debugging problems with your actual site.
Based on what Scott published above, likely first step will be to disable serving CORS headers or set a CORS policy allowing anyone to do anything. Then once you get your site working, determine if some additional CORS granularity is required.
Specifically... it appears... you've set Access-Control-Allow-Origi
This could also be the source of your 500 error as this creates a situation WordPress simply won't understand.. which may lead to WordPress loosing its mind.
Even the following command hangs forever... both from my residence + all other machines I manage online...
imac> curl -I -L https://www.aces-project.com/This is curious. If Scott sees content (wherever he's located on the Net) + many other places show the entire site offline... this suggests something is very wrong... likely with DNS...
Likely best to first vet/check your DNS to ensure all's well, then start debugging problems with your actual site.
Based on what Scott published above, likely first step will be to disable serving CORS headers or set a CORS policy allowing anyone to do anything. Then once you get your site working, determine if some additional CORS granularity is required.
Specifically... it appears... you've set Access-Control-Allow-Origi
This could also be the source of your 500 error as this creates a situation WordPress simply won't understand.. which may lead to WordPress loosing its mind.
likely first step will be to disable serving CORS headers
You are better off to force https.
Another good point by Scott, as you're going through your site, debugging problems.
Be sure you force upgrade both aces-project.com + www.aces-project.com to HTTPS.
Be sure you force upgrade both aces-project.com + www.aces-project.com to HTTPS.
Your site seems to be back online now.
And...
https://webpagetest.org/result/210218_DiSB_6e9edf476878f43d0a6cf98417439ab3/1/details/#waterfall_view_step1 provides a starting point for fixes.
And...
https://webpagetest.org/result/210218_DiSB_6e9edf476878f43d0a6cf98417439ab3/1/details/#waterfall_view_step1 provides a starting point for fixes.
ASKER
Hi, The unresponsiveness was unrelated temporary outage.
Currently, I switched over to PHP 7.2.34 and I left it on with the error. Where do I enable 200 and 500 error reporting?
Currently, I switched over to PHP 7.2.34 and I left it on with the error. Where do I enable 200 and 500 error reporting?
When you click on Failed Request tracing (your layout may be different)
Next click on the Start Tracing button. You will get a pop up where you can set the error codes you want to trace. Separate them by commas. In my example, I used 400,500. Then check the options you want to trace.
Once you have submitted this, run your page, come back and click the new button that reads, Stop Trace. You will then see a link to click on and review.
Next click on the Start Tracing button. You will get a pop up where you can set the error codes you want to trace. Separate them by commas. In my example, I used 400,500. Then check the options you want to trace.
Once you have submitted this, run your page, come back and click the new button that reads, Stop Trace. You will then see a link to click on and review.
ASKER
OK... This is what I get...?
We are getting closer...
Go to your PHP settings
And enable FastCGI
Go to your PHP settings
And enable FastCGI
ASKER
It is enabled
BTW, what is the latest stable version of PHP, and how do I install?
BTW, what is the latest stable version of PHP, and how do I install?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.