Automating Wordpress Autoptimize Cache Deletion

Over 30% of the sites across the web are believed to be on WordPress (source). To keep those sites running buttery smooth, a lot of optimizations are made. Most commonly, web pages are cached so that they can be served ludicrously fast. WordPress provides a plugin Autoptimize which does such optimizations and more for you.

Autoptimize minifies and caches the styles and scripts of your webpage and stores it on the server. This data can keep on accumulating and take up a lot of space if your site is heavy or loads a lot of resources within a few days.

To solve this problem, you need to log on to the WordPress admin page and from the options of Autoptimize plugin, delete the cache manually. This can be a painstaking task and you might be yearning to automate it.

We at Squad also encountered this problem. Unfortunately, not a lot of information was available on the web on how to achieve this. Fortunately, now there is :)

If you just need the solution and do not wish to read through the issues faced along the way, feel free to jump to section ‘The solution’.

Possible solutions

1. Adding a cron that periodically deletes the cache files directly on the server
2. Periodically hitting the API that WordPress uses when you delete the cache manually from the admin

(I succeeded on the 2nd solution so didn’t look out for any more)

The problems

1) Adding a cron that periodically deletes the cache files directly on the server

Autoptimize has a cache directory on the server where it stores all the cached data. If you picked the option to delete the files directly on the server, here’s a surprise — not all files are supposed to be deleted. If you delete all the files, your website will stop loading any resources.

So you might be thinking, “No problem I’ll just delete the files that are supposed to be deleted.” Aha! Here’s another surprise — since these files are minified and auto-generated, you won’t be able to figure out which file to delete unless you regenerate the entire environment in which these were generated.

You could try doing this if you have a lot of spare time and a good understanding of the WordPress code flow but I wouldn’t vouch for it.

2) Periodically hitting the API that WordPress uses when you delete the cache manually from the admin

If you trace the request made when you clear the cache manually from the admin (using Chrome Dev Tools or similar), this is how the request would look like (Image1)

Image 1

Focus on the Request URL. This is the URL of the API you’d want to hit. Notice the query params (Image 2)

Image 2

You’ll see “nonce”. What this means is that every time you make the request, WordPress has generated a nonce and is sending that along to the backend to validate if the request came from an authenticated WordPress account. If not, it shuts out the API access.

Now for a moment if we ignore the nonce problem, would it work? Not quite. If you copy this request as cURL, here’s what you’ll see (Image 3)

Image 3

Notice that along all the headers, a Cookie is being passed. The Cookie header is essential because WordPress has another layer of security where it prevents any API from accessing anything if the request did not come from a browser having Cookies enabled.

To be able to send the Cookie in this API, you need to have an authorized Cookie from a logged in authenticated user, so you need to hit the login API which would provide an authorized Cookie in the response.

The final problem with this is that when you hit the login API, it also needs the Cookie support (no this is not Inception :P). The good thing about this Cookie is that it doesn’t need to be a valid Cookie.

Considering all these problems then, here is a set of final steps that would solve this problem once and for all.

The solution

Get rid of the “nonce” problem

1. Open the file autoptimizeToolbar.php (generally found on the path wp-content/plugins/autoptimize/classes/autoptimizeToolbar.php) in any shell editor of your choice
2. Find the function delete_cache() and comment the first line as shown below (Image 4)
3. Save the file and exit the editor

Image 4

Hit the Login API with the valid Cookie having any dummy value

a) Extract the key for the Cookie

1. Log on to the WordPress admin
2. Open the Chrome Dev Tools (press F12)
3. Navigate to the “Application” tab, expand the “Cookies” tab on the left and choose the URL of your WordPress site as shown below (Image 5)
4. Copy the name that starts with “wordpress_logged_in” (as marked above with a red rectangle). This is the key for your Cookie

Image 5

b) Hit the login API with a cURL request as follows (Image 6):

Image 6

1. Replace the value in “log” with your WordPress admin username
2. Replace the value in “pwd” with your WordPress admin password
   (If it shows Incorrect password, make sure to encode special characters, if any, in your password)
3. Replace the key in Cookie being sent with the key that we extracted in Step a) of this point
4. Replace the URL with your WordPress site URL. Make sure to keep wp-login.php at the end to ensure that you hit the login API

Extract the authorized value of the Cookie from the file cookies.txt (as mentioned in the above cURL request)

Here’s a look of the cookies.txt file (Image 7)

Image 7

Image 8

1. The value marked in red is the one we need (Image 7). To achieve this programmatically, you’ll need a combination of grep and sed as above (Image 8)
2. In the above command replace “username” with your WordPress admin username (at both places)
3. The output will be the value that was marked with the red highlight (in Image 7)

Hit the delete cache API with the correct Cookie value

Image 9

1. Since you will be doing all of this in a .sh script to be able to run this by cron, I’d suggest storing the value of the previous step in a variable ($var in this case) and then using it to hit the API as above (Image 9)
2. Replace the URL with your WordPress site URL
3. Replace the Cookie key with the one derived in Step a) before
4. Once you execute this request, it should return “true”, which marks a successful request

Create a script (if not done already) having all the above steps and add it to a cron

While picking up this task, I had thought all I’d need to do would be add a cron that would either call an API or run a “rm” command to delete the cache files directly. But it was only after I dove deeper into the problem, did I fully realize its complexity.

At Squad we love tackling a challenge or solving a puzzle while simplifying the lives of others (automating a tedious repetitive task in this case). You can learn more about the culture at Squad at the following links.

Squad takes the Joel test
How we built an engineering culture of doing more with less

And if you’re a talented developer who believes she’ll be a good fit for Squad — we’re hiring!