Unable to update to PHP greater than 7.4?

Although recent versions of WP are compatible with PHP 8, however no guarantee of compatibility for every and all plugins and themes since that is the responsibility of the plugin/theme developer. For example, the first Warning is from the wp-complete-backup plugin.

Try:
– manually resetting your plugins (no Dashboard access required). If that resolves the issue, reactivate each one individually until you find the cause.

– If that does not resolve the issue, access your server via SFTP or FTP, or a file manager in your hosting account’s control panel, navigate to /wp-content/themes/ and rename the directory of your currently active theme. This will force the default theme to activate and hopefully rule-out a theme-specific issue (theme functions can interfere like plugins).

PHP COMPATIBILITY AND WordPress: https://make.www.ads-software.com/core/handbook/references/php-compatibility-and-wordpress-versions/

The specific fatal error is due to a faulty widget declaration within your Element theme. Even if you have the most recent version, this does not guarantee it is compatible with 8.x. It’s possible this is the one and only issue and if corrected everything will be fine. Or correcting it will expose other issues ??

I recommend seeking assistance through your theme’s dedicated support channel. In the interim, switch to a default twenty* theme and see if any other issues are raised because of one of your other plugins.

If you’re facing issues updating your PHP version beyond 7.4, it could be due to compatibility or server limitations, installation issues, or permission problems. Diagnosing the issue and seeking assistance from the community or hosting provider can help resolve the problem.

Thanks so much to both of you for these excellent suggestions.

I will try to find the theme’s dedicated support channel if I continue to maintain this site. I assume twenty* means that either 22 or 23 are appropriate default channels, which I had set while deleting all priors.

There were lots of issues with WordPress Complete, which I deactivated since I already had a backup on Updraft Vault.

Meanwhile, I seem to have lost the site entirely by attempting to temporarily shut down Jetpack to troubleshoot this issue.

I don’t even know where or how to begin to recover it.

Totally bummed out today.

Any theme that is included with the default WP installation is suitable. If your preferred theme is a block/FSE theme, then 2022 or 2023 themes are good choices. If yours is a “classic” theme, then I suggest 2021 theme for debugging.

If you have one of those default themes active and your site is still non-functional, via FTP or your hosting file manager, rename the /plugins/ directory (under /wp-content/, similar to what t-p suggested). When WP cannot find its usual plugins directory, it’ll deactivate all themes that were active. You should then be able to log into the admin area and front end requests will return content, although perhaps not appearing as you might prefer.

Once you’ve verified that you can log in, restore the proper /plugins/ name.

Totally bummed out today.

Understandable. I’m sorry this is happening to you. Remember that your site’s content is still in place in the database, it’s just that WP cannot properly access it. Once it’s working again, your content will again be accessible.

Thank you, bcworkz (are you in BC? I’m on VI).

I will use 2021 for debugging, if I ever dare to use HealthCheck again for troubleshooting (I realize you love it).

My site came back up today WHILE I was speaking with my host, concomitant with a message from WP.org that I had been updated to 6.2 (although I thought I had already seen that at the bottom of my screen prior to the crash). This seems mighty coincidental, and I notice lots of other new HELP messages surrounding this update.

I still seem only able to access anything beyond PHP 7.3, which means I will incur extra support charges at IONOS, which wants me to use 8.0 or higher.

Is this likely to be a permanent issue (WP 6.2 not compatible with PHP 8.0), or is it something that I should just wait for and hope that I do not need the extra support? Can you possibly recommend a host that will support PHP 7.4 without additional charges? This site is a labor of love, NOT profit.

I think staying with 7.4 would be ill advised. It reached end of life late last year and is no longer supported. Security flaws could be discovered and remain unpatched. Core WP 6.2 should run with PHP 8.0+ without any problems. Any problems remaining in core would be extremely rare. I strongly suspect the issues you’ve encountered with 8.0 are due to your usual theme or one of your plugins.

Your site coming back is likely due to the 6.2 upgrade, any other happenings at that time are likely coincidental. What I suggest is to configure your 6.2 installation to use 2021 theme and no plugins. Upgrade to PHP 8.0 if it has not already been done. In wp-config.php, define WP_DEBUG as true so you will immediately be advised of any code issues. Do a few common tasks in WP like publish a test post. If everything seems normal without warnings or errors (it should), try switching to your preferred theme if it’s not 2021 to start with. Test again. If all seems well, activate your one most important plugin. Test again. Continue with your other plugins, one at a time and testing afterwards. At any time you encounter trouble, remove the problem module by either deactivating or renaming its folder via FTP.

There are indeed many people having trouble with the 6.2 update because their theme or plugin wasn’t as well coded as it should have been. For themes and plugins that are actively supported, they are usually patched in short order. In the interim you’d need to do without that module until the issue is resolved.

My ‘BC’ refers to a local geographic feature in the Rocky Mountains. I’m not Canadian. However, I did live in Seattle for several years and visited VI a number of times. Such a beautiful island!

Thanks again, @bcworkz, very helpful.

I am not with 7.4 (actually, it seems to be 7.3) by choice. In fact, I want to be at 8.1 or higher, as my host is charging “support” to maintain these older versions. However, when they changed it to 8.1 for me, this caused the first crash. Should I ask them to change it back to 8.1 now that the update has completed? Or can I change it myself? When I look at my dashboard, it only seems to give me choices up to 7.3. But this may be resulting from compatibility with existing plug-ins. I’m slightly reluctant to start deactivating plugins because doing that was at least temporally related to the crash, even though as you surmised it might be coincidental.

You suggested that I should “In wp-config.php, define WP_DEBUG as?true?so you will immediately be advised of any code issues.” Could you please advise me as to how to access wp-config.php?

Basically, I think I am in way over my head here. And I need a more supportive host than IONOS!

Thanks again for being so patient with a pretty clueless user.

To edit wp-config.php, what can usually be done with most hosts is to access your account’s file manager through the account’s control panel. (FYI, the alternative is to use a FTP client, but I think file manager would be easier for you) I cannot be certain these instruction will be valid for your particular host. In file manager, find where WP is installed. It’s often in /public_html/ but this can vary. The correct installation folder will have at least /wp-includes/, /wp-content/, and /wp-admin/ sub-folders. Here you will find the wp-config.php file. You should be able to open it for editing in file manager. If not, download to your local computer and edit it with a plain text editor (never a word processor like MS Word). There will be an existing definition line for WP_DEBUG. Edit it to be:
define( 'WP_DEBUG', true );
For good measure, also insert this line immediately below:
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );

Important: When you’re done fussing with this and wish to let your site be, change the two true values to false. Being able to see any error messages could give hackers a slight edge that you don’t want them to have.

Save your changes. If necessary, upload your local version back to file manager.

You cannot change PHP versions from the WP dashboard, it merely tells you which is currently running.

With most hosts, you can alter PHP versions yourself through your account’s control panel. It’s rather variable exactly where this can be done. Poke around in control panel for anything that seems related to PHP. If you cannot find anything, ask your host to upgrade to 8.1. When changing PHP versions, it’s best for WP to be in its default state — no plugins and 2021 or similar theme active. Whatever content you’ve added is OK. If you make the change yourself, it may take a short while for the change to take place. If the change has been completed, when you reload the page where you can select versions it should show 8.1 as the current version.

WP should be fine with 8.1 in this state. You can then begin activating your plugins as discussed previously.

Thanks again, @bcworkz for these clear and complete suggestions.

I have attempted to follow them to the letter (albeit in reverse order because I didn’t know where to find that wp-config.php file initially) and have again created a disaster.

First, I deactivated all plug-ins using bulk action.

Next, I activated 2021. It looked like my themes were thereby de-activated. The site looked pretty OK, albeit with obvious changed theme. I was still able to access my dashboard.

Next, I figured out how to update to PHP 8.1 on IONOS. I think the site still worked, but with altered theme. I was able to get into my dashboard, and then restored the theme. This must have been a fatal mistake.

First I got something about a critical error and to check my admin email inbox for instructions. I couldn’t locate such an inbox on my dashboard. (should there be one?) I was still able to access the dashboard.

When I attempted to re-revert the theme , I got another error message, which may have been this one:

 

Fatal error: Uncaught ArgumentCountError: Too few arguments to function

WP_Widget::__construct(), O passed in /homepages/14/d230231817/htdocs/blogOLD/wp-includes/class-wp-widget-factory.php on line 62 and at least 2 expected in /homepages/14/d230231817/htdocs/blogOLD/wp-includes/class-wp-widget.php:163Stack trace: #0 /homepages/14/d230231817/htdocs/blogOLD/wp-includes/class-wp-widget-factory.php(62): WP_Widget->_ construct() #1

/homepages/14/d230231817/htdocs/blogOLD/wp-includes/widgets.php(115):

WP Widget _Factory->register('adsWidget') #2 /homepages/14/d230231817/htdocs/blogOLD/wp-

content/themes/element/lib/custom_widgets.php(275): register_widget('adsWidget') #3 /homepages/14/230231817/htdocs/blogOLD/wp-includes/class-wp-hook.php(308): adsWidgetInit(") #4 /homepages/14/d230231817/htdocs/bloqOLD/w-includes/class-wo-hook.php(332): WP_Hook->apply_filters(NULL, Array) #5

/homepages/14/d230231817/htdocs/blogOLD/w-includes/plugin.php(517):WP_Hook-

>do_action(Array) #6 /homepages/14/d230231817/htdocs/blogOLD/wp-includes/widgets.php (1854): do_action('widgets_init') #7

/homepages/14/d230231817/htdocs/bloqOLD/w-includes/class-w-hook.oho(308):

wp_widgets_init("') #8 /homepages/14/d230231817/htdocs/blogOLD/wp-includes/class-wp-hook.php (332): WP Hook->apply_filters (NULL, Array) #9

/homepages/14/d230231817/htdocs/blogOLD/wp-includes/plugin.php(517):WP_Hook-

?do_action(Array) #10 /homepages/14/d230231817/htdocs/blogOLD/wo-settings.php(623): do _action('init') #11 /homepages/14/d230231817/htdocs/blogOLD/w-config.ohp(90): require once('/homepages/14/d.') #12 /homepages/14/230231817/htdocs/bloqOLD/w-load.php(50): require once('/homepages/14/d..') #13

/homepages/14/230231817/htdocs/blogOLD/wp-admin/admin.php(34):

require once('/homepages/14/d.') #14 /homepages/14/d230231817/htdocs/blogOLD/w-admin/themes.php(10): require once('/homepages/14/d..') #15 {main? thrown in homepages/14/d230231817/htdocs/blogOLD/w-includes/class-wp-widget.phponline

163

So I expect this means some widget/ the theme is the problem. However, now when I try to access the dashboard to do anything at all, I’m getting more error messages and am denied access.

I downdated to 8.0 at my host. Same result.

I downdated back to 7.4. Same result.

I THEN tried your first suggestion (maybe this was the problem, should have done this first but didn’t know where to begin) and started getting a series of parse errors.

Is there a way to undo what I have done and do it in your original order? It was rather daunting to try programming myself, but I THINK I did it correctly, changing just the one word in line 81 from true to false without changing spacing or anything and adding a new 82 (I did justify it with 81). That didn’t help, so I removed the new 82. The resulting parse errors were pretty simple, except for the last one which was talking about an ‘unexpected token “(“, expecting “:” on line 86’ however, there were several “(” s on line 86 which looks like this (beginning with line 85:)

/** Absolute path to the WordPress directory. */
if ( ! defined( ‘ABSPATH’ ) )
define(‘ABSPATH’, dirname(FILE) . ‘/’);

I tried sequentially replacing each of the (s with : and nothing helped.

So now, I am again stuck and unable to access my dashboard to do anything at all.

IONOS does provide a sample wp-config.php file which looks a little different from mine starting with the equivalent to line 81: (actually it is line 86 so something must be different before this.)

define( ‘WP_DEBUG’, false );

/* Add any custom values between this line and the “stop editing” line. */

/* That’s all, stop editing! Happy publishing. */

/** Absolute path to the WordPress directory. */
if ( ! defined( ‘ABSPATH’ ) ) {
define( ‘ABSPATH’, DIR . ‘/’ ); }

/** Sets up WordPress vars and included files. */
require_once ABSPATH . ‘wp-settings.php’;

But even cutting and pasting the equivalent of line 86 from the sample to MY wp-config.php did not resolve the issue. I’ve waited several hours and it is not correcting.

I’m afraid to do anything else considering my track record.

I do not see any way to just revert the entire wp-config.php file back as it was when the site was functioning (albeit with PHP 7.4) earlier today.

Do I need to throw myself to the mercy of IONOS?

I apologize for the length of this. It is amazing if you have made it all the way to the end in an attempt to help me. Thank you so incredibly much for your patience and willingness to try.

I am going to mark this resolved, even though it actually isn’t. After going “down the rabbit hole” two days in a row and being closed out of my site, receiving a string of bizarre error messages I cannot begin to address, and being admonished by my host I shouldn’t have messed with anything, I am concluding that php 7.4 is the best I can do and that I need to change to another host or get developer who can either deal with 7.4, or can successfully update me to the current version and sort out any resultant issues. Thanks for all of your help. If I could delete this entire thread I would, but perhaps it might serve as a precautionary tale to others.

Thanks for trying to help!

I’m sorry you had to suffer through so much trouble. Your main trouble is your preferred theme has not been updated to be 8.0 compatible. You would need to use an alternative theme until it could be updated. If it is out of support, you’d need to find a new theme that is 8.0 compatible.

If you cannot log into your site to deactivate your theme, what you can do is change its folder name via file manager. When WP can no longer find it at its expected folder, it’ll use something else, the latest twenty* theme if it’s available. With troublesome code out of the picture, everything should work again.

I realize you’re done with this mess and I could be wasting my time providing more information. I’m going to do so anyway. You’re OK staying with 7.4 for now, but you cannot cling to it forever. It’s fine to take a good long break and forget all the pain it has caused. If you want to keep your site up and running, sooner or later you’ll be faced with the same issues.

As for parse errors in wp-config.php, you likely made a simple typo somewhere while attempting to edit it. It may not be due to lack of knowledge, but just an innocent, accidental blunder. I’ve done it myself at times, accidentally introducing a character or deleting one without noticing. The trouble with PHP error messages is they tell you where PHP realized there’s a problem. The root cause could lie somewhere above that point. If you’re not familiar with PHP syntax, spotting a typo can be difficult if not impossible.

Ideally, what to do then is revert to a known good back up. No backup? That one is partly on me for not mentioning it. I do apologize and feel badly for the trouble it caused. At this point would be the time to ask for help and not try to fix things without truly knowing what you’re doing.

If no help is forthcoming in a timely manner, at least with wp-config.php issues, you could compare your version with wp-config-sample.php, character by character. Of course the DB name, user, and password would be different, as would the salts, but only the parts within quotes with phrases like “your blank here”. You would have to assume what you have in quotes is already correct since incorrect values in quotes would not cause PHP parse errors. WP may not be able to connect to the DB with the wrong password, but there’d be no parse error because of it.