Connect yourself to the source.

The biggest challenge of developing WordPress sites locally has always been putting them on the internet when you're ready to go live. WordPress uses a database to store content, which makes migrating a site without breaking stuff a giant. pain. We thought we could make it better by connecting our local platform with our internet ones.

connect-header@2x-1

Uhh... so how is this gonna work?

This was a complicated problem. We’d need multiple places for people to connect. Someone may want to pull or push from an existing Local site, or pull down to a fresh Local site. We started by only connecting to Flywheel, but wanted to connect WP Engine eventually, too, so what patterns would benefit us in the long term? What were the technical risks? I led some team brainstorming to come up with a plan.

connect-stickies@2x

I ran brainstorming sessions with the PM & engineers around technical & user needs

AUDIT-Affordances-for-Connecting-to-WPE-_-Other-Hosts@2x@2x

I then iterated on process flows to clarify interactions early

Push-–-first-time-–-9@2x
Push-–-after-connected-and-after-selecting-site@2x
Individual-site-logged-in-connected-–-host-selector-engaged

Dealing with site requirements

As a managed WordPress host, we lock down our platform pretty hard for security. Locally, however, it’s the Wild West. People can do whatever they want — which is great!…unless you want a magic one-click system for deploying back and forth between a server.

We needed a way to make sure local site settings matched the server settings at the destination...otherwise your site would break. That’s not magical.

Server setup? Simple.

We came up with the concept of "Preferred" and "Custom" site setups, and reinforced the selection UI with cute little icons. This way the average user wouldn't run into problems (they'd be scared to click "custom"), but the advanced users could more effectively troubleshoot.

We also worked out ways to automatically update settings if our requirements changed, or if someone wanted to test a newer version of something locally and update Flywheel via a push.

connect-tab@2x

Two-way connection

We also needed a way to pull down from the host into Local. I wanted Connect to be discoverable, so I gave it its own tab in the sidebar. This provided ample room for future growth.

connect-pull@2x

To Flywheel + beyond

At the site-level, I chose to leverage our footer action bar for Connect. It already had a shareable link feature (“Live Links”), so this felt like the perfect area to turn into a complete “external access management” section.

Icons launch the Connect experience (later becoming "Magic Sync.") Here you select the site to push to or pull from, turn on or off database syncing, and it would just take care of it.

It seriously was a game changer — the public response after launch was incredible. This had never been done before.

connected-–-bottom-bar@2x
teleporter_dribbble
grab-placeholder-–-VIDEO-CALLOUT@2x
connected@2x
push-select-site-–-2@2x
push-select-site-–-1@2x

Project impact + reflection

I remember starting this project and feeling like the challenge was so massive it might not actually be possible. It just goes to show that by breaking things down into small chunks, working with your team, and solving for the problem in front of you, it's possible to do some really cool stuff. This was one of those design and product challenges that now feels so obvious and natural that it's almost like it has always existed.

It's been cool to see it expand into supporting other hosts (WP Engine, specifically), and further close the gap between technical and non-technical peoples' abilities.