RadiantFreedom

I’ve contacted my client’s host provider and verified there is a host provided firewall in place that may be blocking cloud features of some plugins. I’ve summitted a support ticket with them to see if this is the case and I’ll see if they can whitelist you to prevent you from being blocked in the future.

Does this plugin run the setup guide via any sort of cloud service originating from your own servers? I’m having similar issues with another plugin, Shareaholic, that also uses the cloud to manage some of the settings and the cloud features are also not working. In Shareaholic’s case, nothing is being displayed.

I can confirm it’s not coming from the browser.

Here’s some video I recorded of the issue for you to see what I’m seeing: I show it on 2 different browsers: https://drive.google.com/file/d/16L6raIurAgx1EzoP1BdUNhlVMZa9rlUp/view?usp=drive_link (if it’s not watchable, give it a bit of time for Google to finish processing the video)

I can post the link now, but at the time I first posted this, the site was still saved as a draft: https://c-choice.ca/

The site’s still under development, but is mostly done now. I have WordFence running, however I’ve had W3 Total Cache running alongside WordFence for nearly 10 years with no issues until now. I can try using a different browser and see if there’s an issue related to the browser.

The other possibility is there’s an issue with the host, which is GoDaddy. I am noticing the plugin images don’t load and appear to be blocked by GoDaddy as far as I can tell as I’ve only ever encountered this issue on that one particular hosting configuration on this one client’s GoDaddy.

Given the timing of how this happened, there’s no other possibility but your plugin.

I created the page 2 weeks ago for a client, last week got the client’s feedback and throughout all that time, all images were working perfectly.

Then yesterday, as part of final edits and optimization of the page, I turn on EWWW, turn on lazy load, and run the image optimization tool, and once that tool had finished optimizing the images, suddenly half of them are not displaying properly, and I can remove the image and re-add it but it still won’t display if id didn’t before. As I’m building this page on Divi, it should be automatically applying the HTTPS protocol and if it was not, I’d be seeing signs of this issue on other client’s sites I’m running on Divi, and this issue would have shown up well before this, not wait until the specific moment when your image optimization algorithm had finished running.

If some images are in fact getting their src values replaced with “http” instead of “https” like it should be, it has to be your plugin making those changes.

When I deleted one of the problem images, permanently from the server and re-uploaded a clean copy, the image worked normally again. So reverting to an image untouched by your plugin fixes the issue. I am noticing the images display normally in the Divi editor, so that would indicate the image files themselves are not being corrupted, but the URLs of the optimized images are apparently being replaced with the wrong protocol, and removing and reinserting the same image does not seem to fix this, so it’s obviously happening behind the scenes, among data I normally don’t have access to within the WordPress Admin panel.

The issue started imidiately upon completing a migration from Bluehost to GoDaddy. As soon as the site’s DNS records were updated to get the site’s normal domain to point to the GoDaddy servers and the records had finished propagating, the issue started.

I am unable to use the built in delete function in WordPress to clear this issue as the error kills all access to the domain, with error pages being shown sitewide, including in the admin section. The only option at that point to regain access to the site is to manually delete the plugin’s files via ftp.

I did find the code the plugin adds to the htaccess file, but was unaware code was also added to the wp-config file as well. What code do I need to look for that comes form your plugin?

As I said before, this issue appears to be caused by a migration and the plugin failing to detect changes in server configuration and trying to use the old SSL Cert that’s no longer valid, with NO MEANS for me to tell the plugin to re-do the SSL configuration.

In older versions, I could just re click all the buttons or select to reconfigure manually, however no such option exists now, so it just stays stuck on the old, invalid configuration and the browser starts outputting error pages, preventing access to the site to even take any farther action to correct things.

I think adding a simple button like “Reconfigure SSL” or “Reset SSL” should suffice to clear up such errors within the WordPress interface, as I would have access to the plugin’s settings page for a short while, long enough to click such a button, and force Really Simple SSL to revert to the beginning and behave like the site has no SSL settings imported. Basically creating clean slate whiteout having to have advanced knowledge on every little line of code the plugin adds, and every possible database entry the plugin creates.

The plugin USED to be able to handle situations like this gracefully back when the user had more manual control over it. I think this is a case of making it TOO automated to the point the user has NO OPTIONS for troubleshooting or resetting things when something goes wrong.

@wfpeter – I have an update. 7 days ago, I manually and permanently blocked a malicious IP, and now I just checked and that PERMANENTLY blocked IP is no longer blocked, and all other IPs I’d PERMANENTLY blocked in the past are also all gone, and NO LONGER listed as blocked.

There appears to be a MAJOR, and potentially FATAL bug in the IP blocking system right now. WordFence either fails to block IPs completely, or fails to list them on the Blocking page, making it IMPOSSIBLE to interact with any blocked IPs in any way, either to escalate a temp block to permanent, or lift a blocked IP that was blocked erroneously.

In your reply above, I think you were missing the main point, which is the issue with the IP Blocking, not that a client lost access to their site due to forgetting a password, which is an issue easily resolved, IF YOUR blocking feature were working correctly, as I could just manually remove the IP Blocking, and instruct them on how to do a password recovery or manually send them a recovery email within WordPress. But when they can’t even access their URL due to an IP Block not working correctly, OR known malicious actors are NOT being blocked when they should be, we have a HUGE problem.

Basically WordFence may not even be fundamentally working as a firewall if there is no consequences for malicious actors violating firewall rules. They’re free to just keep on brute forcing away until they can brute force a solution to break your firewall. you NEED to pay attention to the big picture and roll out an emergency hotfix for this to EVERYONE, and you need to do it NOW.

@robwilc – for scheduled events not firing on time or at all, I’ve found the plugin WP Crontrol helps fix this. They way WordPress Cron works is it only fires if the site receives an HTTP or HTTPS request – so if your site has long periods of no traffic, this can prevent Cron events from triggering. WP Crontrol fixes this by pinging the site when Cron events are scheduled so the scheduled tasks fire off on time.

@duongcuong96 – what exactly does that fix? Sheduled backups not running, or manual backups stalling and failing every time? That’s an issue that came with an update to this plugin back around mid January. So look to whatever you changed around that time and find the bug that broke manually running backups. This issue, for me, occurs across multiple sites I manage, affecting each of them slightly differently, some database backups work normally on, some they don’t, but in all cases, full backups always fail. A fix that fixes manual backups but breaks scheduled backups is no good, as I need those automatic backups to work, as I manage many sites as a pro web developer and don’t have the time to be running from site to site manually running daily backups, 7 days a week even through holidays.

4 Months later and this is still a problem. Do any of you even bother providing any tech support or bug fixes?! 4 months and not even so much as a “we see your concern” is outrageous! Could SOMEBODY PLEASE REPLY! JUST A REPLY for GOD’s sake!

As far as I can tell (dealing with the client’s VA from India so maybe a bit of a language barrier on tech issues like this) is she tried to log in with an incorrect password too many times and eventually hit the failed login attempt limit and got the error page telling her she was being blocked.

The report I got from WordPress via email notification was that she was blocked for too many failed login attempts, verified by the WordFence traffic logs. However, those well within the 24 hour lockout period, her IP address was NOT listed as being banned, but as far as I can tell from the follow up email exchanges with the VA, she’s still getting the error page telling her she’s blocked even though she’s not on the blocked list. I’ll email her again to check if she’s been removed as we’re now well past the 24 hour limit and get back to you.

I don’t have time right now to check the settings for violating other firewall rules, but my standard settings for those are to have the bans last for about 1-6 hours, depending on the client’s specific situation. If a client’s getting an unusually heavy load of suspicius traffic, I may set the time they’re blocked for to longer, and this client did have such issues about a year ago when the Russia Ukraine war was just starting out and several of my clients were getting hit with a flood of hacking attempts coming out of Ukraine.

I may be having similar issues. I created a separate topic, but reading this, we may be experiencing the same bug, so I’ll summarize what I said here as well.

I recently got an email from a client asking for help, they were locked out of their own site. I logged in and checked the WordFence logs, and verified the client had exceeded the maximum number of failed login attempts. These types of bans are set to last 24 hours and the ban occurred about 90 minutes before I saw the email and investigated.

I don’t know if the ban is still in effect or not, but it’s not showing up in the list of banned IPs, and I can’t manually lift or verify the ban still exists. Either the list is failing to report blocked IPs or they’re being quickly scrubbed from the list.

I’m still experiencing this issue. Randomly, a backup file will not download 100% of the file, and this plugin seems to do something to override the browser’s normal behavior of warning me when a download fails. I’m not sure if the issue is the plugin randomly fails to prepare the full .zip file for download, or if you’re doing something else that’s interfering with error reporting on failed downloads, but today, I had a full site backup abort at 10% of the .zip file downloaded, with no error messages from anywhere indicating it had failed to download the full backup file, I only discovered it by looking at the file size on my computer and seeing it was an obviously incorrect file size, (about 10% of the size the full backup file should be.

I posted this OVER A MONTH AGO, are you going to answer this issue at all? Having features broken and not even reporting the errors is a BAD LOOK, and does not encourage anyone to buy the full version when the free version does not work bug free we’re basing our decision on whether or not to buy on.

I have tried it on a 3rd site, a database only backup ran no problem, the scheduled backups, both full site, and database only, ran OK, but when I just attempted to run a manual backup of the full site, the same no response error occurred. This is 3 different sites, on 3 different hosts, I’ve tested this on. Here’s the log for comparison:

WordPress version: 6.1.1
BackWPup version: 4.0.0
PHP version: 8.0.26  (64bit)
MySQL version: 10.3.37-MariaDB-1:10.3.37+maria~ubu2004
cURL version: 7.68.0
cURL SSL version: OpenSSL/1.1.1f
WP-Cron url: https://www.truevikingfinance.ca/wp-cron.php
Server self connect: Response Test O.K.
Document root: /customers/7/5/1/truevikingfinance.ca/httpd.www
Temp folder: /customers/7/5/1/truevikingfinance.ca/httpd.www/wp-content/uploads/backwpup-59792a-temp/
Log folder: /customers/7/5/1/truevikingfinance.ca/httpd.www/wp-content/uploads/backwpup-59792a-logs/
Server: Apache
Operating System: Linux
PHP SAPI: cgi-fcgi
Current PHP user: truevikingfinance.ca
Maximum execution time: 0 seconds
BackWPup maximum script execution time: 30 seconds
Alternative WP Cron: Off
Disabled WP Cron: Off
CHMOD Dir: 493
Server Time: 22:21
Blog Time: 17:21
Blog Timezone: America/Toronto
Blog Time offset: -5 hours
Blog language: en-CA
MySQL Client encoding: utf8mb4
PHP Memory limit: 536870912
WP memory limit: 40M
WP maximum memory limit: 536870912
Memory in use: 36.00 MB
Disabled PHP Functions:: disk_total_space,  diskfreespace,  exec,  system,  popen,  proc_open,  proc_nice,  shell_exec,  passthru,  dl
Loaded PHP Extensions:: Core, PDO, Phar, Reflection, SPL, SimpleXML, Zend OPcache, bcmath, bz2, calendar, cgi-fcgi, ctype, curl, date, dba, dom, exif, fileinfo, filter, gd, gettext, hash, iconv, imagick, imap, intl, json, libxml, mbstring, mysqli, mysqlnd, openssl, pcre, pdo_mysql, pdo_sqlite, readline, session, soap, sodium, sqlite3, standard, sysvshm, tokenizer, xml, xmlreader, xmlwriter, xsl, zip, zlib

I’m getting the same issue on one website I manage, yet it’s working normally on another:

Log from site the plugin’s broken on:

WordPress version: 6.1.1
BackWPup version: 4.0.0
PHP version: 7.4.30  (64bit)
MySQL version: 8.0.28-0ubuntu0.20.04.3
cURL version: 7.58.0
cURL SSL version: OpenSSL/1.1.1
WP-Cron url: https://www.mrtaxes.ca/wp-cron.php
Server self connect: Not expected HTTP response:
Status-Code: 200
Date: Wed, 04 Jan 2023 20:36:03 GMT
Server: Apache
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-control: no-cache, must-revalidate, max-age=0
Set-cookie: wfwaf-authcookie-7d44acb36043ad91efca4f100f534c18=5%7Cadministrator%7Cmanage_options%2Cunfiltered_html
%2Cedit_others_posts%2Cupload_files%2Cpublish_posts%2Cedit_posts%2Cread
%7C18c5c018627431647a0ae8f7d191de5ce0b4b0796c401c175d4f977cd6a20849; expires=Thu, 05-Jan-2023 08:36:04 GMT; Max-Age=43200; path=/; secure; HttpOnly
Vary: IS_SUBREQ,Accept-Encoding,User-Agent
Upgrade: h2
Referrer-policy: no-referrer-when-downgrade
Content-length: 0
Content-type: text/html; charset=UTF-8

Document root: /home/mrtaxes/MrTaxes.ca/http
Temp folder: /home/mrtaxes/MrTaxes.ca/http/wp-content/uploads/backwpup-35918a-temp/
Log folder: /home/mrtaxes/MrTaxes.ca/http/wp-content/uploads/backwpup-35918a-logs/
Server: Apache
Operating System: Linux
PHP SAPI: cgi-fcgi
Current PHP user: mrtaxes
Maximum execution time: 600 seconds
BackWPup maximum script execution time: 30 seconds
Alternative WP Cron: Off
Disabled WP Cron: Off
CHMOD Dir: 493
Server Time: 20:36
Blog Time: 20:36
Blog Timezone: 
Blog Time offset: 0 hours
Blog language: en-US
MySQL Client encoding: utf8
PHP Memory limit: 256M
WP memory limit: 40M
WP maximum memory limit: 256M
Memory in use: 58.00 MB
Loaded PHP Extensions:: Core, PDO, Phar, Reflection, SPL, SimpleXML, Zend OPcache, bcmath, bz2, calendar, cgi-fcgi, ctype, curl, date, dom, exif, fileinfo, filter, ftp, gd, gettext, hash, iconv, imagick, imap, intl, json, libxml, mbstring, mysqli, mysqlnd, openssl, pcntl, pcre, pdo_mysql, pdo_sqlite, posix, pspell, session, soap, sockets, sodium, sqlite3, standard, tokenizer, xml, xmlreader, xmlrpc, xmlwriter, xsl, zip, zlib

Log from site the plugin’s working normally on: (funny thing is this site’s having server problems, so I’d expect this to be the site the plugin would fail on)

WordPress version: 6.1.1
BackWPup version: 4.0.0
PHP version: 8.0.25  (64bit)
MySQL version: 5.7.23-23
cURL version: 7.81.0
cURL SSL version: OpenSSL/1.1.1n
WP-Cron url: https://easycozy.ca/wp-cron.php
Server self connect: Not expected HTTP response:
Status-Code: 200
Date: Wed, 04 Jan 2023 20:40:34 GMT
Server: Apache
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-control: no-cache, must-revalidate, max-age=0
Strict-transport-security: max-age=31536000
Content-security-policy: upgrade-insecure-requests
X-content-type-options: nosniff
X-xss-protection: 1; mode=block
Expect-ct: max-age=7776000, enforce
Referrer-policy: Array
Vary: Accept-Encoding
Upgrade: h2,h2c
Host-header: c2hhcmVkLmJsdWVob3N0LmNvbQ==
X-frame-options: SAMEORIGIN
Content-length: 0
Content-type: text/html; charset=UTF-8

Document root: /home1/fivonex8/public_html/easycozy
Temp folder: /home1/fivonex8/public_html/easycozy/wp-content/uploads/backwpup-e72dd1-temp/
Log folder: /home1/fivonex8/public_html/easycozy/wp-content/uploads/backwpup-e72dd1-logs/
Server: Apache
Operating System: Linux
PHP SAPI: litespeed
Current PHP user: fivonex8
Maximum execution time: 600 seconds
BackWPup maximum script execution time: 30 seconds
Alternative WP Cron: Off
Disabled WP Cron: Off
CHMOD Dir: 493
Server Time: 20:40
Blog Time: 12:40
Blog Timezone: 
Blog Time offset: -8 hours
Blog language: en-US
MySQL Client encoding: utf8
PHP Memory limit: 512M
WP memory limit: 40M
WP maximum memory limit: 512M
Memory in use: 190.00 MB
Loaded PHP Extensions:: Core, PDO, PDO_ODBC, Phar, Reflection, SPL, SimpleXML, SourceGuardian, Zend OPcache, bcmath, bz2, calendar, ctype, curl, date, dom, exif, fileinfo, filter, ftp, gd, gettext, gmp, hash, iconv, imagick, imap, intl, json, libxml, litespeed, mbstring, mysqli, mysqlnd, odbc, openssl, pcntl, pcre, pdo_mysql, pdo_pgsql, pdo_sqlite, pgsql, posix, pspell, readline, session, soap, sockets, sodium, sqlite3, standard, tidy, tokenizer, xml, xmlreader, xmlwriter, xsl, zip, zlib

I haven’t used WP multi site except briefly back in 2015, but the wording did make me wonder. If that’s the error that’s triggering, it has to be a bug, because that’s most definitely NOT a milti-site setup, it’s just a basic WordPress install.

But that part sounds like something I’ll have to take up as a support issue with the wordpress core devs to figure out what’s going on with that site.

Thanks for your quick response, though, that is a mark in your favor.