bjf2000
Forum Replies Created
-
Forum: Fixing WordPress
In reply to: Old WordPress core file not removed during updateWe received that email as well.
I don’t understand any kind of reinstall in this case, since we’re talking about two surplus files (not a false positive: they really are left behind).
I then looked in wordpress-5.3.2.zip: the two files are indeed not included. So what is there to install?
OK, that explains it. I would never have connected the two.
The reason this used to work but no longer does, is because in late August, when we finally upgraded from the latest WP 4.9x to WP 5.x, our host switched our installation over to being managed by “Softaculous,” which is a “commercial script library that automates the installation of commercial and open source web applications to a website.”
And if I go into that, look what I see:
Before Softaculous we (via other means) were always configured to automatically upgrade only minor WP versions automatically. That’s why Wordfence always used to update but then stopped once Softaculous took over.
And I was kind of wondering why we were still on WP 5.2.4 and not 5.3, but in the back of my mind I was thinking that may be considered a major version jump (as opposed to a hypothetical 5.2.5, which would be minor). Clearly not.
I’ll have to remember this when WF 8.0 comes out, because that will not auto-update when set on “Upgrade to minor versions only.”
Thanks
Thanks
That’s what I have at that link (in zipped form).
On the theme, it’s possible, though it’s hard to understand how it would relate. I put it here if you want to take a look at it:
https://www.upload.ee/files/10810126/functions.zip.htmlThere’s nothing in wp-config.php (which hasn’t changed in several months) about updates that I can see:
RewriteCond %{HTTP_USER_AGENT} (BUbiNG) [NC] RewriteRule .* - [R=403,L] # Remove any previously set header from the 'onsuccess' table. Header unset Strict-Transport-Security # Set the header in the 'always' table for HTTPS requests, replacing any previous header. Header always set Strict-Transport-Security "max-age=31536000" env=HTTPS # For HTTP requests, the header should not be sent. Header always unset Strict-Transport-Security env=!HTTPS # BEGIN litespeed noabort RewriteEngine On RewriteRule .* - [E=noabort:1] # END litespeed noabort # BEGIN WordPress <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule> # END WordPress deny from 159.8.14.107 # Wordfence WAF <IfModule LiteSpeed> php_value auto_prepend_file '/home/oursite/public_html/wordfence-waf.php' </IfModule> <IfModule lsapi_module> php_value auto_prepend_file '/home/oursite/public_html/wordfence-waf.php' </IfModule> <Files ".user.ini"> <IfModule mod_authz_core.c> Require all denied </IfModule> <IfModule !mod_authz_core.c> Order deny,allow Deny from all </IfModule> </Files> # END Wordfence WAFThanks
So, pending anything further, I’ll do a manual update and revisit this next time, depending on what happens.
I checked cron, and there’s a lot there. What should that job be called? I see these mentioning Wordfence:
wordfence_ls_ntp_cron
wordfence_daily_cron
wordfence_hourly_cron
wordfence_start_scheduled_scan
wordfence_email_activity_reportOn wfConfig, to make sure “autoUpdate” is DISabled (don’t we still want it ENabled)? This is what we have for all mentions of “update,” but I’m not sure what state it’s in (1=On?). Maybe you can tell:
Thanks
I can check into that, but are you sure at least the “foreach” one doesn’t directly relate to what’s described in the article? Based on what I found, that would seem to be a common problem that is corrected by making the code changes noted.
Great, thanks
Oh, I just happened to notice that there’s a Readme:
= 7.4.0 – August 22, 2019 =
* Improvement: Added a MySQL-based configuration and data storage for the WAF to expand the number of hosting environments supported. For more detail, see: https://www.wordfence.com/help/firewall/mysqli-storage-engine/
* Improvement: Updated bundled GeoIP database.
* Fix: Fixed several console notices when running via the CLI.Wild theory: Because it’s .ca?
Got it.
OK, so I did that, removing what I had in this example form:
john@ourdomain.caAnd replacing it with the same thing minus the top domain.
Then I waited some hours for the next login attempt by
john@ourdomain.ca— but it was the same as before. That is, the Login Attempts section of the Firewall page shows four successive attempts (on the same IP) forjohn@ourdomain.ca, after which the “locked out” email is sent.So, it would appear that the “immediately block” feature doesn’t work in this scenario. If there’s anything else you want me to try, just let me know. Thanks.
Forum: Plugins
In reply to: [No Update Nag] 5.0.1 noticeOK, I misunderstood then. I did see that example notification of v3.9, and noted that it looked different than what I still see, but I attributed that to just a change in style over the years.
It turns out, however, that there are simply multiple notifications up there.
Thanks
Forum: Plugins
In reply to: [No Update Nag] 5.0.1 noticeFYI, updated to 1.4.6.
Wanted to report back that it works! Thanks.
Forum: Plugins
In reply to: [No Update Nag] 5.0.1 noticeAnd later, 5.0.2.