An Introduction to Gutenberg’s Block Parser Class

The new WordPress block editor, more affectionately known as Gutenberg – is nothing short of amazing. The amount of effort that has gone into ongoing development prior to its launch in December of 2018 – as well as the efforts that have gone into it since then – are astounding.

More and more of our work at Zao these days includes customization of Gutenberg for our clients – especially clients who deal with a lot of content every day.

One of our more recent clients had a very specific need that stretched Gutenberg’s capacity – but thankfully, the block editor is designed to be stretched.

The content and editorial team wanted a special term list from a custom taxonomy to be displayed automatically, within the block content. The catch? They didn’t want to have to manually add it as its own block, and it wasn’t a simple task of adding it to a template file, as they wanted it to always be shown after the last paragraph (or “paragraph-like”) block – allowing for custom blocks to be rendered after this term list.

In the past, we would have had to consider shortcodes, telling the client “Sorry!”, or some really bizarre regex/DOMDocument hacking of the the_content filter. Thankfully, not with Gutenberg 😃

WordPress ships with a block parsing class, WP_Block_Parser. This class is passed through a filter called block_parser_class, which allows for very easy extension of this class. Let me show you how, in less than 100 lines of code, we were able to accomplish the task outlined above.

In the gist above, you can see that the first 20 lines are essentially us just overriding the core block parser with our own sub-class. The parse function is the primary function that WordPress uses when parsing blocks, so we need to override that to ensure we do what we are intending to do. Finally, the real work happens in parse_output. This is where we get our article tags, iterate through our blocks, and append the tags to appropriate block. You’ll note an important data structure reality here – each block has a representation of both innerContent and innerHTML. Replacing both is important here, and noting that innerHTML is an HTML string, while innerContent is an array of key-value pairs, where the value is generally the identical string, is the key to making this example work as intended.

As you can tell, the block parser class is a foundational part of how blocks are rendered with Gutenberg, and using it judiciously can be a really powerful way to achieve incredibly helpful editorial workflows.

Replacing a WordPress Layout with Gutenberg

We first wrote about Gutenberg over a year ago. My, how things have changed since then! As a random aside, since that previous blog post, it would appear that approximately 14 developer years have gone into the development of Gutenberg. A sum total of 22 years of effort. Amazing.

We’ve used Gutenberg on a number of different projects – experimenting with custom blocks, page building, and more generic content publishing. We’ve gotten familiar with the areas in which it’s still quite painful to use – as well as the areas where it shows a lot of potential. 

Not too long ago, I decided to live-tweet my experience converting an existing client’s homepage into a Gutenberg-ized home page.

Narrator: Lots of people were interested.

I won’t re-hash the entire Twitter thread. It was…long. Make yourself a cuppa tea and go give it a look, I’ll wait.

tl; dr: Rebuilding a layout in Gutenberg is totally doable, but not exactly for the faint of heart. We’re starting to get more and more of our clients asking us about Gutenberg – and specifically for this type of project. They’re really attracted to the promise of Gutenberg – standardized layout components that give them more control over their site and inch them closer towards a true WYSIWYG experience. (P.S. if that’s you, get in touch!)

So where does Gutenberg currently deliver on the promise and where does it fall short? Let’s start at the beginning.

The Beginning

I don’t think every site is a good candidate for this type of project. Not today, anyway. I’m comfortable saying that Gutenberg can be a great fit for projects that you start from scratch and may be a good fit for retro-fitting some projects. We felt comfortable using it on this particular project due to the fact that the existing homepage was fairly simple, and really already given to a block-based way of doing things. If it was a more complex home page – we may have given a second thought to the project.

In addition to it currently being well-suited (in my opinion) to fairly simple layouts, my experience was less than stellar when it came to getting the latest version of Gutenberg on the client’s site.

It ended up being due to a few different plugin conflicts – but I don’t know how in the world the average WordPress user who updates to WordPress 5.0 is going to know which plugin to deactivate to get back to their editor.

The Build

Once we got building, things went a bit more smoothly. I didn’t face many bugs per se – just a lot of things I wished were maybe a little more fleshed out, a little more powerful, a bit smoother to use, etc. A great example is the Cover Image block.

Cover Image Block

I think something like a Cover Image block is SUCH a common use case, that as a developer, I’d want it to be relatively flexible. As is, however, you can really just add a text/link and that’s it. I think headings, sub-headings, paragraphs, call-to-action buttons – those would all be very common uses for this type of block – but none of that is currently built into the Cover Image block. In the near future, for other similar projects we’re working on, we’ll likely just create custom blocks.

Columns Block

Another block we got a ton of use out of was the Columns block. Combining Columns and Cover Images allows our client to create really lovely landing pages for their product categories. Before Gutenberg, the client having this kind of power and control wasn’t feasible in WordPress without a separate custom page builder. 

The Columns block, however, was also not without its own limitations.

It would be pretty incredible if Gutenberg were able to detect the declared maximum width (for the alignwide class) and build a “grid” system of sorts, that you could drag columns and snap to the grid. The issue was pretty easy for me to fix, as a developer, but required some training for the client.

It’s pretty amazing, actually, how far many clients would be able to go in their own page building experience with just Columns, Cover Images, Media & Text, and Buttons. Four Gutenberg blocks and they’re able to accomplish 50% of the work they might have previously hired a web developer to do. This shouldn’t scare my fellow developers though – this frees us up to do work that is far more rewarding!

The Result?

The end result on this rebuild was ultimately a win for us (more exposure to the pain points and potential of Gutenberg is a good thing for us, and our clients!) and our client. I’ll let Molly, of Ro Sham Beaux, tell you herself:

Gutenberg has given our team the ability to take our website into our own hands. Working on a website can be extremely daunting when everything is created in code and as a consumer, you have limited access to the changes you are able to make. With the new power builder, our team has access to creating new pages, changing out images, adding links to other pages and creating a more integrated website without contacting a qualified developer. This will help us grow our online presence as we can easily swap out photos, text and links to post online sales or introduce new product collections.

The accessibility and ease of Gutenberg has opened the possibilities of what we are able to create with our site. Our business is constantly changing and the resources we need to provide our customers with online must always be updating. Having the access to design and create customized pages on our site will be such an asset moving forward

Molly Moore, Ro Sham Beaux

We’re excited about the future of WordPress and Gutenberg. As it continues to mature, it’s going to a massive help to content publishers everywhere, and our clients will continue to reap the benefits of a re-imagined publishing interface.

Want to bring your website into the future of WordPress? Get in touch!

A 10X eCommerce Search Experience

Recently, one of our favorite clients reached out to us because they were facing some significant issues with their online eCommerce search experience.  Searches were irrelevant and non-performant, faceting worked sometimes, but slowly, and simple things like exporting or paginating results failed miserably. 

The previous technology stack that was implemented included 3-4 disparate systems (WordPress / WooCommerce, FacetWP, DataTables), none of which effectively communicated to each other. The result was an experience that felt like a Frankenstein-mismatched-mashup of components and the overall UX (user experience) was sub-par, to say the least. Our technical challenges were not insignificant:

  1. Research and determine the best technical platform to act as a single source of truth for the entire search experience.
  2. Document existing functionality and prioritize feature parity.
  3. Implement and test new system against feature parity matrix, measuring for key heuristics like speed, search relevance, and the experience feeling fully internally integrated. 

The Best Technical Platform

Arguably the most important decision – this was also the easiest decision. Because of the fact that our client wisely chose to host their eCommerce site at Liquid Web with their new Managed WooCommerce product, we already had tight integration with Algolia for their site search results. Carrying that over to the faceted search experience was a natural evolution of this feature. Not everyone who uses Algolia is aware of this, but they provide more than just insanely fast search (via their Autocomplete and InstantSearch libraries, which Liquid Web leverages). In fact, their faceted search experience is just as fast as their normal autocomplete search – and it’s so much more powerful. Because they provide all of this power, and it was already available to us – using Algolia was a no-brainer.

What Exactly is Faceting?

Great question! You’ve likely already used a faceted search experience if you’ve ever shopped at Amazon. When you search for something, and it shows you different prices, review, categories, or other areas to “drill down” by? That’s faceting. Here’s a simple example:

Choosing the Right Framework

Having decided upon Algolia as our platform of choice – we had another important choice to make. We were completely replacing the entire user experience here, so there was a strong case to be made in replacing the existing patchwork with something built upon a more maintainable framework. Already set on leveraging the InstantSearch.js library from Algolia, using a JavaScript framework for the new interface made a lot of sense to us. Having worked with most modern JavaScript UI libraries – we settled on using Vue.JS. We found it to be more opinionated than Backbone.JS, more progressive than Ember and Angular, and easier to work with than React. We were delighted to find that Algolia already had great support for Vue.JS via their GitHub repos.

Well-Tested or Robust?

Our final platform-level challenge came after reviewing the aforementioned Vue.JS + Algolia starter interface. We realized quickly that the level of integration between Algolia and Vue.JS in their v1 public release was insufficient. Upon some quick investigation of open branches and pull requests against the repo, we realized that they were deep into active development on v2 of their integration – and v2 was much more powerful. Making a difficult decision between using something more battle-tested, but not nearly robust enough – or something that was still in active development, but potentially a much better long-term foundation – we made the tough call of investing in the future, potential bugs and all – we went with v2.

Finally, after making our way through the foundational project decisions, we were ready to get into the weeds and tackle building out a new interface. The first step for us here was not writing code, but writing lots and lots of words to document existing functionality.

Feature Parity

When you’re completely rebuilding something from scratch, it’s easy to sometimes miss the forest for the trees. As developers, we can become so enamored with the new and shiny that we forget that our only goal is to solve our client’s problems. If we’re not doing that, we’re failing. While much of the existing interface was broken in a lot of interesting ways – there was a lot that it was doing effectively. 

In order to make sure that we not only fixed what was broken, but didn’t break what worked well – we need to document every feature of a system that was completely undocumented, and which we had very little initial involvement in building. Due to our collaborative approach to technical partnership with our clients, we were able to work together with our client to identify everything the existing system was doing, prioritize the features, and ensure that we were able to execute everything that existed previously in the new system.

Our only goal is to solve our client’s problems. If we’re not doing that, we’re failing.

While it may sound like a simple experiment to document existing features – this exercise exposed areas of potential complexity that were hidden in plain sight. One great example of this was sorting the table of product results. Each category of products had a default sorting algorithm applied to the results that were unique to that category. In the previous system, driven by a MySQL database, sorting was a fairly straight-forward (although, in this instance, a very broken) process.

A Different Paradigm

With Algolia – while it’s tempting to carry over database-driven paradigms – it’s not a database. It’s a search index. While there is some overlap carried into this paradigm – sorting is not one of those. Where we could sort by a given column in a table in the previous interface, in the new interface, we had to create a new replica index for every column we wanted to sort by. This meant creating over 30 replica indexes and using Algolia’s API to determine which index to use when sorting. 

In the end, we ended up with a task list of nearly one hundred features to maintain parity with. This included (but was definitely not limited to):

  • Default sort order for results, per category
  • Custom facets and facet order per category
  • Custom columns in the tabular results, per category
  • Integrated CSV export (we used the great json2csv package for this)
  • A built-from-scratch mobile/responsive experience, imitating the existing experience driven by WooCommerce Product Tables and dataTables.js. We used Vue-MQ for this.

Risk Assessment 

Finally, the fact that we used alpha software was ultimately a net win, but that doesn’t mean it wasn’t without challenges. The v1 package was well-documented – while the v2 package was mature in many ways, documentation was not one of them. In recent days (and even hours), they’ve made great progress on documentation – but we were flying blind for a good amount of the work we completed.

This introduced a number of roadblocks along the way – but we can’t possibly say enough wonderful things about the developer support from the folks at Algolia. They were massively helpful – with every documentation question, issue logged, support request, etc – they went above and beyond to help and even improve their alpha releases based on our feedback.


Now that we had a clear technical specification to build from; we had to take the decisions we made, the knowledge we had, and the risks we were assuming — and put them all into practice. A project of this magnitude is bound to produce no small amount of hills to climb. Rather than outline every step of the implementation, I’ll share a couple of the challenges we faced and how we overcame them.

Numeric Indexing

I mentioned this briefly earlier: Algolia has a very different architectural paradigm than a MySQL database. It’s a search index, which means it works differently than a standard RDBS. One of the things Algolia is very good at, which the existing implementation was not executing well at all, is sorting by just about anything in the dataset.

“Anything” – in our case, often meant large datasets, sorted by a number. Unfortunately, the way that the existing WooCommerce Algolia plugin works, it’s not possible to have a taxonomy that is comprised entirely of numeric terms to be indexed numerically. In laymen’s terms, that means that where you might expect results to be sorted naturally like 1, 5, 12, 18, 25, 32, 85, 100 – they would instead be sorted like so:1, 12, 18, 100, 25, 32, 5, 85 Not exactly helpful.

In order to fix this, we were able to use an existing filter within the WooCommerce / Algolia plugin to ensure that numeric strings were sent to Algolia as numbers, rather than strings:

function algolia_numeric_index( array $attributes, WP_Post $post ) {
    $product = wc_get_product( $post );

    if ( ! $product ) {
        return $attributes;

	foreach ( $attributes['taxonomies'] as $taxonomy => $terms ) {
		foreach ( $terms as $index => $term ) {
			if ( is_numeric( $term ) ) {
				$attributes['taxonomies'][ $taxonomy ][ $index ] = (float) $attributes['taxonomies'][ $taxonomy ][ $index ];

    return $attributes;

add_filter( 'algolia_post_product_shared_attributes'           , 'algolia_numeric_index', 10, 2 );
add_filter( 'algolia_searchable_post_product_shared_attributes', 'algolia_numeric_index', 10, 2 );

This simple fix allowed us to fix a number of broken indexes, ensuring the sorting experience for users and for our client worked really smoothly. 

Integrating with WooCommerce…and everything else

While this new experience was being built as its own self-contained Vue.JS app – we still needed it to integrate to other parts of the site. The site navigation, driven by WordPress, needed to dictate to the Algolia facets which category should be shown. The app needed to be able to add items to the cart via WooCommerce. Thankfully, these problems were fairly easy to solve.

For integrating the menu items, and specifically clicking them, into the Vue app – we assigned the app to a global variable and emitted events against that scope when the menu items were clicked:

window.zaoAlgoliaApp = new Vue({
  el: '#zao-algolia-app',
  render: h => h(App)

var menuItems = document.querySelectorAll( '#top-category-menu .items' );

for (var i = 0; i < menuItems.length; i++) {
	menuItems[i].addEventListener('click', function(event) {
		window.zaoAlgoliaApp.$emit( 'menuItemClicked', this.href );

This simple approach made it relatively straight-forward to listen for these events within the app and route the requests and refine the facets accordingly. 

For the ability to add results to the WooCommerce cart, we created a small Add to Cart component that mimicked the standard WooCommerce Add to Cart button. Passing the Algolia item along as a property made this effort fairly inconsequential:

	<form autocomplete="off" v-if="this.item.in_stock" :action="formActionUrl" class="cart" method="post" enctype="multipart/form-data">
		<div class="quantity">
			<label class="screen-reader-text" :for="getPostId">Quantity</label>
			<input autocomplete="off" type="number" :id="getPostId" class="input-text qty text" step="1" min="0" max="" name="quantity" value="1" title="Qty" size="4" pattern="[0-9]*" inputmode="numeric" aria-labelledby="">
		<button type="submit" @click="addToCart( $event )" class="button alt add_to_cart_button ajax_add_to_cart" style="outline: none;">Add</button>
	<span v-else>Out of stock</span>

export default {
	props: [ 'item' ],
	name : 'WCAddToCart',
	methods : {
		deleteMessages() {
			jQuery( '.woocommerce-messages' ).fadeOut().remove();
		addToCart( e ) {
			var $ = jQuery;
			var $thisbutton = $( );
			var item = this;



			$thisbutton.removeClass( 'added' );
			$thisbutton.addClass( 'loading' );

			var data = { sku : this.item.sku, product_id : this.item.post_id };

			// Trigger event.
			$( document.body ).trigger( 'adding_to_cart', [ $thisbutton, data ] );

			// Ajax action.
			$.post( wc_add_to_cart_params.wc_ajax_url.toString().replace( '%%endpoint%%', 'add_to_cart' ), data, function( response ) {

				if ( ! response ) {

				document.querySelector( 'header.woocommerce-products-header' ).insertAdjacentHTML( 'afterend', response.fragments.messages.replace( 'Continue shopping', 'View Cart' ).replace( window.location.href, wc_add_to_cart_params.cart_url ));

				setTimeout( function() {
				}, 5000 );

	computed: {
		formActionUrl() {
			return window.location.pathname + '?add-to-cart=' + this.item.post_id;
		getPostId() {
			return 'quantity_' + this.item.post_id;

The Results

Remember – our metric of success is not about lines of code (~1,000), not about how much fun we had with development challenges (a lot) or how fancy and shiny the frameworks we used are (so fancy, so shiny) – it’s about solving the client’s problems.

To reiterate: 

  1. Slowness – Pages would reload anytime categories were changed, anytime breakpoints were triggered (via portrait to landscape changes, browser resizing, etc.), any time searches were performed, or facets were selected. This added 1-2 seconds of load time for almost every interface interaction.
  2. Accuracy – Pagination would always show links for pages for the entire dataset, and result counts for the entire dataset, not just for the filtered set. Sorting would only sort current page, not the entire set. Exports would not take into account filters or search queries. Filtering by one facet would inconsistently affect other facets. 
  3. Overall experience – UX for facets was clunky, everything was slower than expected, the entire experience did not feel well-integrated.

So – did we fix it?

  1. Slowness – the interactions in the previous experience would often take a minimum of 500ms, with an approximate upper boundary around 2500ms. With Algolia powering everything – from the export, to the searching, to the faceting, to the sorting and pagination – the average interaction is essentially imperceptible – between 1 and 80ms, averaging around 30-40ms. This represents a minimum improvement of around 10x – but comparing experiences, it feels like 100x. 
  2. Accuracy – one of the more powerful elements of Algolia is just how accurate it can be. Not all accuracy is created equally.  For example – when a user searches for model numbers, we have little to no typo tolerance, as they’re searching for a very specific number, and any fuzziness would be likely to return irrelevant results. However, if they’re searching for a color or material – typing Blak or Sliver or Lether should return the relevant results – typos and all! Thanks to Algolia’s powerful customizable ranking algorithms, this is exactly how the new interface works. On top of all of that – the primary issues they were facing with exporting, searching, sorting and filtering were all easily resolved.
  3. Overall UX – in any UX, it’s easy to get weighed down in numbers and metrics – but at the end of the day, how it feels is what matters most. The magic of a completely rebuilt app in a modern JavaScript framework, on top of a lightning-fast service like Algolia cannot be overstated. Taking a core user experience from being painful to powerful, from janky to joyful – this is why we do what we do 🤗

But Wait, There’s More!

In addition to these goals that were very much a matter of execution – we’re also very attuned to our client’s strategic goals. As a bootstrapped startup, two things are eminently important for this client: 1) Keeping expenses low 2) Getting as much actionable data as possible.

To this end, our client wanted a way to be able to gather some data around how people were searching, filtering, paginating, etc. For example – to be able to track when a person types a search into the search input. and they have to click a pagination link to find the result. That gives some helpful insights into how to make search results more relevant for users.

The only problem is that Algolia makes this type of insight available – but it’s at a pricing tier that costs more than ten times as much as they were already paying. Being aware of these conflicting constraints, we got creative.

We were already using Heap Analytics for tracking data on their site. Creating custom events for faceting, paginating, searching (and a small number of other actions) using Heap’s Event Visualizer established a quick, easy way to gather this actionable insight – at no additional cost to our client. Wins all around!

If you’re reading this, wondering to yourself, “Wow, I have some of the same problems with our website – can these folks help me?” – we’d be honored to hear how we can serve you. Fill out the form below and get in touch.

WordPress web development, WordPress eCommerce development, WordPress plugin development, hire a WordPress developer

Getting to Know Zao: Our Founder, Justin Sainton

One of the cornerstones of how Zao works is the way we prioritize collaboration. We build long-term partnerships with our clients, rather than acting as one-off vendors. We’re invested in their success, and build technology that lays a foundation for them to meet their business goals.

Since we work so closely with our clients, we thought it important that you know who we are. Here’s the first part of a series introducing our team, starting with our founder, Justin Sainton.

Continue Reading

#WooConf 2017 Recap

I had the opportunity to attend WooConf 2017 in Seattle last week. Thankfully, Seattle is just a stone’s throw from my backyard (a three-hour-drive stone’s throw, but a stone’s throw nonetheless). After a brief road-trip up I-5, getting settled into an Airbnb with some random stranger, and getting a good night’s rest, we were ready to rock and roll.

Continue Reading

WordPress, Gutenberg Project, WordPress editor, WordPress thought leaders, WordPress thoughts, WordPress professionals

My Thoughts on Gutenberg

We’re in an incredibly exciting time in the development of WordPress as a platform: the REST API is in core, we’re imagining a new JavaScript-driven future for WordPress, and we’re in the early stages of development of a new editor for WordPress, Gutenberg.

As one might expect, anytime major changes happen in open source software, hot takes abound! While my take isn’t necessarily as hot (I highly recommend each of those posts!), I’d like to share some of my observations on the community reaction to the process of introducing Gutenberg to WordPress.

This post is not a feature-by-feature review of Gutenberg. Any of the posts linked to above do a far better job of that than I could hope to. Rather, I’d like to explore the general sense of animus this project has seemed to introduce into our community – and if possible, I’d like to explore that without pointing any fingers.

Continue Reading

WordCamp Sacramento 2017, WordCamps, WordCamps 2017, WordCamps west coast, WordPress events, WordPress conferences

Learn How to Extend WooCommerce at WordCamp Sacramento 2017

I’m excited to announce I’ll be speaking at WordCamp Sacramento 2017, which means I’ll be headed to the golden state this coming weekend.

The line up this year looks absolutely amazing. I’m honored to be presenting alongside such a great group, and connect with the WordPress community in the flesh!

Here are a few select sessions I’m especially looking forward to:

There are so many that sound fantastic that it was hard to pick.

As for me, I’ll be presenting on how WordPress developers can extend and improve WooCommerce. Zao heavily focuses on and specializes in eCommerce development in WordPress, and I’m excited to bring what we’ve learned to other developers. My presentation is on Sunday, September 17th, at 1:30 PM, so I hope I’ll see you there!

Are you headed to WordCamp Sacramento too? Make sure to introduce yourself if we haven’t met before (and obviously say hi if we have)!

Using the WooCommerce API with wp-api.js

As of WordPress 4.7, we’ve had a really fantastic, fully featured REST API in WordPress. It is relatively well-known that the infrastructure for the API was introduced in WordPress 4.4, with the content endpoints being introduced in 4.7.

What is somewhat less well-known is that 4.7 also shipped with a Backbone.js client you can use to interface with the core API.  It’s super simple to enqueue:

wp_enqueue_script( 'wp-api' );

Using it for core objects is pretty straight-forward:

var post - new wp.api.models.Post( { id : 2 } );
alert( post.attributes.title.rendered ); // Renders "rendered" title of post.

But what if you want to use it with non-core objects that are in custom namespaces, or maybe not even on your own site? Thinking that you’ll probably have to write some PHP, maybe your own library or framework for interfacing with these, and your own JS models? Ugh, amirite?

Good news! None of that is necessary.

Continue Reading

WordPress economy, WordPress business, WordPress web development, WordPress jobs, WordPress developer jobs,

The WordPress Economy is Changing, and Zao Is Ready For It

Not too long ago, Post Status’ newsletter covering Rainmaker’s move from a SaaS product model to a service-only model served as the catalyst for a lot of conversation on Twitter. We saw the esteemed Brad Williams tweet this thought about the WordPress economy:

And it sparked a conversation in the Zao Slack about the WordPress economy and how this impacts us, too.

Continue Reading

Zao Grows: Lizz Ehrenpreis Joins Zao as Project Manager

Founder’s Note: Sometimes, you have a role and need to find a person to fill it. Other times, exceedingly rare times, you find a person and decide you need to make a role for them.

We’re so excited to welcome Lizz Ehrenpreis to Zao as our newest team member. Bringing Lizz into our Zao family is a great example of the latter scenario. After working with her on a contract basis for a few months, we knew she needed to be a more formal part of Team Zao. Her work for an array of incredible clients speaks for itself, not to mention her time at one of our favorite agencies, WDS.

She’ll be spending her time with us primarily as a content strategist and project manager, and we’re so lucky to have her. Welcome to Zao, Lizz!

Hi! I’m Lizz Ehrenpreis. If you’ve been paying attention to Zao, you’ve seen me around these parts, writin’ posts and whatnot. I’ve been a contract Content Manager for Zao since November, helping the Zao team level up their blogging and working behind the scenes on enhancing internal documents.

If you don’t know me from Zao, you may know me from my time as WebDevStudios’ Client Communications Specialist, or from working with a variety of small to mid-sized businesses, many of which are well-known in the WordPress sphere. When I’m not click-clacking away at my computer, you can find me chilling with my two goofy cats, sipping on a sparkling water while reading a book, or tromping around the West Coast like I own it.

Although I’ve already been working with the Zao team, I’ve officially started in a new capacity: I’m no longer just a content maven–now I’m a Project Manager! I’m excited to be moving into this new role and working more closely with the Zao team, who consistently produce incredible work, as well as integrate their company values into everything they do. Their generosity of spirit, kindness, transparency, and collective work ethic is unparalleled, and I’m all too jazzed to be joining the group in a more official capacity.

You’ll still be seeing many more posts from me, although the topic matter may become more diverse as time goes on as I’m about to dive into Louder Than Ten’s Project Management Apprenticeship and learn as I go with the Zao team.

If you want to find out more about me, you can check out my website, follow me on Twitter, or creep me on LinkedIn.

Also, it’s my personal duty to remind you to like Zao on Facebook.

That’s all, folks! See you around the Zao-o-whirl!