Giter Club home page Giter Club logo

wp-ffpc's Introduction

=== WP-FFPC ===
Contributors: cadeyrn
Tags: cache, nginx, memcached, apc
Requires at least: 3.0
Tested up to: 4.7.2
Stable tag: 1.11.2
License: GPLv3
License URI: http://www.gnu.org/licenses/gpl-3.0.html

A fast, memory based full page cache plugin supporting APC or memcached.

== Description ==

**WARNING** The development of WP-FFPC had been put on hold.
If you need new features, please send code and pull requests to [WP FFPC @ Github](https://github.com/petermolnar/wp-ffpc).

*A short why: I developed this plugin in 2010 to support my own site. Right now, as it is, it's working on a few sites I still maintain for friends and since I don't need any additional features, I'm not planning to extend it with things I have no real use of. During the past years I've received some heartwarming donations - unfortunately the amount never came close to consider the project financially beneficial. I removed the donation links and put it on hold for now.*


WP-FFPC is a cache plugin for [WordPress](http://wordpress.org/ "WordPress").
It works with any webserver, including, but not limited to, apache2, lighttpd, nginx.

It can be configured together with [NGiNX](http://NGiNX.org "NGiNX") but use [memcached plugin](http://nginx.org/en/docs/http/ngx_http_memcached_module.html "memcached plugin") directly from the webserver, bypassing PHP.

= Requirements =

**This plugin does not kick in right after activation**. You have to adjust the setting in Settings -> WP-FFPC and save the settings.*

* WordPress >= 3.0
* **at least one** of the following for storage backend:
    * memcached with [PHP Memcached](http://php.net/manual/en/book.memcached.php "Memcached") > 0.1.0
    * memcached with [PHP Memcache](http://php.net/manual/en/book.memcache.php "Memcache") > 2.1.0
    * [APC](http://php.net/manual/en/book.apc.php "APC")
    * [APCu](http://pecl.php.net/package/APCu "APC User Cache")
* PHP 5.3+ is really highly recommended, see "Known issues"


= Known issues =

* errors will not be displayed on the admin section if PHP < 5.3, only in the logs. This is due to the limitations of displaying the errors ( admin_notices is a hook, not a filter ) and due to the lack of proper anonymus functions in older PHP.
* **If you're using PHP 5.4+ avoid the APC backend: the plugin with that setup can even make your site slower.** Please use APCu or memcached in this case.

= Features: =

* various backends
  * memcached with [PHP Memcached](http://php.net/manual/en/book.memcached.php "Memcached")
  * memcached with [PHP Memcache](http://php.net/manual/en/book.memcache.php "Memcache")
  * [APC](http://php.net/manual/en/book.apc.php "APC")
  * [APCu](http://pecl.php.net/package/APCu "APC User Cache")
* cache exclude options ( home, feeds, archives, pages, singles; regex based url exclusion )
* minor Woocommerce support
* (optional) cache for logged-in users
* 404 caching
* canonical redirects caching
* Last Modified HTTP header support (for 304 responses)
* shortlink HTTP header preservation
* pingback HTTP header preservation
* talkative log for [WP_DEBUG](http://codex.wordpress.org/WP_DEBUG "WP_DEBUG")
* multiple memcached upstream support
* precache ( manually or by timed by wp-cron )
* varying expiration time for posts, taxonomies and home
* (**warning**: untested since WordPress 3.8) Wordpress Network support
  * fully supported domain/subdomain based WordPress Networks on per site setup as well
  * will work in Network Enabled mode only for subdirectory based Multisites ( per site settings will not work in this case )


Many thanks for donations, contributors, supporters, testers & bug reporters:

Harold Kyle, Eric Gilette, doconeill, Mark Costlow, Jason Miller, Dave Clark, Miguel Clara, Anton Pelešev, Firas Dib, CotswoldPhoto, tamagokun, Many Ayromlou, mailgarant.nl, Christian Rößner, Ameir Abdeldayem, Alvaro Gonzalez, Meint Post, Knut Sparhell, Christian Kernbeis, Gausden Barry, Maksim Bukreyeu, Lissome Hong Kong Limited, Gabriele Lauricella, 7th Veil, LLC, Julia Harsch, Grant Berntsen, Jorgen Ilstad, Cinema Minima for Movie Makers Worldwide

== Installation ==

1. Upload contents of `wp-ffpc.zip` to the `/wp-content/plugins/` directory
2. Enable WordPress cache by adding `define('WP_CACHE',true);` in wp-config.php
3. Activate the plugin through the `Plugins` menu in WordPress ( site or Network wide )
4. Check the settings in `Settings` ( site or Network Admin, depending on activation wideness ) -> `WP-FFPC` menu in WordPress.
5. Save the settings. THIS STEP IS MANDATORY: without saving the settings, there will be no activated caching!

= Using the plugin with NGiNX =
If the storage engine is either PHP Memcache or PHP Memcached extension, the created entries can be read and served directly from NGiNX ( if it has memcache or memc extension )
A short configuration example is generated on the plugin settings page, under `NGiNX` tab according to the saved settings.
**NOTE:** Some features ( most of additional HTTP headers for example, like pingback, shortlink, etc. ) will not be available with this solution.

== Frequently Asked Questions ==

= The plugin is not working! =

Did you save the settings as mentioned in this document?
Do you have at lest one supported backend?

= It's making my site slower than it was! =

So far this only happened if PHP 5.4 or higher was used with APC.
Please avoid this setup; PHP 5.4 shipped opcache and APC is full of bugs since then. Use APCu with PHP 5.4+.

= Does it support mobile theme switching? =

No, it doesn't, and with the way it's currently working, it never will.
WP-FFPC is using the URL as key for caching, so it can't differentiate if there is no change in the URL.
*(I personally also disagree with separation of mobile and non-mobile theme; you need to support a plethora of screen sizes and resolutions, so just use responsive designs instead of splitted logics.)*

= Can you please add '(insert shiny new feature here)'? =

Sure. Send me a code and a pull request on [WP FFPC @ Github](https://github.com/petermolnar/wp-ffpc).
Unfortunately I don't have the resources to code it myself, but there are plenty of WordPress developers who would probably do it for a minor fee.


== Screenshots ==

1. settings screen, cache type and basic settings
2. debug and in depth-options
3. cache exceptions
4. memcached servers settings
5. NGiNX example

== Changelog ==

Version numbering logic:

* every A. indicates BIG changes.
* every .B version indicates new features.
* every ..C indicates bugfixes for A.B version.

= 1.11.2 =
*2017-02-08*

* annoying typos in text

= 1.11.1 =
*2017-02-08*

* exclude cache for WooCommerce
* fix load textdomain
* add Italian (it_IT) translation
* nonexistent redis support removed (it never got to a usable stable state, mostly due to the chaos with the redis php modules)
* readme cleaned up for development hibernation
* donation link removed
* WP version compatibility bumped

= 1.11.0 =
*2016-01-15*

* merged filter for HTML before it hits the cache
* refactored logging

= 1.10.1 =
*2015-10-30*

* fixed nginx configuration sample snippets
* nginx configuration moved from Settings tab to Help tab, so if you're looking for the "nginx" tab, you need to look under "Help" on the WP-FFPC Settings page.

= 1.10.0 =
*2015-10-23*

*IMPORTANT, READ THIS*

* Proper browser cache support:
    * new options to set real browser cache expiry for singles, taxonomy and home
    * added Etag support based on browser cache expiry
    * added proper Expires header according to cache entry generation time + browser cache expiry
    * added support for Last Modified header for home & taxonomy ( singles already had it) based on the last post modified date within the taxonomy

= 1.9.1 =
*2015-10-18*

* bugfix for is_writable check failures ( see: https://wordpress.org/support/topic/settings-saved-but-getting-not-saved-error-message)
* bugfix for memcached.protocol notice
* typo fixes
* replace variable with string constant in translatable messages

= 1.9.0 =
*2015-10-14*

* adding exclude option based on text entry matching ( regex )

= 1.8.4 =
*2015-10-13*

* changes in HTML debug comment: instead of the former, single comment, now 2 comments are added. The first is added when the cache entry is generated; the second only appears if the page was served from the cached entry. Please note that this last bit will - should - change with every single refresh.
* backend code is now split into separate files
* more debug code

= 1.8.3 =
*2015-05-07*

* small change in key creation: prefix is kept in front of sha1 hashes for debugging purposes

= 1.8.2 =
*2015-04-30*

* sha1 key hashing made to be optional
* added additional debug condition of WP_FFPC__DEBUG_MODE constant to be `true`


= 1.8.1 =
*2015-04-29*

* fixing the wrong release of 1.8.0

= 1.8.0 =
*2015-04-29*

What's new:

* backend keys are now sha1 hashes instead of full url; this is to prevent too long key error with memcached

Under the hood:
* wp-common is removed; no more git submodules
* logging method changed

= 1.7.9 =
*2015-02-02*

What's new:

* detailed log messages for other log message clarification
* added auto-upgrade for advanced-cache.php on plugin upgrade


= 1.7.8 =
*2015-01-30*

What's new:

* merged pull request for [wp-ffpc-purge](https://github.com/zeroturnaround/wp-ffpc-purge)


= 1.7.7 =
*2015-01-14*

What's fixed:

* fixed alert backwards compatibility for PHP < 5.3


= 1.7.6 =
*2015-01-09*

What's fixed:

* anonymus function call only for PHP 5.3

= 1.7.5 =
*2014-12-29*

What's fixed:

* wp-ffpc was not actually alerting when it had issues; this should be fixed now

This was a really bad bug and it could have cause a lot of issues since the plugin was probably not working in some cases when the alerts went unnoticed. Due to WordPress restrictions on admin_notices hook I had to use PHP features only present since 5.3. Please keep this in mind.


= 1.7.4 =
*2014-12-17*

What's changed:

* localhost cache forced exclude removed; instead please use `define('WP_CACHE', $_SERVER['REMOTE_ADDR'] !== '127.0.0.1');` instead as pointed out by [plescheff](https://github.com/petermolnar/wp-ffpc/commit/eb4942005273822aec8c2da09f0e763807f94f9c#commitcomment-9006031) if required
* compatibility tested up to WordPress 4.1

= 1.7.3 =
*2014-12-17*

What's fixed:

* expiration time set to '0' resulted instant expiration instead of infinite keep; fixed now

= 1.7.2 =
*2014-12-08*

What's changed:

* merged pull request for memcached proxy compatibility; memcached binary mode if off by default from now on

= 1.7.1 =
*2014-12-04*

What's fixed:

* [Unable to determine path from Post Permalink](https://wordpress.org/support/topic/unable-to-determine-path-from-post-permalink) noise fixed
* potential Multisite precache bug fixed ( database prefixes were not set according to original prefix )

What's new:

* added permanent cache exception of localhost

What's changed:

* pingback header preservation is now off by default and can manually be turned on

= 1.7.0 =
*2014-09-19*

What's new:

* added varying expiration time options

What's changed:

* **dropped Xcache support**: the reasons behind this is the outstandingly terrible documentation of Xcache
* **dropped persistent memcache mode**: no one was using it and even if the were only caused trouble
* **removed '/wp-' hardcoded cache exception**; this is now the default in the regex exceptions field as ^/wp-; please add this manually in case you've already been using the regex field

= 1.6.4 =
*2014-09-12*

What's fixed:

* downgraded log level from halting-level fatal to warning ( thank you PHP for the consistent naming... ) in case the selected extension is missing
* leftover code parts cleanup

= 1.6.3 =
*2014-09-12*

What's fixed:

* there were still some alway-on log messages

= 1.6.2 =
*2014-09-05*

What's fixed:

* merge pulled from [plescheff](#25)
* fixed bug of alway-on log messages ( warning was set to default where notice should have been )

= 1.6.1 =
*2014-09-04*

What's fixed:

1.6 release, correcting SVN madness with non-recursive copies.

= 1.6.0 =
*2014-05-30*

What's new:

* added functionality to exclude regex urls, contribution from [plescheff](https://github.com/plescheff/wp-ffpc/commit/3c875ad4fe1e083d3968421dd83b9c179c686649)
* added functionality to include "?" containing URL

What's fixed:

* some warning messages removed in case there's not a single backend installed when the plugin is activated
* fixed issue of resetting settings when new version of defaults was released

Under the hood:

* major changes to the abstract wp-common class for better interoperability between my plugins


= 1.5.0 =
*2014-05-30*

What's new:

* APCu backend added ( APCu is a stripped version of APC with only user object cache functionality what can be used with PHP 5.4 & 5.5 besides [Opcache](http://php.net/manual/en/book.opcache.php "PHP Opcache") )

= 1.4.0 =
*2014-05-12*

What's new:

* Xcache backend added ( theoretical, partially tested, volunteer testers required )

What's fixed:

* invalidation for comment actions added

= 1.3.3 =
*2014-04-29*

What's changed:

* removed broadcast message
* better logs ( additional logs and adding translation compatibility )

= 1.3.2 =
*2014-04-09*

What's fixed:

* 1.3.1 was a quickfix for an uncommitted change required for 1.3 to work.
* removed PHP warning in case WP_CACHE was off ( see #14 )
* PHP notices in log from [Harold Kyle](https://github.com/haroldkyle "Harold Kyle")
* ms is really second


= 1.3 =
*2014-04-04*

What's fixed:

* uninstall will not fail anymore ( and I hate PHP for it's retarted language restrictions )
* typo fix for memcache functions from [Dave Clark](https://github.com/dkcwd "Dave Clark")
* uninstall security lines from [Dave Clark](https://github.com/dkcwd "Dave Clark")
* modification to nginx sample file from [Harold Kyle](https://github.com/haroldkyle "Harold Kyle") to skip all urls with query string present

What's new:

* added unix socket memcache module support ( ONLY for memcache backend for now )

= 1.2.2 =
*2013-11-07*

What's fixed:

* 404 for first hit of 404 pages; bug report from [phoenix13](wordpress.org/support/profile/phoenix13 phoenix13)

= 1.2.1 =
*2013-07-23*

What's fixed:

* call to undefined function get_blog_option error fixed

= 1.2 =
*2013-07-17*

What's new:

* additional cookie patterns to exclude visitors from cache, contribution from [Harold Kyle](https://github.com/haroldkyle "Harold Kyle")
* syslog dropped; using "regular" PHP log instead
* pre-cache from wp-cron
* changeable key scheme ( was fixed previously ); possibility to add user-specific cache if PHPESSID cookie is present

What's fixed:

* logged in cookie check fixed ( was not checking all WordPress cookies )
* global error messages to show if settings are not saved

**Dropped functionalities**

* there's no info log on/off anymore, it's triggered when WP_DEBUG is active
* sync protocols has been removed for two reasons: this has to be done by other systems and causes issues in special cases

**For Devs**

* the abstract class have been moved into a separate Github repository, [wp-common](https://github.com/petermolnar/wp-common "wp-common"). Because PHP is not capable of replacing/redefining classes, there's a versioning with the abstract and the utilities class, please be aware of this.

= 1.1.1 =
*2013-04-25*

* bugfix: Memcache plugin was diplaying server status incorrectly ( although the plugin was working )
* bugfix: typo prevented log to work correctly

= 1.1 =
*2013-04-24*

What's new:

* HTML comment option for displaying cache info before closing "body" tag ( a.k.a make sure it works "noob" method )
* pre-cache function ( only manual pre-cache is enabled for now; uses permalinks structure )
* new, additional invalidation method: clear post & all taxonomy cache, including feeds
* full virtual server example to use the plugin with nginx ( originally it was only a snippet required to use the plugin )

What's fixed:

* contributed fixes from [Harold Kyle](https://github.com/haroldkyle "Harold Kyle") to surpress PHP notices and warnings; better CSS & JS enqueue; corrected admin panel descriptions
* bugfix for status check ( there were situations where the status was not updated correctly )
* manual flush cache bug fixed ( was only flushing if the settings were on "flush all" )
* bugfix on data & meta prefixes ( some places used hardcoded prefixes )
* feed caching fixed ( due to a security check it turned out feeds were excluded for a long time )

= 1.0 =
*2013-03-22*

* plugin development using [GitHub repository](https://github.com/petermolnar/wp-ffpc "GitHub repository") from this version
* Software licence change from GPLv2 to GPLv3
* backend code completely replaced ( object-based backend, improved readability & better structure, lot less global vars, etc. )
* added proper uninstall ( uninstall hook was not removing options from DB, uninstall.php will )
* revisited multisite support ( eliminated overwriting-problems )
* preparations for localization support ( all strings are now go through WordPress translate if available )
* more detailed log & error messages
* retouched Memcache initialization ( faster connect, cleaner persistent connections )
* proper settings migration from previous versions

**Bugfixes**

* faulty expiration times fixed
* eliminated warning message for memcache when no memcache extension is present
* fixed multisite settings overwriting issue

**Dropped functions**

* APC entry compression support

= 0.6.1 =
*2013-03-08*

* refactored & corrected backend status check for memcached driver

= 0.6 =
*2013-03-08*

* true WordPress Network support:
  * if enabled network-wide, settings will be the same for every site
  * if enabled only per site settings could vary from site to site and cache could be active or disabled on a per site basis without interfering other sites
* delete options button to help solving problems

= 0.5.1 =
*2013-03-07*

* settings link for plugins page
* readme cleanup
* setting link URL repair & cleanup

= 0.5 =
*2013-03-06*
WARNING, MAJOR CHANGES!

* default values bug ( causing %3C bug ) really fixed by the help of Mark Costlow <[email protected]>
* UI cleanup, new tabbed layout
* WP-FFPC options moved from global menu to under Settings in both Site and Network Admin interfaces
* added 'persistent' checkbox for memcached connections
* added support for multiple memcached servers, feature request from ivan.buttinoni ( ivanbuttinoni @ WordPress.org forum )
* case-sensitive string checks replaced with case-insensitives, contribution of Mark Costlow <[email protected]>
* refactored settings saving mechanism
* additional syslog informations
* additional comments on the code
* lots of minor fixes and code cleanup
* donation link on the top

= 0.4.3 =
*2013-03-03*

* long-running %3C bug fixed by the help of Mark Costlow <[email protected]>, many thanks for it. It was cause by a bad check in the default values set-up: is_numeric applies for string numbers as well, which was unknown to me, and cause some of the values to be 0 where they should have been something different.

= 0.4.2 =
*2012-12-07*

* added optional sync protocoll option: replace all http->https or https->http depending on request protocol
* binary mode is working correctly with memcached extension
* added warning message for memcache extension in binary mode

**KNOWN ISSUES**

There are major problems with the "memcache" driver, the source is yet unkown. The situation is that there's no response from the memcached server using this driver; please avoid using it!

= 0.4.1 =
*2012-08-16*

* storage key extended with scheme ( http; https; etc. ), the miss caused problems when https request server CSS and JS files via http.

= 0.4 =
*2012-08-06*

* tested against new WordPress versions
* added lines to "memcached" storage to be able to work with NGiNX as well
* added lines to "memcached" to use binary protocol ( tested with PHP Memcached version 2.0.1 )

**KNOWN ISSUES**

* "memcache" extension fails in binary mode; the reason is under investigation

= 0.3.2 =
*2012-02-27*

* apc_cache_info replaced with apc_sma_info, makes plugin faster

= 0.3 =
*2012-02-21*

* added syslog debug messages possibility
* bugfix: removed (accidently used) short_open_tags

= 0.2.3 =
*2012-02-21*

* NGiNX-sample.conf file added, NGiNX config is created from here

= 0.2.2 =
*2012-02-21*

* memcache types bugfix, reported in forum, thanks!

= 0.2.1 =
*2012-02-21*

* bugfix, duplicated inclusion could emerge, fix added, thanks for Géza Kuti for reporting!

= 0.2 =
*2012-02-19*

* added APC compression option ( requires PHP ZLIB ). Useful is output pages are large. Compression is on lowest level, therefore size/CPU load is more or less optimal.

= 0.1 =
*2012-02-16*

* first public release

wp-ffpc's People

Contributors

ameir avatar dkcwd avatar gablau avatar haroldkyle avatar igordb avatar shimoju avatar szepeviktor avatar tomcastleman avatar vdwijngaert avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

wp-ffpc's Issues

Force Save settings on Plugin activation?

Hi there,

is there any way to trigger/force save settings options tab to create db options table+advanced-cache.php on plugin activation?

Background: This would be great for automated deploy cases using wp-cli e.g. so that you don't need to login to each blog and click options save button.

FFPC serving desktop to mobile site

When combined with WP Touch or another mobile site library the FFPC plugin serves the cached site version to all visitors, even those from mobile user agents.

Request

The request here would be a way to disable cache for mobile user agents or to cache the different themes separately.

Disable Host name checking?

I have a custom URL setup where each user can have a subdomain for vanity purposes.

(\d+).example.com  (i.e. http://234.example.com)

However, wp-ffpc seems to require a separate config for each domain. Can this be disabled? I want wp-ffpc to see all sub domains as the same cache space.

This is not a multisite install. It's just a single blog with funky URL stuff going on.

deploy_advanced_cache() fails to save because Wordpress Filesystem API is not used

deploy_advanced_cache() fails to save on my Wordpress server setup because the Wordpress Filesystem API is not used.
https://codex.wordpress.org/Filesystem_API

Specifically, in my scenario the user under which the apache webservice runs does not have permissions to write to /wp-content and, of course, the needed advanced-cache.php file.

This scenario setup is a hardened setup. Wordpress fully supports this and abstracts away the problem by using the Wordpress Filesystem APIs. On my servers, I have configured Wordpress to allow a different user "wpadmin" to write to files/directories. This wpadmin user can do so using SSH2 and this is transparent after the initial wordpress config. https://codex.wordpress.org/Editing_wp-config.php#WordPress_Upgrade_Constants

I see in your code you often use file_put_contents(). In many of those location, it should be replaced with the Wordpress Filesystem API. This will then allow transparent file saves for php/config files in all situations (non-hardened, hardened, ftp, ssh2, etc.).

Per site settings ?

Hello,
Thank you for this awesome plugin ! It really rocks ! :)

We use this plugin on a wp network with hundreds of websites, and we would like to know whether it's possible to configure some settings per site ?

For example, we would like to turn on cache warmup, but only for a specific website, it is possible ? Could someone give any hint for doing this ?

Thank you very much :)

Saving advanced cache file across several instances

This is a somewhat specialized problem, but I thought I would spell it out and suggest a solution if you are interested in me working on this.

We have several EC2 instances running WordPress behind a load balancer. This usually works great because WP options are typically saved a the single database. In the case of WP-FFPC, though, if we make any changes to the advanced-cache.php, these are not saved the DB nor are they propagated throughout the EC2 instances--the changes will only save on the single instance we happened to connect with. This caused a performance issue today when we traced back sporadic site slowness to a single instance that did not pick up our changes to advanced-cache.php.

My thought was that in addition to saving these settings to advanced-cache.php, WP-FFPC could save these to the database. A cron event could periodically check the value to make sure the current advanced-cache.php file is up-to-date. I don't think this should be part of the plugin, because I can't imagine many people having this problem. So, it seems to me an easy and non-obtrusive way for me to do this is to just add a WP action inside WP_FFPC:: deploy_advanced_cache(). I could hook into this outside the plugin, passing through $this->global_config to do what I need to do. Thoughts?

Errors displayed even when Enable logging is off

I just updated to WP-FFPC 1.7.7 and now all messages are being displaying in my development environment (where I display errors). Things like:

Notice: PluginUtils – getting option wp-ffpc in ... wp-common/plugin_utils.php on line 131

In the past, I would deselect "Enable logging" in the WP-FFPC settings in order to quiet these, but this doesn't seem to have an effect anymore. It looks like you use $this->utils->alert() to display the filtered messages in WP_FFPC::plugin_post_init(). First, why not use $this->log() which would check the option value before displaying messages? But PluginUtils::_get_option() itself doesn't honor this option either, and will always display the notice above.

Hit or miss

Amazon CloudFront says: X-Cache: Hit from cloudfront

Could you modify X-Cache-Engine header to show hits and misses?

memcache unix socket not working

I configured the plugin to use PHP memcache backend with "unix:///var/www/mywebsite.com/tmp/memcached.sock" as host but unfortunately it does not work. Here is the PHP error output:

2014/06/18 17:09:59 [error] 2003#0: *52986 FastCGI sent in stderr: "PHP message: PHP Warning: MemcachePool::getserverstatus() expects parameter 2 to be long, string given in /var/www/mywebsite.com/htdocs/wp-content/plugins/wp-ffpc/wp-ffpc-backend.php on line 921" while reading upstream, client: XXX.XXX.XXX.XXX, server: mywebsite.com, request: "GET /wp-admin/options-general.php?page=wp-ffpc-settings&saved=true HTTP/1.1", upstream: "fastcgi://unix:/var/lib/nginx/fastcgi/wptest.ch.sock:", host: "mywebsite.com", referrer: "http://mywebsite.com/wp-admin/options-general.php?page=wp-ffpc-settings&saved=true"

codebase makes redundant nested calls saving options to disk and database

While adding the WP Filesystem API and removing direct disk access, I analyzed the multiple paths taken to reach deploy_advanced_cache(). I found multiple cases of code being repeatedly called. I am now refactoring parts of the code to remove some of the redundancies because they cause multiple hits to disk and database.

I found in the v1.10.1 codebase that the blocks of code that do saves and updates repeatedly calls itself in nests. plugin_upgrade() is the worst, it calls deploy_advanced_cache() four times.

plugin_admin_init()
    if ( button_save )
        plugin_options_save()

plugin_options_save()
    normalizes posted-in options and saves in class var: $this->options
    plugin_extend_options_save()
        update_global_config()
            deploy_advanced_cache()
        if ( !$activating ) deploy_advanced_cache()

plugin_extend_options_save()
    update_global_config()
        deploy_advanced_cache()
    if ( !$activating ) deploy_advanced_cache()

update_global_config()
    if ($removing)
        unsets $this->global_config[site]
    else
        $this->global_config[site] = $this->options
    deploy_advanced_cache()

plugin_upgrade()
    if (is_plugin_active())
        update_global_config()
            deploy_advanced_cache()
        plugin_options_save()
            normalizes posted-in options and saves in class var: $this->options
            plugin_extend_options_save()
                update_global_config()
                    deploy_advanced_cache()
                if ( !$activating ) deploy_advanced_cache()
        deploy_advanced_cache()

WP object cache backend

Hello @petermolnar !

As WP object caches are properly implemented (see for example wp-redis)
would it be possible to store the cache data in object cache?

When WP_CACHE is false, redirect_canonical is throwing a warning

In our development environment we leave WP_CACHE at false yet leave the plugin active. This had done no harm, other than creating an admin notice in the administration area: "WP_CACHE is disabled, plugin will not work that way." When we upgraded to 1.3.1, this environment caused a PHP Warning on the front end:

Warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'wp_ffpc_redirect_callback' not found or invalid function name

This of course works fine when WP_CACHE is true. This go me to thinking that the plugin should not get so far on the front end if caching is indeed off. Not sure if this issue is worth addressing or not, but perhaps you should check if WP_CACHE is true before hooking some of the plugin_setup actions.

wp-ffpc v 1.10.1 security vulnerable; form fields are not escaped

Throughout the code for wp-ffpc v 1.10.1, the code does not escape html and its values before/after processing by the form page. Therefore, it is possible for:

  1. a malicious string of html to be put in the config (using the form, direct to db, or direct to config file)
  2. that string is read and rendered to the wp-ffpc forms page as a concatenated string value (e.g. the nocache_cookies string value is between two double quotes on an input field)
  3. the malicious string could have its own double quote + a string of html causing XSS problems, automation to destroy the site, or any number of other hostile actions.

All input which is taken from users/admins and later rendered down to a browser needs to be evaluated for security holes like this. An example of this in wp-ffpc-class.php:

value="<?php echo $this->options['nocache_cookies']; ?>"
   should be instead
value="<?php echo htmlspecialchars($this->options['nocache_cookies']); ?>"

ffpc v1.10.1 catastrophic fail with PHP < 5.5 and/or Wordpress 3.0

While testing fixes for the filesystem usage in ffpc, I determined ffpc v1.10.1 is not compatible with PHP versions less than 5.5. It is also not compatible with Wordpress 3.0.

The fail is catastrophic. The plugin code will not activate or load in any way. The fail on PHP < 5.5 is in ...redis.php line 149. There is no "finally" clause in any version of PHP less than 5.5.

The catastrophic fail on Wordpress 3.0 is in ...backend.php line 356. There is no get_current_blog_id() function on Wordpress versions less than 3.1.

These catastrophic failures suggest the plugin has not been tested against Wordpress 3.0 or PHP < 5.5 since the above two code blocks were added. Perhaps wp-ffpc was tested when it was first released, but later code changes (like these) were made to the plugin and version testing was not undertaken.

There is no workaround other than updating
a) the plugin code
b) updating PHP and/or Wordpress
c) update the PHP and Wordpress version minimum requirements

For now, I have made code changes to v1.10.1 to resolve the above two catastrophic issues. The plugin will now load, however, there are a number of other UI bugs which are exposed.

processing or transmission of personal data - EU privacy regulation

Hi,
we use the plugin WP-FFPC (Version 1.11.2) on our website. we are located in germany. we need to check if the plugins used are compliant with the EU General Data Protection Regulation.
are personal data processed by the plugin? are personal data stored by the plugin? will personal data be transmitted through the plugin to countries outside the EU?
thanks for the information

Make flush only delete prefixed keys

Hi,

would it be possible to add another option to cache invalidation method where only prefixed keys (for this app) are deleted?
I prefer the flush all as it feels more safe (i.e reduces chance of support issues for customer), but it's not good that it flushes ALL keys in memcached as we have multiple sites using the same memcached server.

Apart from this your plugin is awesome!

Error on PHP 8.0

WP-FFPC 1.11.2 does not work with PHP 8.0.

How to fix as follow:

wp-ffpc-class.php
1016-1018 lines

[Before fixed]

	public function plugin_options_migrate( &$options ) {

		if ( version_compare ( $options['version'], $this->plugin_version, '<' )  ) {

[After fixed]

	public function plugin_options_migrate( &$options ) {
		if($options === false) $options = array('version' => '0.0');
		if ( version_compare ( $options['version'], $this->plugin_version, '<' )  ) {

This is caused by the

wp-ffpc-abstract.php
From line 514
public static function _get_option ( $optionID, $network = false ) {

In _get_options( $optionID, $network = false ), the return value $options has several patterns such as false (bool value), array, etc. When installing for the first time, the WP-FFPC setting does not exist in the database used by WordPress, so the value of $options becomes false (bool value).

Then the following $options['version’] (public function plugin_options_migrate in wp-ffpc-class.php)
) will not exist ($options = false), and the first argument of version_compare will be false. However, since version_compare expects a string as an argument, a type mismatch will occur, and as of PHP 8.0, it is an error to do so.

Please fix the issue.

pull request 49 causes duplicate calls to preg_match() to scan URLs

The recent merge of pull request #49 (related to not caching woocommerce pages) now causes duplicate code to be run in wp-ffpc-acache.php.

wp-ffpc-acache.php,
lines 72-80 ee76a2a#diff-73d3104eaa45e805aba460e1f5059991R72
and 105-112 ee76a2a#diff-73d3104eaa45e805aba460e1f5059991R105
are basically the same.

  1. they look if there is a regex pattern on an URL to exclude from cache
  2. they call preg_match()
  3. return false if match found

This results is two calls to preg_match() when only one is needed.
I get that someone wants to have an easy way to write the regex expressions. That's the only benefit this provides. I suggest that such a benefit is provided in another way and then the regex values are send into a single preg_match() call.

Ideas like:

  1. with a "help" tab or section in the plugin, if someone has woocommerce installed, put static text of a regex which someone can copy-paste into the primary (only) exclude from cache by URLs field
  2. capture the woocommerce specific regex, save it, then merge it into the main regex, then send that combined regex into a single preg_match() call

Homepage bypassing Memcache (nginx)

This is related to #11

I'm trying to serve a Wordpress site using Memcache. The goal is to have nginx directly serve cached pages without proxying to PHP-FPM.

Since using index index.php in an nginx config will rewrite the request to /index.php, nginx is locating the request as an actual file, and bypassing the @memcached location block.

I've been trying to figure out how I can get this to properly pass /index.php through memcached first, but no luck.

Cached items not being set into Memcached

I have the plugin installed and the nginx config for memcached running just fine. The site works great.

However, sitting here watching the memcached server stats I only see hits for "get" but the plugin doesn't seem to be calling "set" on the server to store the pages.

STAT cmd_get 7
STAT cmd_set 0
STAT cmd_flush 0
STAT cmd_touch 0
STAT get_hits 0
STAT get_misses 7
STAT delete_misses 0
STAT delete_hits 0
....

So the nginx config keeps skipping loading from memcached (because there isn't anything in there) and keeps loading wordpress.

concurrency failure with multisite when NOT network activated; advanced-cache.php data loss

While fixing #56, I discovered that wp-ffpc does not handle concurrency when read/writing the advanced-cache.php file under Wordpress multisite when not network activated.

Scenario:

  1. Have WP multisite
  2. Install wp-ffpc in the network. Do not network activate and, instead, enable it for subsite admins.
  3. The admin for subsite "alpha" activates wp-ffpc
  4. The admin for subsite "beta" activates wp-ffpc
  5. The admins for alpha and beta simultaneously change and save their wp-ffpc settings.

Step 5 exposes the problem. Two admins on two (or more) subsites could make changes to their wp-ffpc config at the same time. When different threads/processes are running the PHP, it is possible for the memory structure of the wpffpc global config to not match the memory structure of the on-disk advanced-cache.php due to the order of execution of the different site's threads. For example:

Thread alpha reads advanced-cache.php into memory
Thread beta reads advanced-cache.php into memory
Thread alpha makes changes to its copy in memory
Thread beta makes changes to its copy in memory
Thread alpha writes from memory to advanced-cache.php
Thread beta writes from memory to advanced-cache.php

Result:  advanced-cache.php has only beta changes. The alpha changes were lost.
This causes confusion by the site admins + support burden on the super admin.
  • One solution to a problem like this is to use a mutex or another type of exclusive locking mechanism. However, this can be complex to prevent excessive server load, long page times, or deadlock situations. http://anirudhsasikumar.net/blog/2008.01.15.html
  • Another solution is to avoid the scenario from occurring. For example, to only allow network activation in WP multisite (no activation/deactivation per-site).

I would recommend the second solution. That is, to only allow network activation and not per-site. In that solution, there is only one admin (the super admin) making changes. It is highly unlikely that super admin will have two browsers open at the same time, on the wpffpc settings page, pressing save at the same time.

Custom post type archive

Great plugin. I have some troubles getting it to work with my custom post types. If i change and save a post in my custom post type the cache of the single (detail) page get emptied. The archive is still using the old changed title. In other words the archive page of my custom post type is not emptied. This is the same for all my custom post types. is there a best practice to fix this?

ffpc v 1.10.1 poorly renders admin UI on all Wordpress less than v3.8

With wp-ffpc v1.10.1, the admin UI fails to render correcting on Wordpress versions less than 3.8.

This is partially due to the following code:
wp_register_style( $this->admin_css_handle, $this->admin_css_url, array('dashicons'), false, 'all' );

This will fail to work on Wordpress < 3.8 because the dependent stylesheet 'dashicons' does not exist until Wordpress 3.8. Because the missing dependency can't load, the wp-ffpc stylesheet will not load.

This leads to missing UI elements and render failures. It is possible the features still work if you can understand/navigate through the UI as it is. Preliminary and incomplete testing demonstrated it would successfully save and reset settings.

To workaround the immediate code issue above, I have changed the code above and removed the dependency on 'dashicons'. This appears to be safe at this time because...

  1. I can find no occurrence of the string "dashicons" in the entire wp-ffpc codebase.
  2. Looking at the dashicons.css in WP 4.5, all fonts and styles within dashicons.css start with the string "dashicons"
    Therefore, there is very likely no part of wp-ffpc is using dashicons.

After this code change, the css is loaded. However, there continues to be large UI render failures. One example of a failure is the jQuery slider will not render. This is because version 1.5 of jQuery is needed for slider code. However, Wordpress did not include the needed jQuery until Wordpress 3.2 (which included jQuery 1.6.1).

Question about post status hooks

There is a function for listening to post status changes which you are using to check for cache invalidation.

However, the code seems to be wrong.

    foreach ( $post_types as $post_type ) {
        add_action( 'new_to_publish_' .$post_type , array( &$this->backend , 'clear' ), 0 );
        add_action( 'draft_to_publish' .$post_type , array( &$this->backend , 'clear' ), 0 );
        add_action( 'pending_to_publish' .$post_type , array( &$this->backend , 'clear' ), 0 );
        add_action( 'private_to_publish' .$post_type , array( &$this->backend , 'clear' ), 0 );
        add_action( 'publish_' . $post_type , array( &$this->backend , 'clear' ), 0 );
    }

Shouldn't the following be changed to this?

        add_action( 'new_to_publish' , array( &$this->backend , 'clear' ), 0 );
        add_action( 'draft_to_publish' , array( &$this->backend , 'clear' ), 0 );
        add_action( 'pending_to_publish' , array( &$this->backend , 'clear' ), 0 );
        add_action( 'private_to_publish' , array( &$this->backend , 'clear' ), 0 );

    foreach ( $post_types as $post_type ) {
        add_action( 'publish_' . $post_type , array( &$this->backend , 'clear' ), 0 );
    }

or even

    add_action(  'transition_post_status',  function($new, $old, $post) {... });

http://codex.wordpress.org/Post_Status_Transitions

Front pages on multisite not being cached

I have the above issue with WP-FFPC.

Stack:
Apache / mod_php / PHP 5.3 / APC
WordPress MultiSite with subdomain mapping.
Network Activated WP-FFPC.

Issue:
The front page of all sites in the network is not cached. The front page of the first blog is cached however.

Example:
site.com/ - cached
site.com/test - cached
subsite.site.com/ - not cached
subsite.site.com/test - cached

Any ideas why this is happening? I have not enabled any cache exceptions.

Add a filter before adding page to the cache

Hello,

First of all: love your plugin. Does what it needs to do and not bloated!

Here's my idea: I would love to be able to minimize the HTML output of my pages before they are being added to the cache. This could easily be achieved if you allowed the page to be altered before you store it in the cache. I think adding a simple filter would allow this in a gracious way.

I'll provide a pull request asap, I hope you'll take a look at it so others can benefit this too!

Sincerely,

Koen

Can I run this alongside an object-cache?

This isn't so much of a bug report as a question about how this plugin actually works under the covers. I thought I understood Wordpress caching, but then I read some docs + code, and now I'm confused... any help is appreciated.

I'm trying to accomplish the following:

  1. Use Wordpress built-in caching mechanism to cache stuff for logged-in users. From my understanding, this stores the output of object compilation so PHP can work with pre-assembled objects and doesn't have to recompute values and re-hit the DB... among other things, it can make the admin panels faster. I've been using this memcached object cache plugin to tell Wordpress to use memcache as the backend for the built-in object cache with no issues.
  2. Full-page cache for logged-out users. I'd like to start using WP-FFPC to serve pre-generated pages Nginx --> memcache server and entirely skip PHP interpreter/MySQL.

Conceptually these are very different, so I assumed they wouldn't conflict, but when I installed WP-FFPC, it requires that I set define('WP_CACHE', true); in wp-config.php, which makes me wonder if it's using Wordpress' built-in caching mechanism somehow?

Cross-posting here: tollmanz/wordpress-pecl-memcached-object-cache#67

Add gzip comression data before set memcached key

Please do php 'gzencode' $data before save to memcached and add $flags to 'set' it is undocumented but work in memcached:
set($key, $data, $expire, 1);
get($key, null, null, $flags); //$flags now is 1

After that we can use nginx with comressed memcached content with gunzip on; &memcached_gzip_flag 1;

Benifits is less memory for memcached and less cpu usage of nginx.

Single site with multiple domain names

I got error message like "Plugin settings are not yet saved for the site, please save settings!" in my nginx logs.

My site has multiple domain name, and is using domain-based template switcher. However, FFPC seems to save only one domain name in the global options array when settings is saved.

So next time when the other domain name reaches, $this->global_saved variable will be false and causing error messages.

Can you please add an option in the settings to let user enter multiple domain names(separated by comma, etc), and save the global option array with multiple domain names as keys?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.