Automattic Women: Rossana Menezes

Welcome to Automattic Women—conversations with some of the remarkable women working all over the world to design and develop Automattic software and make the web a better place. Today’s interviewee, Developer Apprenticeship Rossana Menezes, chats with us from her traveling workstation somewhere around the globe.

Who are you, and what do you do?

Automattician Rossana Menezes

At Automattic, I started as a Happiness Engineer in 2017 and am now part of the Developer Apprenticeship Program, an internal pathway into core engineering roles here. I spent one year preparing to apply, working with a mentor, and in January I started as an Android Developer Apprentice working in the WooCommerce mobile team.

The apprenticeship works as a rotation. You are placed in one of our engineering teams across the company and will work full-time on that team for approximately 12 months. The focus of the program is on learning. While you need to have a certain level of programming knowledge to join, the idea is to prepare you to move to a developer role at the end. This has been an amazing experience so far. I am learning so much while also being able to contribute to the WooCommerce mobile app and help our users to manage their stores on the go. 

What’s a typical day like for you?

The best thing about working here is that there is no typical day if that’s what you want. Work-wise, a typical day starts by waking up around 5:00 am, because I am a morning person, and I can work whenever is best for me. So I wake up early, make some good coffee and open my computer to check Slack pings, P2 posts and any notifications on Github. 

Then, I spend about 5 to 10 minutes organizing my day. I use an app called Noteplan 3 that is connected to my Google Calendar, so I can add notes, and have my calendar on the same app. I add a to-do list for that day and as the day goes by and I work on the things I had planned I mark the items on my list as complete, sometimes add more items as they come up. 

Rossana and friends enjoy off-road biking.

With planning out of the way, I start my deep-focus time. It can be either working on a project I am currently assigned to, working on our backlog tickets on Github, reviewing a Pull Request, or focusing on studying something, since learning is a big part of the Apprentice program. I’ve created a blog where I share the things I’m studying.

I started studying programming using Java for a short time and then moved to Kotlin and found it a bit hard to go through its documentation. I felt that everything related to Kotlin was very focused on experienced Java developers, which was definitely not my case. So I  try to post about the things I’m learning using a beginner-friendly approach. 

Depending on the day, I might have a few Zoom meetings too, like 1:1 with my team lead every other Friday, team meeting every two weeks, paired programming sessions with one of my teammates, or group coaching sessions with the other apprentices in my cohort. 

And the best part is being able to do all that from my home office, from the nice coffee house downtown, from the boarding gate while I wait for my flight to Norway to visit my family, or from a super cute restaurant I found while walking around in Carcassonne, France. 

Depending on where I am, my day looks completely different. If I’m home, I usually work from 5:30 am to noon, when I have a break to exercise, eat, and run some errands. Then I go back to work for a couple of hours and work on things that are not necessarily related to coding. So if I need to write a P2 post, work on documentation, or test the app, I do that in the afternoon.

If I am traveling, I usually prefer to work without a long break, so I can finish early and explore the area.

By the sea, by the sea, by the beautiful sea…

What drew you to Automattic and what keeps you here?

What drew me here was the ability to work remotely. I have family in Brazil and Norway—and being able to work while I visit them made a huge difference in my quality of life. I am able to be in Norway for my nieces’ birthdays, spending the holidays with them or with my family in Brazil. I get to travel the world while I work, and this is amazing because traveling is one of my favorite things.

That said, what keeps me here is the company’s culture. Automattic walks the talk. Our creed is not just a bunch of words put together to make the company look nice. It is taken seriously. People here truly care about helping others, creating things that will help our users, and making the web more accessible and a better place in general. And I think because of that, the most amazing people are drawn here.

I work every day with a wonderful group of super smart and kind people who are willing to jump in and help anyone at any time. Also, here you feel that you matter as an employee. We are heard, we are respected, and we are supported and encouraged to grow. You have the freedom and autonomy necessary to balance work and personal life the way it works best for you.

What’s your favorite non-work activity?

Traveling, exploring new places, trying new food, and taking pictures of exciting things. 


That’s it for this edition of Automattic Women. Follow Developer Resources and Automattic Design to meet more wonderful women of Automattic. And if you’d like to do more than just read about these great folks, consider working with us!

Automattic Women: Josepha Haden Chomphosy

Welcome to Automattic Women—conversations with some of the remarkable women working all over the world to design and develop Automattic software and make the web a better place. Today’s interviewee, community steward Josepha Haden Chomphosy, chats with us from her home workstation in California.

“This photo is of my favorite pre-COVID workstations—on the floor at WordCamp.”

Who are you, and what do you do? 

Within Automattic, I lead our open source practice which means my work is a bit of tactics, a lot of strategy, and full-time leadership training and support. Outside of Automattic, I lead the WordPress open source project and that work is a lot of short-term coordination of projects and long-term planning for WordPress’s success.

What’s a typical day like for you?

My days typically start out with Zoom meetings (and lots of coffee) so that I can get as much work unblocked for folks as possible. My afternoons tend to mostly be “desk time,” where I focus on text-based work, especially in the WordPress project and community itself—posts, goals, budgets, decisions—all the back-office things that make the world go ‘round.

“This one is of me running away from a goat that I just petted. I get very excited about goats, otters, and alpacas.”

What drew you to Automattic and what keeps you here?

I was originally drawn to Automattic because working as a sponsored contributor in the WordPress project was a dream come true. I had the chance to take the life-changing experience of discovering WordPress and learning to work with it, and offer that knowledge to others. What keeps me here is naturally the people that I’ve been so privileged to work with over the years, but also the fact that I routinely get to empower others through work that I find meaningful and a CMS that I have used for more than a decade.

What’s your favorite guilty pleasure?

I don’t know how guilty it is, but I spend a lot of time trying to recreate favorite foods from restaurants I’ve been to during my travels. From “best salad” to “best oatmeal,” I’ve tried and failed infinite times on my way to success. But isn’t that the best part of cooking anyway? Taking a bunch of things that are good on their own and combining them until they’re something wholly new and perfect in a totally different way?


That’s it for this edition of Automattic Women. Follow Developer Resources and Automattic Design to meet more wonderful women of Automattic. And if you’d like to do more than just read about these great folks, consider working with us!

WordPress Plugin i18n, Webpack, and Composer

By: Brad Jorsch

A lot of work has been going on in the Jetpack plugin lately. We have UIs built in React, with the JavaScript bundles being created by Webpack. We have Composer packages used for code sharing, increasingly so as we look into creating standalone plugins like Jetpack Backup and Jetpack Search. And we want everything to be translated for people who speak languages other than English.

A few months back we started getting reports that some translations in Jetpack had gone missing. As we looked into it, we eventually found no fewer than six different ways that translation was broken!

  1. JavaScript bundles weren’t being scanned due to bad file naming.
  2. Webpack’s optimizations were breaking the i18n function calls so WordPress.org’s translation infrastructure couldn’t find them.
  3. Lazy-loaded Webpack bundles weren’t lazy-loading translation data.
  4. Shared React component translations didn’t work in plugins other than Jetpack itself.
  5. Bundled Composer packages weren’t being scanned.
  6. Composer package translations didn’t work in plugins other than Jetpack itself.

It took us a few months, but we’ve now fixed them all. This post will describe how we did it.

Background: How plugins get translated

The recommended way to have your plugin translated is to let WordPress.org extract the translatable strings from your plugin, then build language packs for you based on the work of volunteer translators.

In your code, both PHP and JavaScript, you pass translatable strings to functions such as __()_x(), and so on. When that code is uploaded to WordPress.org SVN, it gets scanned for these calls. The strings for each call are collected and passed into the GlotPress installation at translate.wordpress.org, where volunteers translate them into various languages. The translations are later collected into language packs, which can be downloaded and installed into WordPress so people can experience your plugin in their own language.

(Aside: The extraction is part of the WP-CLI tool: wp i18n make-pot. They use the --slug and --ignore-domain options. Generation of JavaScript translation files is done in a manner similar to wp i18n make-json, but skipping any JS files in a src/ directory)

The extracted strings are all associated with a “text domain” matching your plugin’s slug. If the domain parameter passed to __() and so on doesn’t match, your translations won’t be found at runtime.

All this makes some assumptions about your code, some of which turned out not to be true for the way we were doing things in Jetpack.

Problem 1: JavaScript bundle naming

When we dropped support for Internet Explorer 11 in our JavaScript, Babel stopped transpiling modern syntax such as template strings into an ES5 form that IE11 could understand. This then broke when we deployed to WordPress.com, as that environment automatically applies it own minifier to JavaScript and CSS while serving it and their minifier doesn’t understand template strings either. WordPress.com doesn’t apply its minifier if the files are named like “bundle.min.js”, so we renamed our files like that.

But that ran into one of the WordPress.org translation infrastructure’s assumptions: they assume any “bundle.min.js” can be ignored because it will have a corresponding “bundle.js” next to it. 😬

We didn’t want to include several hundred K of non-minified JS in Jetpack though. Jetpack already has an undeserved reputation for being “bloated”, and the extra files wouldn’t help even if the non-minified JS is never used.

Solution: The URL passed to wp_register_script() can include a query part, and WordPress.com’s minifier can also be bypassed by including minify=false in the query part.

Then we took it a step further. The registration of a Webpack bundle usually involves a fair bit of boilerplate since you also need to read the information produced by @wordpress/dependency-extraction-webpack-plugin and often register some CSS too, something like

$relative_to = __FILE__; // Or something.
$assets = require dirname( $relative_to ) . '/build/bundle.asset.php';
wp_register_script(
    'handle',
    plugin_url( 'build/bundle.js', $relative_to ), // TODO: Add "?minify=false".
    $assets['dependencies'],
    $assets['version']
);
wp_set_script_translations( 'handle', 'textdomain' );
wp_register_style(
    'handle',
    plugin_url( is_rtl() ? 'build/bundle.rtl.css' : 'build/bundle.css', $relative_to ),
    array( /* Some other dependencies? */ ),
    $assets['version']
);

So we added a method in our automattic/jetpack-assets Composer package to handle all that in an easier way. And we can have it perform some simple checks, like requiring that a textdomain be given if the dependencies include wp-i18n.

Assets::register_script( 'handle', 'build/bundle.js', __FILE__, array( 'textdomain' => 'domain' ) );

Problem 2: Webpack optimization breaking i18n function calls

The extraction of translatable strings from JavaScript depends on seeing the call to a function or method named __()_x()_n(), or _nx(), with the various parameters being passed as literal strings. These calls may be preceded by a “translator comment” which is also extracted.

In its default configuration, Webpack in production mode is likely to rename these functions to single-character names and to throw away those translator comments. And even if it’s working now, a changed configuration or a new code pattern might break it in the future (as happened to us when we updated to Webpack 5). 😬

Solution, part 1: The first step was to figure out the necessary configuration to preserve the i18n function calls and the translator comments.

  • Set Webpack’s .optimization.concatenateModules false, as the concatenation sometimes winds up renaming the methods.
  • Instead of relying on Webpack’s default configuration for Terser, supply (via .optimization.minimizer) an instance of terser-webpack-plugin configured to preserve the calls and comments.
    • .terserOptions.mangle.reserved set to reserve the four methods.
    • .terserOptions.format.comments set to a callback that identifies translator comments.
    • .extractComments set to a callback that identifies the license comments Terser preserves by default, which will now be extracted to a separate file instead to reduce the size of the bundle.
  • We also included Calypso’s @automattic/babel-plugin-preserve-i18n plugin to further help preserve the i18n method names.

Solution, part 2: To address the “even if it’s working now, it might break later” problem, and to help identify coding patterns that can break the i18n method calls even with the above configuration, we created @automattic/i18n-check-webpack-plugin. This plugin extracts the strings from the original sources and the output bundle to compare them and see if anything seems to have gone missing, so if something breaks it’ll make the build fail instead of having to wait for someone to notice the broken i18n and report it.

The documentation for the check plugin includes some known problematic code patterns and fixes for them.

Problem 3: Lazy-loaded Webpack bundles

For “entry” bundles, Webpack expects your HTML to include any additional files (e.g. CSS extracted by mini-css-extract-plugin) yourself. In a WordPress plugin this is fairly straightforward to do from PHP (and we made it even easier for ourselves using automattic/jetpack-assets as described above), and that includes loading of the appropriate translation data into @wordpress/i18n.

But if you use code like import( /* webpackChunkName: "async" */ './something' ), Webpack will create a “lazy-loaded” bundle that isn’t loaded until that import() call is executed. In Jetpack we have one of these in the Instant Search module. For such lazy-loaded bundles the Webpack runtime knows how to load the extracted CSS, but it knows nothing about WordPress translation data. 😬

When we looked around we saw that Calypso had a fairly complicated solution in their code, a generic hook added in the Webpack runtime and specific code to load data when that hook fired. Woo had tried to adapt that but gave up in favor of tricking WordPress into loading the lazy bundle’s translations non-lazily. Neither solution appealed.

Solution: We created @automattic/i18n-loader-webpack-plugin to teach Webpack how to load the WordPress translation data. It’s designed to work in concert with @wordpress/dependency-extraction-webpack-plugin and automattic/jetpack-assets: when i18n-loader encounters a bundle that can lazy-load other bundles that use @wordpress/i18n, it will register a dependency on a “@wordpress/jp-i18n-state” module via the former that’s provided by the latter. The state data lets the Webpack runtime inside the bundle know how to locate the translation data, which it will then download and register with @wordpress/i18n during the lazy-loading process.

Problem 4: Text domains in shared React components

As part of the “Jetpack RNA” project, we’ve begun creating React components that can be shared by multiple plugins, like our own Jetpack Backup and Jetpack Search plugins.

But remember how the __() call needs to specify a domain, which is supposed to be a constant string (not a variable) and must match the plugin’s slug? 😬

Solution: We created @automattic/babel-plugin-replace-textdomain, a simple Babel plugin to rewrite the domains as the components are being bundled.

Problem 5: Bundled Composer packages being skipped

WordPress core doesn’t really use Composer; they have a composer.json, but just to pull in PHPUnit and a few other development tools. Where WordPress core needs libraries at runtime, they copy them in statically. Plugins either do the same or include Composer’s vendor/ directory in the code checked into WordPress.org SVN.

The WordPress.org translation infrastructure assumes that anything in vendor/ either has no translations or has its own translation mechanism entirely, instead of intending to use WordPress’s. (Although since __() and such would be defined by WordPress rather than the plugin, I’m not sure how that’s intended to work.) In our case, we do really want these packages’ strings included in the plugin’s language pack. 😬

Solution: Composer allows for custom installer plugins, which can install packages into different locations based on the “type” field in the package’s composer.json. We created automattic/jetpack-composer-plugin that installs “jetpack-library” packages into jetpack_vendor/, and set the types of the relevant packages to “jetpack-library”.

Problem 6: Text domains in Composer packages

As with the shared React components, the bundled Composer packages need to be using the plugin’s text domain because that’s where the translations are going to be. And this time we’re not compiling them into a bundle, so a compile-time replacer wouldn’t work. 😬

Solution: The solution here comes in several parts.

  1. We have automattic/jetpack-composer-plugin write an “i18n-map.php” file into jetpack_vendor/, collecting the WordPress plugin’s slug (set in its composer.json) and each package’s textdomain and version (from their composer.jsons).
  2. The WordPress plugin passes that file to automattic/jetpack-assets, which determines the mapping from each package’s domain to an appropriate plugin’s.
  3. Assets hooks into __() and such to try the plugin’s domain if no translation was found for the package’s. It also hooks into the script translation file loader to point to the script translation files included with the plugin’s language pack instead of the nonexistent packs for the packages’ text domains. And finally it includes the mapping in the state data for @automattic/i18n-loader-webpack-plugin so that can load the correct file for any lazy-loaded bundles.

We also made sure that our monorepo’s CI checks would catch common cases where developers might wind up with wrong text domains, using existing linting rules from @wordpress/eslint-plugin and wp-coding-standards/wpcs and custom checks to verify those rules’ configurations are in sync with each other and with composer.json.

If WordPress Core were to take on this problem, I think they could do it a bit better:

  1. Switch the translation infrastructure from being based on plugins and themes (which all use the plugin or theme slug as the text domain) to being based on the text domains directly. For example, instead of https://api.wordpress.org/translations/plugins/1.0/ and https://api.wordpress.org/translations/themes/1.0/ just have one endpoint that takes the domain.
  2. Let code declare to WordPress which domains it needs beyond the defaults of “plugin slug” and “theme slug”. This is so WordPress can download those extra domains, I don’t think WordPress cares beyond that.
  3. Let us register projects that aren’t plugins or themes (e.g. our packages) on translate.wordpress.org, so the packages can be translated and WordPress can fetch those translations like it does plugins and themes.

That way the plugin only needs to declare the packages’ text domains, and the translators would only have to translate each package’s strings once instead of doing so for every plugin using the package.

Summary and conclusion

We created several pieces to make everything work:

We also took advantage of @wordpress/dependency-extraction-webpack-plugin and Calypso’s @automattic/babel-plugin-preserve-i18n, as well as linter rules from @wordpress/eslint-plugin and wp-coding-standards/wpcs (and a fork of phpcs that we’ve been trying to upstream to let us have per-directory configs) to help developers in our monorepo keep text domains straight.

Overall this was quite a bit of work, but Jetpack’s i18n is now better than ever before. And we hope that this post describing the problems we found and our solutions might help other plugin developers improve their i18n as well.

Automattic Women: Anne Mirasol

Welcome to Automattic Women—conversations with some of the remarkable women working all over the world to design and develop Automattic software and make the web a better place. Today’s interviewee, engineer Anne Mirasol, talks to us from her home workstation in the Philippines.

Anne Mirasol at her Automattic workstation.

Who are you, and what do you do? 

I am Anne Mirasol, a software engineer for Automattic. My team is currently working on bringing P2, Automattic’s homegrown remote collaboration platform, to the world.

As a software engineer (or a code wrangler, as we sometimes call it internally), my job is to implement new features, maintain existing ones, and just basically keep P2 running as it should.

What’s a typical day like for you?

I’m a big fan of slow mornings–easing myself into the work day. Even though at Automattic, we work from home, I try to keep my work hours fairly consistent. I find that it personally helps me maintain a healthy work-life boundary.

My work day typically begins in the afternoon, which is also conveniently the time that most of my teammates start their day. We don’t have a lot of face-to-face meetings over Zoom, but we do communicate a lot via Slack and P2.

Whenever I need to step back and do some back-burner work, I go for an ice cream break at the small convenience store near my place. It’s never-ending summer where I am, so every day is a good day for ice cream.

What drew you to Automattic and what keeps you here?

My best friend introduced me to Automattic. She said that it was her dream company, and encouraged me to apply. I valued her opinion a lot, so I was intrigued. It then turned out that the more I learned about the company—by reading all the articles and employee blogs I could find—the more her dream became my dream as well.

I was hesitant to apply at first, since I didn’t know anyone at the company personally, and I thought it just sounded too good to be true. I’m truly thankful for that one Sunday morning where I told myself to stop overthinking, sat up, booted my gaming computer, and just sent in my application. I can say that the company has far exceeded my expectations, and I’m glad to be part of it.

What I like most about Automattic and what makes me stay is the opportunity to work with extremely kind and talented people without having to move to another city or country. It feels like a bigger world has been opened to me, and I didn’t have to leave my family and friends.

A photo I took of my sister and her dog during one of our late afternoon walks around her neighborhood. My sister was telling me to catch up, because the dog doesn’t like leaving anyone behind. “Snowstorm” is our code word for it, and it means I have to walk faster.

What’s your favorite non-work activity?

Before the pandemic, I loved spending the weekend with my twin sister and her dog. She teaches literature at my alma mater, and stays at a housing facility for faculty, so I would regularly spend a night or two with her, and we’d drive around the campus and eat street food, walk the dog, and read paperback fiction while sitting on the university library stairs until after sunset.

Now that I can’t go out as much, I’ve been sampling hobbies and interests and just seeing what holds my interest the longest. To my neighbor’s dismay, I’ve also started learning to play the violin again, working my way through a first-grade book.


That’s it for this edition of Automattic Women. Follow Developer Resources and Automattic Design to meet more great women of Automattic. And if you’d like to do more than just read about these great people, consider working with us!

Automattic Women: Rebecca Williams

Welcome to Automattic Women—conversations with some of the remarkable women working all over the world to design and develop Automattic software and make the web a better place. Today’s interviewee, Rebecca Williams, talks to us from her home on the Wild Atlantic Way coastline of Ireland’s Louisburgh, County Mayo.

Who are you, and what do you do? 

I’m an Engineer Development Wrangler, and I work within Engineer Development in the Developer Experience (DevEx) part of Automattic’s Talent division. Our team supports Automattic engineering teams in the areas of growth, onboarding, and leadership. 

Rebecca Williams in her home office.

My role oversees engineer onboarding and engagement. This involves working with over 150 new starters each year, as well as building and maintaining relationships with leads and other engineers. I am definitely kept busy, but I enjoy every minute of it!

Our process begins at the intersection of hiring and the start date, and we provide support to both our new starters and our leads to ensure that everyone is correctly prepared for the start date. 

As well as individual check-ins, we also hold monthly onboarding calls. These calls are a great opportunity to touch base with our new starters, and to find out what has been working well for them and what we can help with.

Any feedback that we receive during these calls, or via the surveys, is followed-up and acted upon whenever possible to improve the process for future new starters. 

The ultimate goal is to ensure that all of our engineers land smoothly in their teams—that they know what to expect and what is expected of them, and are well placed to begin contributing and feeling productive at the earliest point. We want everyone to feel like they are reaching their full potential, and to consider what else they could achieve within Automattic.

What’s a typical day like for you?

Freedom to choose where we work is one of the great things about jobs at Automattic. Working from home is great, but I also really enjoy working from a coworking space, too. That way I can support small businesses in my local community, and enjoy a change of scenery.

I drop my daughter off at school, then pop into my favorite coffee shop for a caffeine hit. I make my way to the coworking space, or to my home office, depending on where I decide to work that day.

I start my day by checking emails and Slack pings, as well as reading up on any news that happened while I was offline. I try to keep myself organized with productivity tools like Todoist, which I use with Slack integration, enabling me to mark things for attention later.

I start my day by getting all of my operational and process-driven tasks completed, and then I gravitate towards more focused work. At lunch time, I make an effort to take a walk—often to the beach. I find that this is a great way to reset myself and perhaps untangle anything I have been concentrating on in the morning. 

By the time I return to my desk, I am usually ready to go again. I might have some calls, or I might be ready to switch my focus on some other tasks. 

I find time-boxing whatever task I choose to do to be a great way to provide focus for myself. I am definitely a morning person, so by splitting my afternoon, I give myself specific time-frames to work in, which works really well for me. By 3:30, I am ready to pick up my daughter from school. 

When we’re home from school, I log back on and pick things up where I left off until 5:30-6pm. I usually end up feeling pretty productive by the end of the day!

What drew you to Automattic and what keeps you here?

I discovered Automattic at a local remote-workers’ meet-up run by Grow Remote. Afterwards, I read as many blogs by Automatticians as I could find, and one in particular really spoke to me. Having previously worked in a great team, I decided that this emotional connection with others was a really important factor for me, wherever I landed.

The entire Creed resonated with me, but particularly “I will never pass up the opportunity to help out a colleague, and I’ll remember the days before I knew everything.” This is still incredibly important to me, and something that I see for myself being demonstrated on a daily basis. In many ways, onboarding embodies this statement perfectly!

Snapshot from one of Rebecca’s favorite walks. “It was a magical evening when I took that shot; everything was just right!

Another thing that was really important to me was finding an organization that was family-friendly. Being able to do the school run, and be present for my daughter is crucial. Additionally, being able to move my working day around to accommodate dental, physiotherapy appointments, and school visits means that I can spend my annual leave with my family, and really get the benefit from that offline time.

This role provides me the best of everything: a great and supportive team, awesome colleagues, work that keeps me interested and curious—and being able to do all of this from my home. What’s not to love?!

What’s your favorite non-work activity?

Two things really recharge me: spending time in nature, and focusing on a project. When the weather is kind, I will take a long walk—there’s no shortage of interesting routes to take and I have some favourites! 

When the weather is not great, I love to cross-stitch: I immerse myself in really complex projects that are intricate and time consuming. My last stitching project was Cinderella’s Castle, and that took four years to complete (with a Master’s degree in the middle of that!). My current project is An Evening in Venice. It’s taken two years so far, and I’m not even halfway through!


That’s it for this edition of Automattic Women. Follow Developer Resources and Automattic Design to meet more great women of Automattic. And if you’d like to do more than just read about these great people, consider working with us!

Automatically Deploy to WordPress.com Using GitHub Actions

WordPress.com provides you with a great experience out-of-the-box, from superb SEO to social media sharing, custom web fonts, and so much more.

At WordPress.com, we also cover very advanced needs, such as connecting GitHub to sites on a Business or eCommerce plan. This allows you to automate deployment using GitHub Actions, which can become a huge productivity boost for developers. You’ll be happy to know that GitHub and WordPress.com work beautifully together.

Prerequisite: Start your WordPress.com site now

Tutorial Overview, GitHub Deployment Automation

This is a tutorial that explains how to achieve deep customization of your WordPress.com site using SFTP access, including how to deploy custom themes and plugins. Moreover, we’ll explain how you can automate the deployment of those changes by simply connecting your GitHub repository to WordPress.com. Whenever you push changes to a specific branch of your GitHub repository, those changes will automatically be deployed to your site at WordPress.com as well.

Create SFTP Credentials at WordPress.com

At WordPress.com, create SFTP Credentials for your site. SFTP access is available to administrators on the WordPress.com Pro plan.

WordPress.com SFTP creds settings page

Log In Over SFTP, Manually Review Directory Structure

In the screenshot below, which was taken from Filezilla (a popular SFTP client), you can see the primary extensibility features in WordPress, i.e., themes and plugins. Themes are in /wp-content/themes; plugins are in /wp-content/plugins.

If you recreate this structure in a Git repository starting from the /wp-content directory, then whenever you push changes to the GitHub repository, they will be deployed automatically to your site at WordPress.com.

Some core directories and files have a question mark (?) icon next to them. This denotes they are part of your site’s core installation. We do not allow modifying core files as they are required for your site to function properly.

Filezilla SFTP client example screenshot

Create GitHub Repository

I’ve created an example GitHub repository named: wp-github-actions-test-site. Inside this repository, I’ve added a custom theme and a custom plugin that I’ll deploy automatically as part of this tutorial. I have already pushed these changes to the main branch of my example repository. Using my example (screenshot below), please create a GitHub repository for your site at WordPress.com.

Creating GitHub repo example screenshot

Create New Branch: wordpress.com

Create a new branch with the name wordpress.com, such that you have two branches: main and wordpress.com. Whenever you push changes to the wordpress.com branch, you want those changes to be deployed automatically to WordPress.com. You can create the new branch using GitHub’s interface, as seen below, or from the command line. The choice is yours.

GitHub repo branch structure example screenshot

Create GitHub Action

On the main branch, create a workflow by copying and pasting the code snippet (provided below). Please copy & paste the snippet with no modifications into .github/workflows/wordpress.com.yml

Note: It is easiest to use GitHub’s interface for this, as shown here.

Creating GitHub Action workflow example screenshot
GitHub Actions WordPress automation example workflow script screenshot

WordPress.com Workflow Code Snippet

Copy & paste into .github/workflows/wordpress.com.yml

name: Deploy to WordPress.com
on:
  push:
    branches: [ wordpress.com ]
jobs:
  FTP-Deploy-Action:
    name: FTP-Deploy-Action
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@master
        with:
          fetch-depth: 2
      - name: FTP-Deploy-Action
        uses: Automattic/FTP-Deploy-Action@3.0.1
        with:
          ftp-server: sftp://sftp.wp.com/htdocs/
          ftp-username: ${{ secrets.FTP_USER }}
          ftp-password: ${{ secrets.FTP_PASSWORD }}
          known-hosts: "\
            sftp.wp.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQAB\
            AAABAQDwfT/YEhOKO2Z0+XrjRqUS5Q2Ali6AlhOhZtzlIfMOvm03Sype\
            DJH70tlUHasS+nm0SnZ01fOiEeAXa91ZhMihIYUT3nTGuiA2J3uVYsyS\
            CJefvhWc0kg1FbEus3V3cVmx4e3XctdkzLbOgPNngypZocbP+8yCpbx6\
            Kb9lihmgTjgGn2QzbK1enRSzsN/CbjVhej9jwukbrWqdCrQsKAsoZ2p6\
            YCtcKbHS+Yy4RwcO9PxZUBkeMXUrejms027bRcdVfwf55hWSD9xYEHpE\
            HupkSL4ofWs3UKeRGz+jCCzl7Nu0S6VSwK4Zzll0auHI0Hwh8WKTJbSn\
            1gxCdF93/rmP\
          "

Create GitHub Secrets

The workflow code snippet references two secrets:

- ${{ secrets.FTP_USER }}
- ${{ secrets.FTP_PASSWORD }}

Create these two secrets in your GitHub repository using the SFTP credentials that you obtained at WordPress.com in an earlier part of this tutorial. Please define both the FTP_USER and FTP_PASSWORD secrets.

GitHub Actions workflow secret example screenshot
GitHub Actions secrets settings in workflow

Push Changes, Test Deployment Automation

Now that you have everything configured properly, update your local copy of the GitHub repository using Git from the command line. Start by fetching all updates, then pull changes into the main branch, merge them into the wordpress.com branch, and finally push those changes to the wordpress.com branch. In doing so, you will test the GitHub Action workflow to make sure things are working properly.

$ git fetch --all
$ git checkout main && git pull
$ git checkout wordpress.com && git merge main
$ git push --set-upstream origin wordpress.com

At this point, you can visit the Actions tab at GitHub to review and observe status. Since you pushed to the wordpress.com branch, the workflow you created should already be running. When it’s finished, the status icon will turn green with a checkmark indicating your changes were deployed successfully to WordPress.com.

GitHub Actions workflow ran success screen within repository

In this case, the workflow is deploying your last change, which was to “Create the wordpress.com.yml” file itself — from a previous step in this tutorial.

In the future, when you merge and then push any changes, such as theme or plugin updates, from the main branch into the wordpress.com branch, they’ll be deployed to WordPress.com automatically. Yay! 🎉

The Pro Plan at WordPress.com

At WordPress.com, you’ll be well-equipped without installing custom themes or plugins. However, if you want to take your site to the next level, our Pro plan supports several additional features. This plan includes increased storage, custom themes, custom plugins, and SFTP access, making the GitHub integration described in this tutorial possible.

Start your WordPress.com site now

The Rise of WordPress Frontend Options, Themes vs. REST API + JS/React: Decoupling WordPress

The opportunity to move to a decoupled or headless WordPress system is an emerging discussion because of the broad range of possibilities it opens for developers with complex architecture needs. Decoupling, or separating the backend from the frontend with a framework like Strattic, also delivers a level of complexity that should be factored in when planning a project’s development. Certain projects can benefit from decoupling, while the fully integrated WordPress platform better serves most use cases.

When the words “Learn JavaScript Deeply” were spoken by Matt Mullenweg in 2015, the world hadn’t yet fully realized the scope of what would soon be possible. Then, when the WordPress REST API was released as part of core in 2016, the platform made a giant leap into the future. Of course, Gutenberg, the WordPress editor introduced in late 2018, highlighted what could be accomplished with this new feature as it uses the REST API to create and update posts by communicating with the WordPress core backend. Both the REST API and a modern JS framework built on React are shipped with every copy of WordPress and are now integral components.

This evolution of WordPress means that today, developers are no longer limited to PHP. Instead, developers can create apps built on React and other JavaScript frameworks, served by Node, and powered by the WordPress REST API. This enables WordPress development by frontend developers who don’t write PHP, as well as integration between WordPress and other frontend technologies and systems. 

Key Issues To Consider 

First, a reminder of some key issues worth seriously considering as you weigh decoupling, versus using WordPress as a complete solution. 

  • Performance – Many developers want to decouple in the belief that this increases performance or scale. This, however, rarely proves itself in reality.  Decoupled front-ends must be scaled separately from the WordPress backend. A good host largely solves scaling in traditional architectures. A top-tier enterprise WordPress platform, such as WordPress VIP, will also scale endpoints for decoupled architectures and can serve Node apps at the same scale as anything else being served.  However, decoupled front-ends present their own points of failure, their own caching mechanisms, and generally increase performance risk.  For example, if the site is down, is the front-end causing the problem?  If so, which part of it?  Or is it the API?  
  • Total Cost of Ownership (TCO) – Even teams with mature JS capacity typically find that decoupled experiences have higher TCO than traditional ones. This is primarily due to duplicate hosting, multiple technologies, split teams, multiple codebases, multiple caching strategies, and more. The overall cost of support and build of a decoupled project is almost always higher than a traditional integrated WordPress build. It is essential to consider cost in terms of the whole lifecycle of the project.
  • Solved problems / ecosystem – Out-of-the-box WordPress architectures have more access to integrations and community solutions than custom front-ends.  Sure, React supports many community extensions and integrations, but when we limit the scope to the kinds of extensions required for content apps, WordPress’ extensions and integrations are almost always easier and cheaper to figure out. Examples include AMP and other delivery channels, authentication/SSO, many platform integrations, and even features such as “preview” become an issue that needs to be solved anew for decoupled sites.

Available Toolkit

Today’s decoupled WordPress toolkit is quickly growing, and it includes the following popular solutions.

  • GraphQL / WPGraphQLGraphQL is a Query Language built to craft more precise and lightweight queries to bring only the data you need from the REST API into your front-end application. WPGraphQL extends this framework to be specific to WordPress.
  • GatsbyJS – GatsbyJS is a React and GraphQL-powered static site generator built for speed.
  • FrontityFrontity is a React framework for WordPress. Out of the box, it is set up to consume content from the WordPress REST API, giving developers a big head start by providing many of the most common queries already built-in.
  • StratticStrattic is a static site generator and hosting platform tuned for WordPress.

When Decoupling is an Option

Some of the most relevant reasons developers choose a decoupled approach for complex WordPress projects include:

  • Portability – The app or digital experience needs to be extremely portable or agnostic of the back-end technology.
  • Diverse data sources – The app or digital experience pulls data from more than a small handful of sources, with WordPress being only one of those, and where the WordPress source is probably not the most central of those sources.
  • Leveraging an existing JS-oriented dev team – Frequently, teams of JS developers, especially newly minted ones, want to build Node apps and leverage modern front-ends like React. While the current team’s capabilities are worth considering, this reason may or may not be outweighed by other factors. In addition, there is plenty of exciting work for modern JS developers to do within WordPress itself.
  • Moving into the future of modern JS frameworks – Sometimes, teams want to leverage modern frameworks because the technology is newer, supports app-like behaviors natively in the browser, and it is relatively easy to hire qualified modern JS devs.  These are valid considerations, especially if there are other business reasons to invest in this capacity. However, it is crucial to avoid automatically assuming that modern JS does everything better, cheaper, or faster than WordPress’s mix of PHP and modern JS.

AccuWeather: Making Brilliant Use of Decoupling

This marriage of technologies is the result of leveraging the long-term stability of WordPress with its vast ecosystem with modern frameworks such as React. When used appropriately, this union enables the creation of brilliantly complex applications. One example of this in use is the extremely popular AccuWeather. 

AccuWeather is recognized as the most accurate source of weather forecasts and warnings in the world, serving roughly 1.5 billion people daily. The system comprises weather forecasts, local media partnerships, enterprise solutions, APIs, news, videos, podcasts, and weather data. 

AccuWeather uses a decoupled WordPress stack that includes over 750+ million WordPress requests per day and 50+ billion data calls per day. 

So what advantages were gained by AccuWeather moving to this architecture? 

  1. By retaining the use of WordPress, they can utilize the backend UI/UX experience for the content team. While content is only one part of AccuWeather, it is an ever-growing piece of the brand and company. Using the WordPress backend, the editorial team can work with the most widely adopted and accessible CMS platform, which is used by 40% of the web.
  2. By decoupling the front-end from the back-end, rapid site redesign was made possible without worrying about making massive changes to the platform’s CMS side. 
  3. Finally, the decoupling makes the content easily accessible by other applications. Various development teams, such as app or enterprise teams, can present the content anywhere. For example, they can include a newsfeed with localized content in AccuWeather apps or present targeted video in a widget on a partner site. 

While AccuWeather makes extensive use of the REST API, many other companies and projects can benefit from utilizing and extending the REST API. For example:

  • A vendor may utilize the API for large-scale content migration.
  • A CMS dev team may extend the API to to create mobile apps, or facilitate communication that helps complete 3rd-party integrations.
  • Much like Laravel, WordPress offers developers an extensible REST API framework. A company can easily add new routes and endpoints, giving them a more predictable and structured way to interact with site content or other backend data. They’ll spend less time building tools to access data, and more time creating better user experiences.

One Final Consideration

If all of this seems like the perfect solution for every future project, there’s one final thing to consider before making that jump. 

Decoupling requires a developer or team of developers throughout the entire lifecycle – Developers need to not only be involved in the creation of the project, but will also be needed to manage the site throughout its lifecycle. The client will rarely be able to manage this on their own. While many fully integrated WordPress websites can be left in the care of the site owner, a decoupled WordPress site is usually far too complex for the average site owner to maintain, keep updated, and ensure security and forward compatibility.

Decision Worksheet

Use an internal decision worksheet, such as the one we’ve provided here, to help determine if your project should move forward with a decoupled architecture or not. The more times you answer “No” to the questions, the more caution you should exercise before moving forward. You may still decide that decoupled is the best option, even if you’ve answered ‘No’ to many of the questions, but more deliberation might be needed in that instance.

The Best Choice For You

WordPress leverages the best of a stable, mature product with the promise of evolving with ever-changing modern technological future platforms. Some projects may benefit from the WordPress platform’s integrated approach, while others might require a decoupled architecture. When making decisions, consider the following:

  1. Ask why – Identify the key drivers of your decision, and be honest about this. Are you choosing the more complex decoupling method because it’s the latest cool technology, or is it because it best serves the project?
  2. Consider the total cost of ownership – The TCO over the whole project lifecycle, including multiple hosting, increased complexity, more technical debt, etc., may be significantly higher than you expect.
  3. Look ahead – The landscape around JavaScript and WordPress is changing and expanding rapidly. Can you position your team and your application to thrive in the years and months to come?
  4. Embrace JavaScript – Regardless of your decision to decouple or not, embracing JavaScript will enable you to do exciting things, even within WordPress internally. Learn JavaScript Deeply…still as true today as the day Matt first spoke those words.

Many factors will influence your decision, but WordPress will always be there, either integrated or decoupled, to move your project forward in the best possible way.

Written in collaboration with Donna Cavalier & Jason Caldwell from WordPress.com, and Ryan Sholin & Matt Perry and WordPress VIP.

State of the Word 2020: watch the recording

State of the Word 2020, an annual keynote delivered by WordPress project co-founder Matt Mullenweg, was streamed live on December 17th. Check the recording below to watch at your convenience. You can also watch it on the WordPress.org blog, Facebook, YouTube, or Twitter

Listen first-hand to all the cool improvements that have gone into WordPress this year, thanks to the contributions from thousands of developers and other WordPress enthusiasts from around the world. Also get a glimpse into what’s next for WordPress in 2021. If you develop, design, translate, own a site, or in any way connected with WordPress, then don’t miss it!

Sharing the Data: How Technical Women Navigate Their Career

coaching-coders-coding-7374.jpg

In May, Automattic’s engineering hiring team launched a user research study to better understand how our approach to tech hiring resonates with women and non-binary folks who may experience similar gender discrimination in the workplace and are experienced developers. We asked participants questions about how they saw their careers and next opportunities, as well as specifically asking about their reactions to our job postings. It’s easy to find advice on this topic, but the volume is overwhelming and the information is often conflicting. We wanted to cut through the vast quantity of Think Pieces On The Internet to make some changes based on actual data. Our goal, unsurprisingly, is to identify ways to increase gender representation on Automattic’s engineering teams. 

This was a fascinating process, and we are truly grateful to the 71 people who responded to our request for feedback. Given that we had this level of interest within just five days speaks to the relevance of the topic, as attracting contributors to a research project can often be far more of a challenge. While much of what we learned (discussed below) lines up with research you can find online, listening to people share their individual stories was profoundly impactful on our interviewers. It also revealed further insights that we are eager to apply. Automattic’s hiring team has been able to make some immediate changes, but have much more to think about, and expect this to influence our ongoing efforts.

Methodology

Out of our pool of 71 engineers, we conducted in-depth interviews with 14 participants, and a further 24 answered our follow up survey. The majority of our respondents had over 10 years experience working in software development, and around 60% of them had looked for a new job in the past year.  71% of our respondents were from the US, and all but one participant lived in English speaking countries. All participants self-identified as women or non-binary. The research process was very similar to that used in product user research. We described our initial rationale, invited contributions, used a consistent script, and vetted respondents to ensure the diversity of our interviewing pool. 

Results we expected?

  • Respondents have strong networks that they use for job hunting and support.
  • Respondents are most likely to leave a current role in search of growth – for example, Deutsche Bank discovered that women were leaving to take “bigger jobs” (DB’s term) , than they were offered internally, something that was addressed by adding a sponsorship program.
  • Respondents carry out extensive research on companies before applying if they do not already have a personal connection in the organization, and are highly attuned to red flags. This matches what data shows on the experience of women in tech companies – in the Elephant in the Valley survey, 66% of women report being excluded from opportunities because of gender, 60% report being sexually harassed, and 60% of those who reported it were unhappy with the course of action. Womens’ career choices are too frequently based on avoiding a bad experience rather than seeking a place where they can thrive.
  • Women in technical roles feel pushed onto the management track, and have to fight to continue to focus on technical work as individual contributors.
  • Women receive a significant amount of personal outreach, and many have come to expect it. Generic requests from recruiters are unlikely to be successful.
  • It’s important that other women are visible in the hiring process. Many women have experienced being “the only,” and at this point in their careers prefer that not to be the case.
  • Hiring processes that are collaborative and responsive – a growth opportunity rather than purely evaluative – were perceived most favorably.
  • Respondents care a lot about a respectful process. Responsiveness is a key metric, and was also a theme in interactions.

What was surprising?

  • Respondents read job descriptions almost exclusively for red flags; for instance, they search for language encouraging all relevant employees (not just women)  to take parental leave.
  • Glassdoor is not considered useful, being seen as mainly a place for negative reviews  by former employees or unsuccessful candidates.
  • Many interviewees mentioned using Stack Overflow to look for jobs. We had previously advertised on that platform and discontinued it based on the demographics of applications it drove; diversity of applicants was even lower than the already too-low industry average (as also seen in their survey). However based on these findings, we are running another test on that platform.
  • For some participants, interviewing is seen as a skill to maintain. These people are continually looking at job listings (though at a less-intensive level than a full job search), to ensure that they are aware of their options – before reaching a point where they’re desperate to leave their current position.
  • Consistently being able to have an impact (including leadership opportunities) stood out as important, and they will leave their current role if they cannot find this. This is a key point related to research showing women are evaluated more on their past performance and men more on potential. 
  • Women are looking for more communities focused on connecting to other senior women,  and around more technical topics (many communities focus on entry to mid-level folks). Concerns around online harassment can put women off trying to build their network online.
  • Respondents look to have as much information as possible up front – about the job itself, salary ranges, the team they would join, and the hiring process, and expectations in terms of responsiveness.

What changes did we make?

  • Existing work and life commitments mean that it is important to know the details of the hiring process at the outset: we have published a public page that clearly outlines our hiring process so that people have a concrete understanding of the expectations. We’ve also put together a more detailed document about what to expect during interviews, and will be creating similar materials for the other phases of our process.
  • We are revisiting our employment branding strategy to take into account the extent of research by candidates, revamping our developer blog, collecting resources on what it’s like to work as a developer at Automattic.
  • We are working on supporting our existing developers to increase their visibility externally, through encouraging them to write (our OSS culture goes beyond our willingness to share code), speak, and engage more in their communities. Many co-located companies use their office space to host community events, and it’s clear that is a smart strategy, because it builds employer brand, awareness, and personal connections between candidates and the host/prospective employer. We are looking to find a more distributed, office-less way to approach this.
  • Historically, we’ve resisted asking existing under-indexed employees for second shift work – it’s a too-common reflex- to put the work of “diversity” ahead of and at the expense of those for whom we should be doing the work of “inclusion.” This research made it clear that the highest-leverage activity for our existing under-indexed employees was chatting with potential candidates, and we are making casual chats with other women more available to potentially interested applicants. We see this as more impactful than asking women in particular to interview. While this still amounts to asking for second shift work, we are aiming to identify the highest leverage activities and ask just for participation in those, rather than putting the full work of “diversity” on the diverse, and expecting them to do everything on top of their current job.
  • We removed all the little games from our job posting page. We were trying to test people’s attention to the job posting and filter out unmotivated candidates; it turned out we were also putting people off who we want to apply.
  • We removed all the language that emphasized that hiring is a competitive process -for instance, removing language about application volume.
  • We will be testing adding “(Senior)” into all our technical job postings. Historically, we’ve been reticent to do this because it implied a job ladder that doesn’t exist at Automattic, but the research clarified that its absence sent the message that our positions are all mid-level roles without the path to growth that women candidates tend to look for. 
  • We rewrote our job postings highlighting the learning and career opportunities for the candidate, rather than focusing on our needs.

What are we considering going forward?

Some of what we learned was less concretely applicable, or requires broader changes across our engineering organization.

We’re considering how to adjust our messaging with respect to D&I, and whether some of this messaging should be tailored to developers and D&I within the engineering organization specifically. We also need to consider how this interacts with the commitment to Open Source – the data shows that women are less likely to contribute to Open Source projects, in part because of the culture of many of these projects.

The best way to retain the women we have is to ensure that they have opportunities for growth outside of affinity networks. This is something we’re mindful of as we look to improve opportunities for growth across the organization. We’re also considering the research in Women Don’t Ask, and thinking about how to offer under-indexed folk opportunity, rather than expecting them to ask for it.

Another key area to explore is the importance of titles. As an organization, we have an unorthodox approach to job titles, promotions, and leveling; employees are free to create their own job titles, and promotion and leveling are holistic processes focused on the specific employee, their skills and development goals, and current team needs, rather than on a preconceived hierarchical chart. We hire only experienced engineers who will make the whole team better – the way they choose to do that is up to them and their team lead. Bringing in titles would be a significant change to the way we operate, potentially reduce our flexibility, and if not done carefully and thoughtfully would be destined to fail. We have to consider whether we can better facilitate growth, and make the opportunities for growth and recognition clearer in our job postings and hiring process.

Some changes we’ve made relating to this recently:

  • We took a group of >20 team leads and developers to the Lead Developer event in London, and facilitated a day together. We will repeat this for US-based team leads in Austin later this year.
  • We have started offering candidates the opportunity for one-on-one calls with a member of our Developer Experience team during later stages of our hiring process; we’re starting with under-indexed folks, with a view to rolling this out to everyone. These exist outside the regular hiring process, and is premised on the idea that it both provides an  opportunity for the applicant to ask any questions they have and for us to better understand their career goals and motivation so that we can assign them to the team that’s the best fit. 

It’s early for all of this, but we’re excited about the concrete changes we were already able to make, and the initial markers of progress we are tracking. As our Creed states, “I am in a marathon, not a sprint” – we have much more to do.

This project was a team effort from @sinitivity, @tobynieboer, @rlwilliams0803, @annahollandsmith, led and coordinated by @annezazu. You can find the official announcement and a more complete whitepaper here.

Leadership in Fully Remote Teams with Aaron Douglas

Aaron Douglas, one of our mobile team leads, has been with Automattic for six years. Almost immediately after starting here, he struggled to find the ability to focus and prioritize his work. He’s put significant effort into understanding how to change behaviors associated with Attention Deficit Disorder which have had numerous positive side effects. Those tools have evolved further over the last five years of him being a team lead. To share what he’s learned, he recently spoke at THAT Conference on August 8th in Wisconsin Dells, WI, USA. The conference describes itself as a “Summer Camp for Geeks”:

Over four days, folks of diverse technology backgrounds and expertise levels gather to take advantage of multiple learning mediums to maximize one’s community and career advancements.

Aaron chose to focus on leadership within fully remote teams since he’s been leading a team at Automattic for the last 5 years. As the description of his session states, “Remote working brings a whole set of challenges that should be addressed by every employee and it’s a good leader’s role to make sure nobody is blocked by them.”

To learn from Aaron and how he approaches remote team leadership with his unique background, check out his slides and reach out to him on Twitter if you have any questions. If you’re more of a visual learner, we’ve got you covered with this awesome sketchnote from an attendee at the conference:

If you’re interested in getting a better understanding of Aaron’s personal experience working remotely and the impact it’s had, be sure to also watch his talk on WordPress.tv titled “How Working Remote Saved My Life”.

P.S. If you’d like to work with folks like Aaron, check out our jobs page! We’re hiring and would love to tackle problems together.