Flush Opcache with Varnish: a WordPress Plugin Announcement

Flush Opcache with Varnish is here to rescue you from the constant annoyance of flushing yet another cache!

If, like me, you use PHP’s Opcache to speed up a site, and you have a Varnish cache, and maybe some other server-side caches, you probably want to flush the opcache, Varnish cache, and any other server-side caches at the same time after changing the PHP files on your server, (like, when you update WordPress, plugins, or themes). I don’t want to click a button for each cache type, or worse, have to log in to the command-line for a sudo service restart varnish after doing updates, especially if I’m doing repeated updates. Flush Opcache with Varnish hooks into Mika Epstein’s excellent Varnish HTTP Cache plugin and flushes the PHP Opcache and the WP Super Cache cache, (if you use WP Super Cache), every time you manually flush the Varnish cache, turning the Varnish HTTP Cache “Clear Cache” buttons into a three-for-one deal.

If you also use the plugin WP Opcache to manage your opcache then WP Opcache will be called to do the actual Opcache flushing so you can take advantage of its automatic rebuilding of the opcache.

I’m already using Flush Opcache with Varnish in production and it’s saving me time every time I update a theme or plugin. You can get it in the WordPress.org plugin directory.

Starting a Side Project

There’s a side project that I’ve had in my head literally for years. It will solve a minor annoyance I have that comes up a couple of times per year, and an extremely basic version should be quite quick to put together. Even though I’m snowed under with work, one of the annual events that the project will help with is coming up very quickly, so I’m going to get a rough version online to use, with my family, and see what works and what doesn’t. I also intend to blog about the process, and track the time spent on the project.

The nature of the project will be kept secret for a while.

Why now, After so many Years?

TL;DR: I think that web development has progressed to a point that I can get a lot of value out of the project for a reasonable amount of work.

For years this was “the project that I would learn Rails with,” back when Rails was the cool kid on the block. Now PHP, which I’ve worked with for years, has grown up and I don’t feel the same need to learn Rails. This is a chance to try some modern PHP techniques that are difficult to push into legacy projects, in an environment where I’m the one who will suffer if I screw up.

There’s a heavy mobile component, so I plan to use a Responsive design, which I haven’t gone all-in on before, and I recently learned a bunch of performance tricks, so stay tuned for some greased lightning.

SASS, and Grunt build routines for SASS, Grunt, and images have made their way into legacy projects but I’ve never started a project with these in place, and I’m excited to see how it goes.

Finally, by building on the old-fashioned LAMP stack I can host the project on existing servers at no additional cost so the only cost will be my time.

Source, Open and Closed

This unlike a couple of other projects, this one will be largely closed-source. I think it may be a viable business so I intend to find out before giving it away for free. This means I got to have adventures in setting up a Git server instead of relying on GitHub.

I will be sharing things that are not core to the business such as interesting techniques, and maybe my Gruntfile. If the project doesn’t become a business, I may release the source, only time will tell.