nicknormal

I didn’t name call.

If you’re referring to “circle jerk” I’m not calling *you* the circle jerk I’m describing the process as a circle jerk, which is not “name calling.”

“there is no way for a plugin or WordPress to be aware of what software a host will refuse to install” – OK first I wasn’t talking about “install” I was talking about executing. The software “installed” fine, but it wouldn’t physically run (per PHP incompatibility). And yes it absolutely is possible, it’s called Version Compatibility, and it’s literally there in the sidebar of the plugin page on www.remarpro.com: https://imgur.com/a/gpDtx16 — “Requires” — unfortunately the user doesn’t see this data in the Dashboard Plugins page where one is recommended to, and I quote, “update now.”

If the update won’t work, “why bother with update?”

Thus the circle jerk.

Point taken: I’ll no longer use WordPress backend Plugins page to update plugins prior to checking compatibility first – which defeats the whole purpose of using that backend page for the purpose of updating, and thereby creating a horrible experience for the user, which ultimately drives users away from a service (WordPress) that is unreliable and only creates version-frustration and a complete waste of everyone’s – yours, mine – time. The whole process stinks. I’ll let WordPress know this, too.

Implementing this setting in php.ini has at least made the fatal errors not creep up during theme ‘upgrade’:

max_input_vars = 5000

Hope this helps someone else. I’m still waiting for further resolution before marking this topic resolved.

Thanks for your patience and assistance.

Thanks for the tip. Standing by. I’ll post my findings here when I know more.

Cheers.

Again, another clarify. Right now the theme is active, and the website is live; the theme relies on 7 plugins, 6 are optional, one is required; right now everything is stable, visible, no errors.

There is however a quirk in the theme ‘upgrade’ process that requires
mbstring.func_overload = 0
This is the support request I currently have into the host, to confirm – and if necessary, to set – the setting.
Because when I initiate the theme upgrade, the fatal errors kick in; but they are all over the place, which I can’t pin down. At this point I have to remove the theme folder, rename the plugins, etc. to reset the site to some semblance of operation.

So if there’s any known correlation between
mbstring.func_overload = 0
and fatal errors, I’d love to try and troubleshoot that while waiting for the host to respond. I apparently cannot set that setting from within php.ini, contrary to some docs online.

Cheers.

I have a support request into the host regarding a known issue with the theme; but my fatal errors are not reported by other users of the theme. Host says average response time is 20 hours, so standing by. (btw I’m on Grid, have been for 10 years with no problems like this)

Sorry I didn’t clarify; when I say I’ve tried the cut-and-paste response Mods give to users about memory limits, I also mean I’ve tried other correlating numbers that users have used to resolve their memory limit errors i.e. I’ve tried 38, 64, 128.

To clarify, .htaccess has php_value memory_limit 128M;

/etc/php.ini can have the memory limit set or not, and this usually produce the blank/white screen;

changing wp-config.php seems to have the least (as in no) effect.

The challenge is that /wp-admin/ is inaccessible, blank, or riddled with errors, so I cannot ‘Deactivate’ plugins; I can remove/rename them via FTP but it’s my understanding this maintains their activation inside WordPress, that they’re just gone, not deactivated.
Going that route I can access /wp-admin/ but as soon as I kick the theme back on the fatal errors reappear, and bounce around, from file to file, line to line.

I’m lost.

Luckily this is a website that barely gets 10 hits/day, but no way am I upgrading other domains or clients that have 1-10k/hits day, if I can’t figure this out.

Any help is appreciated.

Host is MediaTemple; they say ask WordPress.

Help.

Thank you for that Topher.

As I used Custom Sidebars to generate the sidebar originally, it appears it was located under wp_options as widget_customsidebarempty or something similar to this; the string data in the table too is quite interesting – I always enjoy sifting around inside phpMyAdmin!

Cheers.

I don’t know, I’m at a loss.

FWIW I’m running v5.3.29 PHP.

I’m having the same issue currently.

Why does Deactivating the plugin make all the Widgets go ‘Inactive’?

The behavior I am seeing is very similar to this thread on wpmudev.org only I don’t have the option of simply upgrading the plugin because I’m already using the most recent version.

Thank you for your time.

Thanks for the tip.

I enabled debugging and it generated some errors.

I resolved the ones I could, by deleting expired (no longer used) plugins.

The remaining errors all reside inside the /wp-includes/functions.php file, which I have not ever edited, and believe that is considered WordPress ‘core’ – so why is WordPress generating errors for itself?

The tint over the Media Library remains.

These are the errors generated by debugging; I have removed my webhost folder directory so the error is more front-and-center:

Notice: get_settings is deprecated since version 2.1! Use get_option() instead. in /wp-includes/functions.php on line 3573

Notice: wp_enqueue_script was called incorrectly. Scripts and styles should not be registered or enqueued until the wp_enqueue_scripts, admin_enqueue_scripts, or login_enqueue_scripts hooks. Please see Debugging in WordPress for more information. (This message was added in version 3.3.) in /wp-includes/functions.php on line 3792

Notice: The called constructor method for WP_Widget is deprecated since version 4.3.0! Use
__construct()
instead. in /wp-includes/functions.php on line 3624

Notice: The called constructor method for WP_Widget is deprecated since version 4.3.0! Use
__construct()
instead. in /wp-includes/functions.php on line 3624

Notice: register_sidebar_widget is deprecated since version 2.8! Use wp_register_sidebar_widget() instead. in /wp-includes/functions.php on line 3573

Notice: register_widget_control is deprecated since version 2.8! Use wp_register_widget_control() instead. in /wp-includes/functions.php on line 3573

Do you recommend a solution for cleaning up errors in /wp-includes/functions.php ?

Thank you for your time.

That didn’t solve it.

Help.

This is a brilliant scheme by WordPress developers to allow me to charge an arm and a leg for clients who want their own specialized “god” or “asdf1234” password. I love it!

I have de/activated each of my plugins one by one, and doing so does not resolve the caption conflict – captions are still being rendered incorrectly, with all the plugins deactivated.

I have also (with plugins deactivated) implemented the functions hook provided by andidas here, and still the captions are not displaying correctly.

I use a completely custom-theme, hand-coded, so any advice on correcting this WordPress 3.4+ implementation is appreciated. Thanks.

Users -> All users -> your profile, click ‘Edit’
Make sure ‘Show Toolbar when viewing site’ is ticked ON.