Month: April 2016

Automattic Code Wrangler Application

My application for a position as a Code Wrangler at Automattic, the company started by WordPress co-founder Matt Mullenweg.

Good day

I’ve written this email in my head about 5 times, one for each year since 2010, when I first became aware of Automattic. Each time I never actually sit down, type it up and send it. I’ll do my best to explain why below. I apologise in advance for the length of my story, but it takes some time to explain.

Since 2006 I’ve been developing in PHP and I started blogging with WordPress in 2009. In 2011, I left full time employment to assist my wife in her family’s business. The business supplies data to estate agents and as such we work full day Saturday and Sunday until quite late. To keep involved in web development (which is my first passion) I took a position with a local development agency who were flexible enough to give me an on site position that matched my availability.

That worked well for about 4 years. However last year I decided to resign (mostly for personal reasons but mainly because I was becoming frustrated with the in-house CMS system that we worked with) and I am back to looking for a position which fits my specific availability, working remotely for up to 21 hours a week. The main reason I’ve never sent this application to Automattic was because I assumed that this would be a restricting factor.

I’m the kind of developer who,when tasked with writing a form submission script, will first spend half an hour asking other members of my team if the framework we are using has it’s own get_request_vars() type function (or looking through the docs and code for one, if no one knew) instead just using $_REQUEST or writing my own. I love solving problems through code, from making a script which converts .xlsx files to .xls for my wife (don’t ask, don’t tell) to building larger complex eCommerce stores. I have a huge respect and passion for good written documentation, so much so that I got involved with the new WordPress HelpHub project after WordCamp Cape Town 2015. I can think of nothing more exciting than building/improving a product that is used by people around the world.

Finally I believe that as a developer I am only as good as the rest of my team, so supporting my team (both in mentoring where I can or just keeping spirits high) is almost as important to me as my own work. How this passion for people would fit into a remote work situation I have yet to discover, but I’m excited to find out.

Filed under: WordPress

Divi Page Builder Cache

The latest versions of the Divi Page Builder includes very smart caching. This can sometimes lead to problems where users find they can’t add or delete rows or modules or use custom modules.

Disclaimer: I’ve only really experienced this issue when developing module customisations. So this may not work for your specific Page Builder caching situation. Results may vary.


Divi’s Page Builder uses the JavaScript LocalStorage API. Basically this allows the Builder to store the Page Builder cache on your computer instead of in your browser, meaning that even clearing your browser cache does not clear the Page Builder cache.

You can see the LocalStorage elements from your browser’s inspector window. In Chrome it is found under Resources (see image below)


To clear the LocalStorage items you need to run a line of javascript in your inspector window’s Console tab.

for(var prop in localStorage)localStorage.removeItem(prop);

I’ll expand this below so you can see what its doing.

for (var prop in localStorage) {

What this does is loop through each property in LocalStorage and remove it from LocalStorage. Simple!

UPDATE 05/11/2016 As John kindly pointed out in the comments below an even quicker way to clear the local storage would be to just clear the local storage object.


Once you’ve done this you’ll need to refresh the page to see if it has worked.

It’s worth noting that any other web apps you use that may use LocalStorage will also be cleared out, so it’s perhaps best to check if there are any other LocalStorage properties that aren’t Divi specific.

For those who aren’t as tech savvy to know where their inspector window is or how to use it, I’ve created a simple plugin that will clear all localStorage while using the WordPress admin interface if activated. I don’t recommend you leave it activated at all times. You can download the plugin here. Please note that this runs some JavaScript in your admin view, so once you activate it, refresh your admin view and leave it for a few seconds, before trying the Page Builder again.

I’d love to hear if this solved your specific Page Builder caching issues, so please leave a comment below if this helped you.

Filed under: Development, Divi, WordPress