tamramc

and I’m wondering if this is related to site security and Site Health. if wp-admin directory secured, your plugin cannot be used? but all other plugins are still accessible and working fine.

What fixed problem — but check your server for correct Apache name containers: <Limit> is 2.2, <Require> is 2.4

// works //
<Files .htaccess>
Require all denied
</Files>

Require ip xxx.xxx.xxx.xxx
Require ip xxx.xxx.xxx.xxx # continue for any other ips/CIDRs or an entire range
Require local # THIS is the most important thing — WordPress PLUGIN needs to not be blocked

ErrorDocument 400 /file
ErrorDocument 401 /file
ErrorDocument 403 /file
ErrorDocument 413 /file
ErrorDocument 404 /file
ErrorDocument 500 /file

/// end works /// AND I LOVE THIS, SO MUCH EASIER, and simple with same security.

This results in 403 error for unauthorized access, as expected. And after this site health actually reported GOOD JOB! with 0 issues found. What existed before (below) resulted consistently in wp_version_check() and loopback failures, including on FRESH install w/ zero 3rd party plugins, just WordPress and server.

<Files .htaccess>
order deny,allow
deny from all
</Files>

<Limit GET POST> # now deprecated, may cause server errors. Require is the new Limit — see link below
order deny,allow
allow from xxx.xxx.xxx.xxx
allow from localhost # THIS didn’t satisfy WordPress, because see link below
# allow from xxx.xxx.xxx.xxx/xx
deny from all
</Limit>

<Limit PUT DELETE>
order allow,deny
deny from all
# allow localhost here could fix the problem on some servers, but find out your server version software and see link below if 2.4 as ours is.
</Limit>

https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html#requireany

So, what WordPress developers need to do, hardcode comment for require localhost or info to allow calls from host to update as needed. Because of so many brute force login hackers, most all wp-admin directories are password protected and include a variety of security options. But w/o “Require local” some functionality will fail: scheduling and other tasks.

• This reply was modified 4 years, 9 months ago by t-p.
• This reply was modified 4 years, 9 months ago by tamramc.
• This reply was modified 4 years, 9 months ago by tamramc. Reason: clarity and formatting

What fixed problem — but check your server for correct Apache name containers: <Limit> is 2.2, <Require> is 2.4

// works //
<Files .htaccess>
Require all denied
</Files>

Require ip xxx.xxx.xxx.xxx
Require ip xxx.xxx.xxx.xxx # if any other ip/CIDR or an entire range
Require local # THIS is the most important thing — WordPress PLUGIN needs to not be blocked

ErrorDocument 400 /file
ErrorDocument 401 /file
ErrorDocument 403 /file
ErrorDocument 413 /file
ErrorDocument 404 /file
ErrorDocument 500 /file

/// end works /// AND I LOVE THIS, SO MUCH EASIER, and simple with same security.

This results in 403 error for unauthorized access. And after this site health actually reported GOOD JOB! with 0 issues found. What existed before (below) resulted consistently in wp_version_check() and loopback failures, including on FRESH install w/ zero 3rd party plugins, just WordPress and server.

<Files .htaccess>
order deny,allow
deny from all
</Files>

<Limit GET POST> # now deprecated, may cause server errors. Require is the new Limit — see link below
order deny,allow
allow from xxx.xxx.xxx.xxx
allow from localhost # THIS didn’t satisfy WordPress, because see link below
# allow from xxx.xxx.xxx.xxx/xx
deny from all
</Limit>

<Limit PUT DELETE>
order allow,deny
deny from all
# allow localhost here could fix the problem on some servers, but find out your server version software and see link below if 2.4 as ours is.
</Limit>

https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html#requireany

So, what WordPress developers need to do, hardcode comment for require localhost or info to allow calls from host to update as needed. Because of so many brute force login hackers, most all wp-admin directories are password protected and include a variety of security options. But w/o “Require local” some functionality will fail: scheduling and other tasks.

• This reply was modified 4 years, 9 months ago by tamramc.

my problem was fixed by changing .htaccess containers and directives. some options which worked before, no longer “compatible” with Site Health. and my public_html and wp-admin .htaccess files were set up a certain way to stop brute force login attackers from accessing directories they were persistently trying to access, or making remote calls to exploit.

by using a new install/test site w/ zero plugins or 3rd party add-ons, able to see right away, the “A plugin has prevented updates by disabling wp_version_check().” error should be reworded to send persons onto the right path — towards their server’s security options first, instead of wasting time looking at plugin after plugin. it was easier to just isolate WordPress by itself to see the problem, then go from there.

this Site Health feature is going to be a problem, because not everyone has the same server setup, and many sites require extremely strict security and data protection.

if “allow localhost” isn’t added for certain directives now, Site Health will fail. if Site Health doesn’t like the valid container <name></name>, Site Health will fail. Password protected directories may also fail, esp. wp-admin directory depending upon how it’s password protected.

anyway, I hope this helps someone.

and be safe guys, esp. given hackers are now running scripts to obtain info 24/7. we’ve had over 200,000 attempts to login in one month alone. blocking IPs has become a joke and limits functionality because companies such as Amazon, Facebook are in same server bed as brute force login attackers.

UNBELIEVABLE! problem solved, it was ONE wrong line in .htaccess file, incorrectly formatted, never updated. FIXED. it was specifically related to <Limit GET HEAD POST> transferred from old installation. Once line removed, all was fine.

having same problem, but WITH zero plugins installed and active — set up a test site just for testing one plugin or environment. went to test site after seeing error on live site, saw same “A plugin has prevented updates by disabling wp_version_check()“, and under “Recommended improvements”, another consistent error is shown:

Your site could not complete a loopback request.

The loopback request returned an unexpected http status code, 403, it was not possible to determine if this will prevent features from working as expected.

however, ZERO plugins installed/active on test site.

this could mean, given none of us have same server environment, yet are experiencing same problem, that it’s an IP or service site that is being blocked remotely, away from your site.

I’ve been reporting brute force login attempts for years on various sites. but in the past 2 months alone, brute force login attempts have ramped up via Digital Ocean, OVH, New Dream Host, GoDaddy, Vultr/Choopa and hetzner. with each brute force login attempt, IPs are getting self-blocked by other networks after suspicious/malicious activity, such as persistent brute force login attacks. this may be affecting usability, if www.remarpro.com is hosting any content on any of those networks.

how I discovered this problem: posts could not be scheduled within a plugin on a live site.

• This reply was modified 4 years, 10 months ago by tamramc.

thanks for the quick reply. will update now.

and also sites existed with WordPress BEFORE the current mysql 5.6 and php 7.0 requirements. sites are approximately 6-7 years old and updated with each update as well as mysql and php updated. but never experienced this type of problem before with update to mysql and php.

and I clicked submit too soon, but all sites have latest version of WordPress 4.8.3 as they’re regularly updated. I’m told that not all sites were using 4.8.3, which would cause the error, so I updated all sites to 4.8.3, but want to make sure there’s a safe way to update php and mysql w/o loss of use again.

and all but one of the templates except one is regularly updated with each WordPress update. so if I have to scrap that template, least of my concern. more concerned with getting latest software.
thanks.