carbeck

And while that may be a problem, it is not the specific problem I have (it may be related, though).

The reason I made this thread is that file permissions on wp-config-cache.php are apparently so restrictive since updating to 1.6.1 that I can’t easily backup my site with the tar program anymore without first resetting permissions on that file so as to be readable by the regular user (user me), and not *only* by WordPress (user web). This is slightly annoying because my host does not allow that to be dealt with by simply issuing sudo chown me; chmod 664 in an SSH session.

I should add that I have the FS_CHMOD_FILE directive set to 0664 in my wp-config.php to actually avoid this problem.

@patrickrobrecht, @stklcode: Das scheint zu funktionieren. Wenn ich meine Seite aufrufe, wird in der Datenbank jedenfalls ein Eintrag gemacht. Vielen Dank für eure Arbeit!

I did a little investigating and it looks like what I want could be achieved by modifying the buildGalleries function in js/wpFeatherlight.js. Within this function, a jQuery function .find( '.gallery-item a' ) is called twice with slight variation (.gallery-item and .tiled-gallery-item). This makes the lightbox apply to any links in WP galleries.

As I mentioned, however, the File Gallery plugin allows you to place non-image files in galleries as well in order to list files by tag from the Media Library. I suspect that what I want can be achieved by changing the jQuery function call to .find( '.gallery-item a[data-featherlight=image]' ) (mutatis mutandis) to capture only those links in WP galleries which link to image files when creating a lightbox gallery.

Edit: I just tested it, and indeed, by filtering image links from WP galleries specifically, Featherlight will only consider image files for lightbox gallery creation. It’d be nice if the plugin authors could consider such a feature for future versions in some way.

• This reply was modified 6 years, 10 months ago by carbeck.

Wenn ich es in einer separaten PHP-Datei ausführe, also nicht irgendwo in wp-config.php eingebettet:

7.1.17-nfsn1
NULL
NULL
string(14) "/temp/test.php"
NULL
string(135) "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/66.0.3359.139 Chrome/66.0.3359.139 Safari/537.36"
NULL

Der Referer ist dann natürlich NULL, weil ja kein Request von irgendwo anders vorliegt, wenn ich die Datei direkt aufrufe. filter_input() scheint bei meinem Hoster allerdings nicht zu gehen.

• This reply was modified 6 years, 10 months ago by carbeck.
• This reply was modified 6 years, 10 months ago by carbeck.
• This reply was modified 6 years, 10 months ago by carbeck. Reason: Aufteilen der Ausgabe in Zeilen

Das gleiche bei mir, die Seite ist ayeri.de. Versionen:

Statify: 1.6.2
Wordpress: 4.9.6
PHP: 7.1
Apache: 2.4
MariaDB: 5.3.12

Statify-Einstellungen:
[x] Page tracking via JavaScript
[ ] Skip tracking for referrers listed in the comment blacklist

Andere, vielleicht relevante Plugins:
Autoptimize 2.3.4 (Ausnahme für statify/js/snippet.js eingetragen, snippet.js wird auch separat geladen, statify_referrer wird gesendet)
WP Super Cache 1.6.1

Auch wenn ich nicht in WP eingeloggt bin, erfolgt selbst nach Leeren der Caches kein Eintrag in der Datenbank. Und das, obwohl statify_referrer gesendet wird.

• This reply was modified 6 years, 10 months ago by carbeck. Reason: Infos zur Datenbankversion

Same here, and seems to be a bug that’s managed to sneak back in: https://www.ads-software.com/support/topic/wp-cache-config-php-file-permission/

At least when I list the currently cached files, permissions for this file change to the user the server is running WordPress under (instead of ‘me’) with permissions 600. Should be 644 at least.

This is especially annoying to me because using TAR to make a backup of my files, TAR chokes on this file since it’s not readable to the regular user.

• This reply was modified 6 years, 10 months ago by carbeck.

It seems to work when I activate the Domain Mapping option in WPSC, even though the actual Domain Mapping plugin is not installed.

• This reply was modified 8 years, 1 month ago by carbeck.

For what it’s worth, even after deleting the exclamation mark in my modified version of WP Super Cache’s plugin for Bad Behaviour, caches are still served.

OK, I fiddled around with the settings, and it appears that even if I choose “Use PHP to serve cache files” and turn zlib compression off, the Javascript BB inserts will include the IP of the visitor that generated the cache. I assume it’s not supposed to work that way.

If I understand https://www.ads-software.com/support/topic/support-for-bad-behavior-standard-in-wp-super-cache?replies=14#post-1012559 correctly, you have to set “Use PHP to serve cache files”, not “Legacy page caching” to get the Bad Behavior plugin working, is that correct? I mean, since BB is dynamic, it would make sense. However, “Only legacy caching supported” in the description for the BB plugin is a little misleading in that case?!

[Ignore this post here, I read up on it myself and it’s not relevant anymore]

This might be a separate issue, but it’s also been puzzling me:

Why doesn’t this IP get blocked, even though it should:

8.14.146.234
Spamhaus: listed in XBL, because it appears in CBL (reason: part of a botnet) — 234.146.14.8.zen.spamhaus.org has address 127.0.0.4
Project Honeypot: suspicious, comment spammer, threat rating 25 (last seen: 2 days ago) — myapikey.234.146.14.8.dnsbl.httpbl.org has address 127.2.25.5
Stopforumspam.com: 65 entries

(I made the host requests manually while being logged into my server with SSH)

I had these settings in my 3rd party configuration, but the IP was still allowed to access, is not found in the cache, and no emails were sent:

Stopforumspam: all thresholds set to 5 (no API key)
Spamhaus: activated
Project Honeypot: all thresholds set to 20 and “Suspicious”, API key entered.

Or does activating all three sources mean that an IP has to be in all 3 lists to get blocked, not just in any one of them?

Hi Peter!

Yes, it’s in my cache and marked as spam, so it’s not just my server malfunctioning, I suppose. Which is why I wondered. It’s happened a few times before since I installed FDAS.

Oh wait, question 1 answers itself:

Cache the IP's that meet the 3rd party termination threshold and the IP's that are not detected by the 3rd party.

That still leaves question 2, though. Case in point:

46.151.52.XX - - [10/May/2015:16:27:00 +0000] "GET /legal HTTP/1.1" 500 3215 "https://mysite/legal" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.65 Safari/537.36 OPR/26.0.1656.24"
46.151.52.XX - - [10/May/2015:16:27:01 +0000] "GET / HTTP/1.0" 200 21307 "https://mysite/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.65 Safari/537.36 OPR/26.0.1656.24"

Projecthoneypot gives this IP a score of 49 and says it’s a comment spammer, hence FDAS blocked it. However, it only blocked the initial access, not the subsequent one to the front page – which was also apparently sent uncompressed even though it should be.

Thank you again for your assistance, Stefano! Since updating the plugin today, compression seems to work correctly ??