Cache doesn't invalidate when permalink changes

[raffaelj]

Describe the bug

The cache doesn't invalidate when the permalink of a page/post changes.

I use "HDD" mode (which is a bit misleading, because files are stored on SSD) with the proposed changes to .htaccess.

To Reproduce

• create page with permalink /test/
• Open /test in browser to trigger caching of static file in /wp-content/cache/cachify/{host}/test/index{.html,.html.gz}
• Change permalink to /test2/
• /test/ folder with html file still exists in cache folder

Expected behavior

• When a permalink changes, the cached files /test/index.html and /test/index.html.gz should be deleted.
• Also the parent folder /test/ should be deleted.

System:

• OS: Local test instance, using docker with a modified version of wordpress:php8.1-apache (e. g. a2enmod rewrite expires headers)
• WordPress: 6.3-RC3-56351
• Cachify: 2.3.2

Solution

Use post_updated action instead of save_post and check against the original post to invalidate the cache with the original permalink.

• https://github.com/pluginkollektiv/cachify/blob/develop/inc/class-cachify.php#L96
• https://github.com/pluginkollektiv/cachify/blob/develop/inc/class-cachify.php#L1009

While there, internal methods should pass WP_Post instead of int $post_id to save a few db calls.

For reference:

• https://developer.wordpress.org/reference/hooks/post_updated/
• https://developer.wordpress.org/reference/hooks/save_post/
• https://developer.wordpress.org/reference/functions/get_permalink/

I could send a pull request with changes, but I'm not sure, if this plugin is still actively developed.

Other

I do some research about WP Cache plugins and Cachify looked promising (no bloat, readable code and a rant about CDNs in the docs).

First I tested WP Super Cache, but it loads the whole settings ui on each frontend call, which slows each non-cached request down. Also the code is unreadable.

Cachify is number 2 on my list. I like it, but as mentioned above, I would like to use (and contribute to) a maintained plugin.

Cache Enabler would be the next candidate. I read in an issue here, that it is a fork of Cachify. At first I wanted to drop that because of unhealthy permissions, but I saw, that Cachify has the same issue (chmod with 777 and 666) edit: While skimming over the code I misunderstood the meaning of $stat['mode'] & 0007777.

[stklcode]

Expected behavior

• When a permalink changes, the cached files /test/index.html and /test/index.html.gz should be deleted.
• Also the parent folder /test/ should be deleted.

I’d go even further and say more pages or the entire cache should be flushed. The link has changed, so all other pages that point to the modified page (e.g. via menus, where no “page modified“ event has to be triggered explicitly).

But I agree, flushing the cache for the old permalink seems to be a reasonable first action.

[raffaelj]

I’d go even further and say more pages or the entire cache should be flushed.

Good point. But I also use the Redirection plugin, that redirects changed permalinks. So the whole site doesn't break with outdated links. In combination with Cachify, the RewriteRule breaks this behavior:

• /test (no trailing slash) is internally redirected to /test2/ via Redirection plugin
• /test/` (with trailing slash) points the outdated page

For general site health and SEO, it's easy to press the cache flush button once in a while. So I would go with:

flushing the cache for the old permalink seems to be a reasonable first action.

[raffaelj]

I wanted to write a fix and immediatly found another bug:

[07-Aug-2023 14:42:42 UTC] PHP Warning:  filemtime(): stat failed for /var/www/html/wp-content/plugins/cachify/css/dashboard.min.css in /var/www/html/wp-content/plugins/cachify/inc/class-cachify.php on line 351
[07-Aug-2023 14:42:42 UTC] PHP Warning:  filemtime(): stat failed for /var/www/html/wp-content/plugins/cachify/css/admin-bar-flush.min.css in /var/www/html/wp-content/plugins/cachify/inc/class-cachify.php on line 359

Copying dashboard.css to dashboard.min.css to admin-bar-flush.css to admin-bar-flush.min.css solved it for now. From a quick look at composer.json and package.json it looks like I would have to install minifycss and minifyjs in the global scope to build everything in the intended way, which I want to avoid.

Are there any other gotchas, I should be aware of when working locally with just throwing the git repo in the plugins folder (actually mounting the git repo as a docker volume)?

[stklcode]

Yep, the minified files are generated in the build process (in Composer post-install or build stage), which requires dev-dependencies.

The project is not really suited for Composer or Git based setup, the tools are just used to generate all files for deployment to the WP repo in the CI/CD pipeline. But I think that’s all. There a a few files in the repo that should not make it into a prod WP instance (basically everything that’s listed in .distignore), but for dev/testing that should be fine.

[raffaelj]

From reading the code it looks like the old version wouldn't invalidate the cache when unpublishing a page. My PR fixes this too. But maybe this is handled in a different hook. I didn't read the whole source.

[raffaelj]

Now I ran composer install to fix the remaining linting errors. composer run-script lint-php doesn't show any errors anymore.

There is one "Code smell" from the SonarCloud tests and I'm not sure, if it's worth fixing.

it looks like I would have to install minifycss and minifyjs in the global scope to build everything in the intended way, which I want to avoid.

I thought, the minify scripts were from npm. But now I realized, that npm modules are only used for linting.

it looks like the old version wouldn't invalidate the cache when unpublishing a page.

Now I tested it with Cachify 2.3.2 and I can confirm, that the cache doesn't invalidate when unpublishing a page (changing status from "Published" to "Private"). It is the same behavior:

• /test (no trailing slash) shows a 404 as expected
• /test/ (with trailing slash) points to the page, that must not be available anymore

Changing the event from save_post to post_updated fixed the unpublishing issue, too.

[stklcode]

Thanks very much for your work. If nobody is faster, I will take a look at your changes later the day.

Resolved the sonar code smell with a comment. Unused intermediate parameters in hook callbacks should be fine.

[raffaelj]

Resolved the sonar code smell with a comment. Unused intermediate parameters in hook callbacks should be fine.

Thanks. I also had another look, if there is a better hook, but $post_before doesn't show up very often in post.php.

After doing some more research and testing a few more plugins I decided to use Cachify (or to write a simple plugin myself, that only supports file caching with apache rewrite rules). So the next question is: When will the next release be published? Or: What's needed to publish a new release?

After my PR is merged, I can install it via wp cli plugin install cachify --version=dev. After looking at the comparison of 2.3.2 and dev branch, using the dev version in production should be save.

edit: It's not save because of an invalid robots.txt.

I found the milestone 2.4.0 with many open issues. My feeling is, that this milestone won't be completed soon. Is there a chance to release a 2.3.3 instead?