Dion

I never thought I would log back into this site again, but your review compelled me to do so.

The descriptions of the the meaning of the numbers is in the FAQ, which is where most people would look before posting a review. Most people would also define what they mean by “killed the site” before posting a review. The rest would make a support request for one or both before posting a review. Which means there’s a hidden door #3.

UsageDD is a tiny plugin with only a few lines of code, and it would be almost impossible for it to “kill a site” unless its code was modified. (The only reason I added “almost” is because nothing in life is 100% guaranteed except death.) I also read your other reviews, all of which were similar to this one. So I guess what’s behind hidden door #3 is that you either hacked the UsageDD code, or wrote a review of UsageDD without ever trying it.

If you have issues with UsageDD, please post them in its dedicated support area, and I’d be happy to assist. Otherwise, I see no reason to continue this discussion.

I’m well aware of how the WP internal cache system is set up and how plugins can use APCu/Redis/Memcached/etc and an advanced-cache.php file to implement a persistent cache. Your response is more than a bit condescending given that you have no knowledge of my clients’ sites, some of which require the display of dynamic content to guests.

FWIW…OPCache offers much more “bang for the buck” than a persistent cache since it doesn’t require a plugin to implement, and as long as it wasn’t configured by a moron, it offers dramatic performance improvements and won’t interfere with sites. It should IMO be the strongest server-based recommendation in Site Health.

Anyway, I stand by my comment: this is yet another example of WordPress attempting to dictate server configurations without providing information about the ramifications of its “recommendations”. (The “recommendations” also assume that WordPress is the only PHP-based application on a server, but that’s a different issue and discussion.)

On that note…I’m done here.

Where did you obtain your octintz.com domain name? That’s the place where you should be asking your question about DNS settings.

I noticed this “recommendation” when I was trying out 6.1RC1. Since many of my clients have dynamic pages and using a persistent cache would be disastrous, I had them add the following line to their wp-config.php files before 6.1 was released:

$GLOBALS['wp_filter']['site_status_should_suggest_persistent_object_cache'][999]['dion'] = ['function' => '__return_false', 'accepted_args' => 1];

This is (IMO) another example of Site Health attempting to dictate server configurations without providing any information about the ramifications of its recommendations. In this specific case, nowhere does it mention the very large potential problem of the loss of dynamic content when a persistent cache is used.

I don’t think you understand how namespaces work. I’ll let you do some research to understand why this is true, but the following line will work in all your code as long as the function_name function is defined in the test namespace:

add_action('admin_menu', '\test\function_name');

If you require further assistance, I suggest that you ask your questions where PHP coding is discussed, such as StackExchange. In the meantime, if you are having difficulty using namespaces, perhaps you shouldn’t be using them.

It will be difficult, if not impossible, to perform a database update with such a huge wp_options table. Disabling plugins will probably not resolve this issue, though it should be attempted — using FTP, rename all subdirectories in the wp-content/plugins directory, and that will deactivate all your plugins.

Since your hosting company will not remove data from the table unless you provide the queries (no doubt for liability reasons), it will be up to you to identify the data should be deleted. To do that, you will need access to something called phpMyAdmin, which should be available through your hosting control panel. It will allow you to view the contents of the wp_options table and determine what should be deleted, and hopefully determine which plugin (or plugins) caused this problem.

If you cannot do this yourself, you’ll probably need to hire someone to do it.

This can’t be done from within WordPress.

If you have hosting that includes a control panel such as cPanel, Plesk, or DirectAdmin, you can create email accounts using the control panel.

Otherwise, contact your hosting company.

The error is being caused by a missing $_SERVER superglobal and is occurring before plugins and the theme are loaded. So it’s probably a PHP issue.

Check your php.ini file for PHP 8.0 and make sure it is registering the $_SERVER superglobal.

I’m sure you can remove the directories and databases through your hosting control panel. However, it should be done in a specific order for each installation:

1) obtain the database name and user from the wp-config.php file
2) delete the database, and the DB user if it’s unique to the database
3) delete the subdirectory

If you have any questions about the specifics of these three tasks, you should ask your hosting company. PLEASE BE CAREFUL! Deleting the wrong subdirectory or database/user would be disastrous because they could not be recovered.

What many (and I daresay most) hosts call “WordPress hosting” is little more than a stripped-down version of a regular hosting plan, typically set up on a server that has extensive cache software installed, and either without a control panel or with a minimalist in-house-developed panel. The lack of cPanel/Plesk/DirectAdmin means the profit margins on these “WordPress hosting” plans are higher than with standard hosting, which is why hosting companies heavily promote them.

Oftentimes these “WordPress hosting” plans will have custom plugins and drop-ins installed that cannot be removed. Many will force automatic core/theme/plugin updates…whether you like it or not. And some hosts provide WordPress with core code that has been modified. These things are done to insure everyone is running the same basic WP installation, which reduces the need for support (typically the host’s largest cost).

Having said this, customized WordPress hosting plans exist where the host takes care of everything, including custom theme/plugin installation, and they offer quality support. Plans such as these tend to be expensive…up to 10X the price of a standard hosting plan.

Finally, here’s a tip: if you can hold off for a few weeks, most hosting companies offer “Black Friday” hosting deals that are usually their best prices of the year.

If the code you’re describing is specific to the theme, and you’re not creating a child theme solely for this code, then put the code in the theme’s functions.php. Otherwise, it probably makes more sense to create a plugin.

Using a plugin will add some files to your filesystem, a hundred or so bytes to the database, and potentially some bytes to memory usage. However, if you created a child theme for the sole purpose of adding code to functions.php, then using a plugin will reduce the filesystem, database, and memory usage because the child theme can be deleted.

The biggest difference is that the plugin’s code will be available to all themes, not just the one that previously contained the code.

Plugin code starts executing before theme code, which could be a plus or a minus depending on your code.

If a PHP extension is installed and shows up on the phpinfo() page, then WordPress will know it is available. That’s how PHP scripts work. Site Health will ALWAYS show the same information as running phpinfo() from a web-facing script. Note that running php -r "phpinfo();" or php -i from the command line can display different results than running phpinfo() from a web-facing script.

I’m sure you already know, but for others reading this: if PHP extensions are added/removed, one must restart PHP in order for the new configuration to take effect.

Site Health contains subjective recommendations — no more, no less. If you understand the ramifications, then ignore the ones with which you don’t agree. For example, I have all automatic updates disabled, and Site Health displayed all sorts of “they sky is falling!!!” errors. I also don’t have certain PHP extensions enabled (fileinfo and imagick) that Site Health says I should have have enabled. Well…fileinfo (technically libmagic) is buggy and consumes A LOT of memory, and imagick is a CPU pig under most circumstances. So I’m happy letting WP guess MIME types internally, and since my server has the available memory to make it work well, I’m happy letting GD manage images.

Eventually I decided to write a plugin to completely disable Site Health, because for my (and my clients) purposes, it does more harm than good. (The plugin also blocks WP’s access to “browse happy” and “serve happy” for good measure. ?? )

This is a cPanel issue, so it’s best to contact them:

https://forums.cpanel.net/

If you have shared hosting, your hosting provider must do this on your behalf. It sounds like they don’t want to make the effort to do so, which is unfortunate…perhaps you should consider finding a new hosting provider.

In the meantime, you can edit the wp-config.php file using FTP. (The fact that your hosting provider didn’t mention this is another reason to explore other hosting options.)