I was previously hosted on the Deluxe Legacy Linux hosting plan which only supports PHP 5.x. This presented multiple problems, including performance (and potential security) issues. I went ahead and purchased the Deluxe cPanel hosting plan and started migrating my multiple hosted domains. Got all the domains configured. The biggest issue I am unable to fix is with WordPress, and I am at a loss after 3 days of troubleshooting. Here is what I have found:
1. Changed PHP to 7.2 on the cPanel plan
2. Restored MySQL DB from the Legacy plan to cPanel
3. Edited the wp-config.php file to point the DB host from DBNAME.db.##.hostedresource.com to localhost
4. Went to the WP site and get "The site is experiencing technical difficulties."
Looked at various WordPress.org forums and other sites, pointing to a multitude of potential issues, including file/folder permissions, Theme and Plugin problems.
5. Renamed the Theme and Plugin folders to isolate if any of them are at fault. Still get the same error. I don't know how to switch the Theme from Avada to the default WP Twenty-whatever theme.
6. Dropped all the tables in the database, and I can go to site.com/wp/wp-admin/install.php to re-install WP. However, this also means that I have to start all over with installing plugins, themes, and configuration settings.
7. Tried exporting the data from the Legacy install and importing into the newly-installed WP instance. It imported the data, but not the configurations.
8. Tried changing the PHP version to 5.6 on the cPanel plan to no avail
Is there anything else I could try to help me get the WP sites back up and running without having to start all over with configuration? My Legacy plan ends 9/22, and so I only have 1 more full day to troubleshoot this before my old files/configs will be wiped by GoDaddy.
Solved! Go to Solution.
Without having too much knowledge of your configurations, it sounds like they may be the issue. Your site was running on a deprecated version of PHP for a long time. It may simply not be compatible with PHP 7+. It's rare, but it does happen.
It might be time to spruce up those websites and bring them more in line with today's standards?
Once your issue is resolved,
please be sure to come back and click accept for the solution
Thanks for your reply. I thought so initially too but all the plug-ins and Avada theme are rated as php 7 compatible.
Today, I will remove all .htaccess files and see what happens. Will also check the error_logs files in more detail that I saw GoDaddy places in nearly every folder I tried to access.
This is the error that pops up in the log when WP debugging is enabled. (xxx/yyyy is masked for privacy)
PHP Fatal error: Uncaught Error: Class 'Fusion_Widget_Tweets' not found in /home/xxx/yyyy/wp/wp-includes/class-wp-widget-factory.php:100 Stack trace: #0 /home/xxx/yyyy/wp/wp-includes/widgets.php(115): WP_Widget_Factory->register('Fusion_Widget_T...') #1 /home/xxx/yyyy/wp/wp-content/themes/Avada/includes/class-avada-init.php(413): register_widget('Fusion_Widget_T...') #2 /home/xxx/yyyy/wp/wp-includes/class-wp-hook.php(286): Avada_Init->widget_init('') #3 /home/xxx/yyyy/wp/wp-includes/class-wp-hook.php(310): WP_Hook->apply_filters(NULL, Array) #4 /home/xxx/yyyy/wp/wp-includes/plugin.php(465): WP_Hook->do_action(Array) #5 /home/xxx/yyyy/wp/wp-includes/widgets.php(1715): do_action('widgets_init') #6 /home/xxx/yyyy/wp/wp-includes/class-wp-hook.php(286): wp_widgets_init('') #7 /home/xxx/yyyy/wp/wp-includes/class-wp-hook.php(310): WP_Hook->apply_filters(NULL, Array) #8 /home/xxx/yyyy/wp/wp-includes/plugin.php(465): WP_Hook->do_action(Array) #9 /home/xxx/y in /home/xxx/yyyy/wp/wp-includes/class-wp-widget-factory.php on line 100
I fixed the issue and it couldn't be simpler. It was a "DUH" moment. The solution is to treat the move as if you're moving to a new hosting provider.
0. Back up your files and MySQL databases.
1. Restore the files to the target host.
2. Install a fresh, new copy of WordPress (in my case, WP had errors popping up for 3 of the 5 sites) and the Theme you were using (4 out of 5 sites were not working).
3. Then use phpMyAdmin to drop the wp_options table
4. Restore the MySQL database. This will create a new wp_options table with the info from the source
5. Rename wp-content/plugins folder to wp-content/pluginsOLD
6. Install new copies of the plugins you want to keep, and activate the ones you want
This is oversimplifying all the things I had to do for each of the 5 sites, each having their own challenges/issues that needed troubleshooting. However, those steps were generally what worked for 4 out of the 5 sites.
Hope this helps whoever is running into something similar!
FYI: Tables that are created after WP is freshly configured:
@MSY_ , Thanks for coming back and share how you solved the issue! I'm sure other people who may be experiencing something similar will appreciate your words of wisdom.
I wanted to add another solution to a long-time problem I have had (and the reason for why I went from the Classic hosting plan to the new CPanel one) -- my site kept crashing very often and seemed slow to load. Some solutions said to go from PHP 5.x to PHP 7.x, but that did not resolve the issue for me either.
After a lot of troubleshooting, I finally found that the I/O and CPU utilization maxed out from time to time after posting a new article or going to the WordPress Dashboard. The CPanel showing that utilization helped put me on the right path. With the Classic hosting, I had no idea why the site kept crashing often.
Next, I also learned that if the I/O and CPU utilization goes through the roof, there is no way to see what processes are taking up the resources because CPanel does not provide a built-in tool to show that. Previously, GoDaddy apparently had a custom tool written that gave that functionality, but it did not work 100% reliably (and hence their decision to remove it entirely.) If a resource spike like this occurs, the solution is to switch PHP version from one to another.
Finally, I found the culprit for the utilization hog and crashes -- WordPress JetPack plugin. I had read elsewhere a while ago that this was a resource-hungry plugin and that disabling AND removing it helped. However, that did not fix the crashes for me at the time. Oddly, however, after I decided to disable it about a week ago, my site no longer has crashed. I went ahead and disabled it from ALL other sites on the same hosting plan and plan on removing it entirely in a few weeks. The only feature I used with that plugin was to stop spam anyway, but Akismet might be sufficient.
Hope this helps others.