phil1984

But did you try changing the permissions so your webserver can write to that file? Looks like you XXXXed out the owner and group of that file so we can’t see.

I had the same issue with linux + PHP 5.6 + open_basedir set + mod_mcrypt. Are you using this combination?

You should be able to fix it either by disabling mod_mcrypt, or by adding “/dev” to your open_basedir path.

I have reported the issue.

Hi Gioni,

I have just found this line in my logs hidden away in my /var/log/messages file. It seems to be killing PHP execution at a cruicial point.

Feb 26 09:22:10 php1 suhosin[18954]: ALERT – function within blacklist called: openlog() (attacker ‘xx.xx.xx.xx’, file ‘/xxxxxxx/public_html/wp-content/plugins/wp-cerber/wp-cerber.php’, line 391)

I wrongly assumed it was a problem with your plugin. Sorry for the false alarm.

Options JSON:

{“attempts”:10,”period”:60,”lockout”:60,”agperiod”:999,”aglocks”:3,”aglast”:48,”notify”:”1″,”above”:”5″,”subnet”:”1″,”nonusers”:”1″,”loginpath”:””,”cilimit”:200,”ciperiod”:5,”ciduration”:60,”cinotify”:”1″,”email”:””,”keeplog”:”90″,”usefile”:”1″,”stopenum”:1,”xmlrpc”:1,”ping”:0,”nofeeds”:0}

For Reference:

Attempts: 10 allowed retries in 60 minutes
Lockout duration: 60 minutes
Aggressive lockout: Increase lockout duration to 999 hours after 3 lockouts in the last 48 hours
Yes (checked): Notify admin if the number of active lockouts above 5
No (Unchecekd): My site is behind a reverse proxy

Block subnet: YES
Non-existent users: YES
Redirect dashboard requests: NO
Request wp-login.php: NO

Custom Login URL: <EMPTY>
Disable wp-login.php: NO

Citadel Threshold: Enable after 200 failed login attempts in last 5 minutes
Duration: 60 minutes
Notifications: YES

Notification Email Address: <EMPTY>

Keep records for: 90 days
Use file: YES

Had a similar issue with WP 4.4 which caused an infinite loop somewhere during the login process. It only seemed to affect new people wanting to login as existing login cookies worked fine. The apache threads never end and thus end up killing the server.

Turns out it wasn’t a plugin issue. We dont use any mu-plugins. Reverting to 4.3.1 was the only thing that fixed it. Managed to narrow it down to something inside of wp_signon.

Ah I remember the days of stripslashes.

I placed a script tag with some json inside a nooptimize tag and it really can screw up your website something bad. Removing backslashes from json code can cause html parsing errors if the json itself contains html strings.

I removed that stripslashes and it seems to be working. When is the next release?

Thanks for finding this Frank. Saved me hours probably.

This is not resolved

https://www.ads-software.com/plugins/all-in-one-seo-pack/

WordPress 4.2.2
Plugin 2.2.7

Broken

Yep true. If that function could be made available at the application cache layer somehow, it would be possible to add this as a feature to the plugin. It could just be a checkbox called “Vary cache based on wp_is_mobile”. Modifications would also need to be made to the crawler to crawl each page twice with different user agents.

Yes of course. Your example is specifically for when you are hiding images with display none which was not what I was talking about. And yes that is silly to do because it doesn’t prevent download.

I’m not going to say one way to do things is right or wrong, but I am just pointing out that if you write truely responsive code which is user agent agnostic (identical for all devices) and “responds” appropriately, then you would not have any problems with caching. This is one direction you can take and in my opinion the easiest.

I disagree also. It is not really limiting to only use responsive media queries. display: none; actually tells the browser not to render that element, so for small things (e.g. menus), you dont save much loading time or data by leaving out the desktop menu markup for mobiles. In my opinion it is certainly not worth the complexity. If you are serving completely different pages based on user agent you should ask yourself, “Do I need 2 seperate websites?”.

I am a bit shocked that wordpress made this function unavailable in the advanced cache layer as it could easily be used to implement some kind of Vary caching against User-Agent strings. The problem with this is that there are just so many User-Agent strings out there that it would probably render the cache useless.

You cannot use both W3 Super cache and WP FFPC at the same time as they both hook in to wordpress using this file.

You cannot easily add it manually either because it needs all the settings you choose.

It is probably a file/directory permissions issue. The plugin will not update the advanced-cache.php file if it cannot remove it. Try deleting it through your ftp client.

The user who owns the server process (e.g. www or apache) needs to have write and execute permissions on the wp-content directory. You might need to make wp-content group writable and executable depending on which user owns the directory.

It looks like the one for method 3 is in development but not turned on yet. As of v1.8.3 anyway.

Method 4 should flush the assigned page for posts.

It all depends on the option show_on_front. If it is “page” then you are using custom page ids for the start page (page_on_front) and the posts page (page_for_posts).

Is there a point to deleting the file first?
file_put_contents will overwrite the file by default.

Hi MailShark

Please check your wp-content/advanced-cache.php file

Does it look ok? It should include the wp-ffpc-acache.php file at the end. If it doesn’t, try resaving in the settings page to regenerate the file.

Thanks

Thinking about this more, since WP-FFPC is acting as a caching layer, perhaps it should be catching and storing the headers with the data like other caches do. After all, if I output some custom header, I wouldn’t want it to disappear if it serves the cached version. The Content-Type header is already put in the meta array anyway. You can access the headers with the headers_list function. The only other issue is with the age part of the Cache-Control header and it should really be calculated on the fly.