Becoming a Googler

I often see tweets from people in the industry announcing major career changes; I never expected that I would be adding to this stream, but today I am. After more than 8 years at XWP/X-Team, I am starting at Google as of October 1st. I’m joining the Developer Relations team at Google to work on building a stronger web content ecosystem. In my new role I’ll be doing… many of the same things because I’m joining Google for the purpose of continuing to contribute to WordPress. While I have been doing that with the support of XWP, now I’ll be doing so with the backing of Google.

After working heavily on the WordPress 4.8 and 4.9 releases in 2017 (as well as previous core releases), I started transitioning a year ago to working on something very different. XWP started working with Google on a new phase for the AMP plugin and I led the engineering efforts. It was a refreshing change after years of working primarily on the Customizer: I realize now that I was on the verge of burnout at that time, and since we just did a major core release with Customizer improvements and because focus in core shifted fully to Gutenberg, I felt comfortable stepping away for a while to focus on AMP. After several months of working on AMP we then also started working on a PWA feature plugin which aims to bring progressive web app capabilities to core.

Working on AMP and PWA have felt like returning to my roots. Before XWP and before I was involved in WordPress even, I was really interested in open web standards. I contributed (with small acknowledgement) to the HTML5 spec by participating in the mailing list and creating a cross-browser implementation of Web Forms 2.0. I also created polyfills for CSS Transitions and CSS Gradients. I loved learning new cutting edge (progressive) technologies and then finding ways to implement them in projects, often requiring some creative solutions to get them to work in older browsers. (I used to take pride in my knowledge of IE6 workarounds.) I was an early adopter of Ajax, and I was an avid listener of the Audible Ajax podcast on the old Ajaxian blog; I loved that community that Ben and Dion created, and I loved contributing some things I hacked on. (Ben and Dion are both at Google now and I’ll be working in the Chrome team with them.)

My desire is to make as big an impact as possible. This is why I’m passionate about the open web. In publishing some project openly, I know that someone else can benefit from it and build upon it to make something new, just as I have benefited and built upon the projects of others. Everyone can contribute to building a better web. This is also a reason why I love WordPress: not only does it democratize publishing but it also democratizes development.

I’ve loved working at XWP because of our mission to build a better (open) web, and we have been doing so through WordPress. Over the years I’ve also been a big Google fan because of all they’ve done to invest in the open web. But I never thought that I’d get to work at Google, nor even that I’d want to. Nevertheless, this past year of working with Google has been a really great experience. I’ve been able to see first hand their commitment to the open web, and there was such a great alignment with XWP in having a shared mission to make it better. I’ve also been able to work with exciting technologies that serve toward this goal.

For many months I resisted the idea of applying at Google. I’ve invested many years working at  XWP and helping it to grow, and I have many relationships there which I value greatly. I’ve been able to contribute to building a better web at XWP and I could certainly continue to do so there. However, after Google I/O and WordCamp Europe I realized that at the current place in my career, I believe I’ll be able to grow more personally and have a greater impact if I start to contribute from Google while leveraging its support and resources. Additionally, there are others at XWP who can take my place and do more than I ever could to lead the company in technology and engineering; I have total confidence in them. While my relationships with XWPeople will change, they won’t end as I’ll be continuing to work with them on AMP, PWA, WordPress core, and other projects in the future. Read more about this new season for XWP.

So I’m going from working with Google to working at Google. For more see my Googler colleague Alberto Medina’s post about Web Content Ecosystems @ Google. I’ll be based out of Google’s Portland office so I’ll continue to be in PDX. I’m excited about this next chapter in my career and season in my life. Strangely enough, I’m really looking forward to taking TriMet and riding my bike each day to the office, as I’ve been working from home for the past 8 years (which I have loved, don’t get me wrong). But more so I’m looking forward to seeing how Google can build a better open web by investing in WordPress. I’m excited to be a part of it.

Customizer Features for WordPress 4.3 Kickoff

Here are the features I have suggested/proposed during the WordPress 4.3 kickoff:

Partial Refresh

This greatly improves performance of previewing changes in the Customizer for non-postMessage transport settings (JS-applied changes) by just refreshing the area of the page that has been changed. As such it eliminates some of the need to do postMessage in the first place, while also reducing the amount of duplicated logic that would have to be implemented in JS to mirror what is being done in PHP. This resurrects some code from the old Widget Customizer feature plugin developed for 3.9. Writeup and feature plugin are available.

Transactions

A low-level re-architecture of the Customizer plumbing that has a lot of side benefits and bugfixes, introducing some exciting possibilities for future feature plugins like scheduled settings, setting revisions, and drafted/pending settings. Partial Refresh is a dependency for this. Pull request available, but needs refresh. See proposal.

Concurrency/Locking

This is an important one for a client project I’m involved with, and so I’m having to prioritize it. I’m working on a client site that will have many users in the Customizer at a time, and given the way the Customizer is currently implemented (as with most areas of WP), there is no concurrency/locking support. So I’m working on adding locking at the control/setting level. See #31436.

(Cross-posted in comment.)

WordCamp Sydney talk: Customize all the things!

Today at WordCamp Sydney, I speak on The Customizer:

The Customizer is one of the least known yet most powerful features of WordPress. We need to get past thinking of it as the “Theme Customizer” which only good for tweaking colors and a limited number of settings. No, the Customizer provides a framework for live-previewing any change to WordPress.

In WordPress 3.9 I led development of incorporating Widget management to the Customizer, and I’d like to get on a soapbox to get people excited about developing their own custom controls for the Customizer.

Here’s my presentation:

I’m also happy that we at XWP (X-Team WP) and Stream are among the sponsors of the WordCamp:

Re: Edit WordPress Posts and Postmeta in the Customizer

I couldn’t reply to Jeff’s comment on Sarah’s WP Tavern post because of a Jetpack problem, so I’m posting it here:

With the Front-end Editor using the Customizer as a framework, I wonder if the interface will look similar to this experiment? I hope not.

This plugin is really a prototype to demonstrate how the Customizer can be used to preview changes to posts/postmeta at an architectural level. Hardly any consideration has been given to UI, which Avryl has been doing a great job with in her Front-end editor.

Ultimately, I’m interested to see how the Front-end Editor comes into play when previewing a post or writing a draft post. Will we be able to use it to write a post or will the editor be refrained from use until after a post/page is published?

You can use this Customize Posts plugin to edit drafts as well. Just create a new post post, save a draft, and then click Preview. You can then click Customize in the admin bar to then access that post from the Customizer and you can make changes, including transitioning the post draft to a published post. This relates to a previous prototype I worked on in the Customizer Everywhere plugin, which replaces the “Preview” button with a “Preview & Customize” button.

In this case and as I’ve seen mentioned already, editing should be done inline and not with boxes popping up around the content.

In terms of a prototype which demonstrates how inline editing can be added to the Customizer, see my other prototype: Customize Inline Editing.

Regularly cleaning up /tmp on a DreamHost VPS

I ran into a problem recently where I was no longer able to upload a file via PHP. I checked the server error log, and I saw entries like:

ModSecurity: Input filter: Failed writing X bytes to temporary file

Looking at my /tmp directory it contained 128MB of data. Apparently ModSecurity tries to prevent the filesystem from being maliciously filled up.

If you try to manually clean up just with a rm -rf /tmp/*, it will fail because the files are owned by dhapache and are not writable by anyone else. But, with DreamHost VPS, you have the ability to add admin users (aka sudoers). As an admin user, you can then set up a cron to automatically clear out the /tmp directory of old files:

su myadminuser
sudo crontab -e

Then in the editor which opens, add this line:

0 0 * * * find /tmp -mtime +5 -exec rm -rf {} \;

This will delete all files under /tmp which haven’t been modified in 5 days; it will happen every day at midnight.