Product Build Breakout Summit/2020: Make Local WordPress Development Simple
Keep it simple, but make it advanced. Local is a fuss-free, cost-free way to spin up local WordPress sites, test your latest site updates, and speed up your development workflow. During WP Engine’s 2020 Summit Jack Sellwood, Product Manager, Flywheel shares fuss-free dev tools to bring your team online. Leave this session with a renewed confidence in your development!
Jack Sellwood, Product Manager, Flywheel discusses:
- Web development workflows and how modern dev teams are working together in local dev environments.
- Options for everything from managing your own servers to the latest technologies.
- How to stop debugging local environments and spend more time launching WordPress sites.
The best option for scalable serious projects is working locally – local dev environments are the way to win.
Full text transcript
– Well hey, thanks so much for joining today. I’m super excited to walk through how to make Local WordPress Development simple and fuss-free dev tools to bring your team online.
I’m Jack, I’m Product Manager for Local over at Flywheel and I’m super excited today to talk about Local WordPress Development.
So I just want to take a quick step back and ask how are web teams working together?
I think this is important to understand as we start to talk about WordPress workflows.
So we’ve sort of seen that web development workflows split really into three categories. There’s a lot of WordPress developers that still cowboy code and this is okay for small or solo dev projects but it’s really not great for projects at scale.
It’s kinda where cloud-based development environment come in, some developers reach for that tool. And that’s workable again for solo dev projects and its a step up, but really if you’re building a larger project or working with multiple developers that’s where Local dev environments come in.
So kinda digging into these cowboy coding again, it’s okay for smaller solo dev projects, it’s okay for tinkering, but one mistake causes downtime. So for getting a semi-colon at the end of a line of PHP, it’s gonna cause downtime on your site.
The other downside with that is that changes whether they’re erroneous or not go live right away.
And so when you make a quick tweak to your site, like just a color change, or maybe you’re actually debugging everyone’s gonna see that immediately.
And as a result, it’s also slow and inefficient. Every time you make a modification, you have to save it, upload it, and then preview it over your browser. And this really only works for one developer.
If someone else is making file changes, they’re gonna overwrite yours. And here obviously advanced tools aren’t available, so if you’re using things like npm or Gulp those tools aren’t available, again, this environment’s hosted, on your website host and you can’t install custom software there.
The next sort of option that some people reach for is cloud-based developer environments. These are workable for solo dev projects, and they’re definitely a more mature workflow since they’re completely sandbox and don’t cause site downtime.
But they’re still slow and inefficient, and again, they’re still limited to one developer. This is sort of an upgrade for a single developer, it’s still hosted wherever your website’s hosted typically and advanced tools still aren’t available here.
So it’s better, it’s not gonna bring your site down, yay, but it’s still not super efficient as a developer.
The best option for scalable serious projects is working Locally.
Local dev environments are the way to win, they’re completely sandboxed. You can make file
modifications, code changes and view those very quickly, so you can quickly iterate.
This is great for many developers, every one of your developers has a computer, so they can work on their computer itself, which means they can install the software they want and use advanced tools like NPM, Gulp, packer or any of the others.
But sort of the downside here is that it does require setup. There’s some tinkering with your computer and the software on it that you need to do to get this working.
Well, we’ve seen across these three workflows is that modern dev teams use Local dev environments because they’re the fastest way to work, but there are some challenges to this, consistency across developers is sometimes a struggle.
Everyone has a different computer with a different operating system and a different version of software.
Setup and tooling is also undocumented across computers, and so making the process
reproducible can be a challenge, since everyone’s computer and software again is different.
The Local dev environments can be prone to bugs and challenges. And then again, because it’s a developer’s individual computer, they can really install and use any of the advanced tooling they want.
So there’s this struggle to balance developer preference and team norms. There’s lots of options for a wide range of developers.
VirtualBox is great if you’re looking at doing serious debugging and tuning, but it can be prone to
errors just since that, it’s running a virtualized copy of Linux on your computer.
Laravel is super speedy, but it does require more advanced setup and knowledge of composer and more advanced PHP technologies.
Docker Desktop has gotten a lot easier to use now with a built-in gooey, but it does require manual setup still, and sometimes long provisioning process. It doesn’t work great for lower end machines.
MAMP is pretty accessible and customizable, but it suffers from poor environment consistency,
and as a result is prone to bugs. So it works okay, and it works for more than just WordPress, but it’s not gonna work for everyone across all their computers every time.
Local on the other hand is purpose built for WordPress, not necessarily great for other projects,
but really great for WordPress projects, and it’s speedy to set up. And what we’ve seen across,
again, all these workflows and all these developers we work with is that the dev tools that are turnkey are winning dev tools.
Turnkey dev tools are winning dev tools. And that’s really where Local comes in, Local is that turnkey tool to work on WordPress on your computer, work on WordPress offline, and just sore.
Localize all the things you’d expect from a Local dev environment. You can quickly create new sites, you can customize the config and preferences of those sites.
Local’s a completely sandbox environment. You can tinker with the WP-config or anything else on your site to try and understand what’s going on and build awesome new projects.
And Local is great for the whole team. I’ll be from any intermediate
WordPress developers, all the way to advanced developers, we have a future for everyone.
There’s a couple basic features for Local, and these are sort of geared towards more of that intermediate WordPress developer and the great features to start a new project like creating a blank site for brand new projects.
You can import existing sites, say if you’re rescuing it from someplace else or from an old agency.
You can also create new sites from blueprint, so if you’re cranking out sites that are similar to one another, you can create reusable site templates if you will, that we call blueprints, and Localized best-in-class Multisite supports you can create new ambitious projects with Multisite running Locally on your computer.
And for testing things like WooCommerce conversions or form submissions we enable you to really quickly trust create self-signed SSL certificates.
From our advanced developers, we have awesome features like custom environments tweaking
and tuning the version of PHP in just a couple clicks that’s right you can hot swap the version of PHP you’re running.
With MySQL, you can upgrade to the latest bleeding edge version, MySQL 8 which isn’t even available in those public clouds, and then you can also hot swap between different web servers, Nginx and Apache.
This is really great for plugging in theme authors that wanna test and confirm feature parody, and support cross the wide variety of WordPress environments that people may encounter.
One-click database management is also available in Local via Adminer, so if you need a debug
and sort of triage your WordPress database, you can do that without needing to download it and install it through third party tool, although we also support socket connections for that.
And we also ship with MailHog, which is an email catcher and debugger.
And this is really helpful for WooCommerce sites where maybe you need to test out the receipts
or order confirmations that are sent from WooCommerce or other plugins where conversions and transactions are important, you can debug those emails.
And I think one of Local’s most powerful features is the zero-config WP-CLI. So there’s a lot of environment variables and a lot of things that you need to do to make WP-CLI work correctly, and Local handles all of that for you.
Right-click on a site in Local, and you can instantly open up a shelf in optimize images, or, sorry I should say regenerate thumbnails, or export your database.
All the functions into WP-CLI are supported. And there’s also really great logging for all of Local’s very services, whether it’s Local’s query logs, MySQL errors, PHP logs, all those are available in surface within your Local site.
People tend to agree that Local has the features they need.
Matt Litherland said, “Holy glorious god…Just tried Local by Flywheel after Wes Bos mentioned it a few days back. What an absolute freakin’ dream to use. Bye bye MAMP for WordPress dev.”
The WordPress community just loves Local because it’s so easy to use, that they’ve come to learn and expect that with WordPress plugins and themes and WordPress software is turnkey,
and it just works out of the box, and Local tries to deliver on that promise.
So for your next WordPress project, no matter where it’s hosted, get started with Local for free,
stop debugging Local environments, and spend more time launching WordPress sites.
So you’ve built this new website, you’re super excited to make it go live. How do you actually launch it?
This is sometimes one of the scariest moments for a developer or you’re working in your coding
and maybe you’re working alone, great, you don’t have to deal with other people, but now you want to actually launch this site or your clients asking, “Hey, I want to launch this site.” Or, “We need to go through an internal review process before we launch it.”
That can be scary, and so Local can do a couple of things to help out with that.
So sort of taking a step back to think about how launching actually happens. We think about a WordPress developers workflow is sort of split into three main sections.
There’s the build phase, which Local obviously serves for huge chunk of it’s helping facilitate you coding on your computer.
And then the flight one WP Engine platforms are sort of there for that launch phase, and there’s some overlap with Local we can help move your site up really quickly.
And then there’s the managed side. So not just managing your site in the sense of creating backups, but also managing in the sense of maintenance and ongoing updates and things like that.
And so as a Local team we’re obsessed about this workflow every single day, and we try and think through critically where there’s pain points along this to try and make specifically launching
and iterating, you know, you launch now, but you’re going to iterate in a month, make that whole process easier.
So we sort of have this magic formula for launching with confidence.
Number one, we wanna avoid site errors. So avoid things like PHP errors, broken links, and slow page loads.
We want to enable things like test review and test again. So reviewing the site as a team, and then when you actually need to go live making that process take just a few seconds or minutes instead of hours, or an afternoon where you’re running around.
So Local’s new broken link checker feature helps you avoid website face-palms. We quickly and recursively crawl through your entire site and we’ll detect broken images, links, and fatal PHP errors.
And this is great, again, if you forgot to semi-colon on a template page, but you didn’t realize that you did that. This will help you uncover that.
And because Local’s purpose-built for WordPress, and we know that this is WordPress, we can actually use the post ID of a page to remove duplicates.
So we’ll exclude all of the archive pages that a post appears on and show you where the link is actually broken on that post’s individual page.
And as a result, we’ll actually offer you a link to go immediately fix this in WP admin.
So just saving you a ton of time from looking through a huge list with duplicate links, or making you sort of second guess and figure out where the link is to go fix it.
So this is a great way to avoid fatal PHP errors and also common 404 errors where maybe a website you’re linking to it doesn’t exist anymore.
Another great way to sort of avoid common website errors and website face-palms is to
boost your site performance with image optimizer.
So improve page load, and this is especially important for mobile visitors. So people who are loading the site on a smartphone or a tablet bandwidth there is constricted, cellular networks can’t load 14 megabyte image really well.
And it’s a great first step to use cropped thumbnails, which is built into WordPress, but you can take that even further, by improving page load by actually optimizing and compressing those images down to be smaller files.
Different from a lot of WordPress plugins and third party services, Local’s image optimizer runs completely offline. So there’s no uploading images to a third party service and waiting for those to come back. And we’re definitely not optimizing these on your production server, and a lot of plugins do this, and they actually slow down your production website for visitors, which is not great.
As a result of this running offline, it’s completely private insecure, and because it’s running on your computer, we also are able to hardware accelerate it to make it run as fast as your computer will let it.
We think this is a really great way to just with a couple of clicks, save a ton of performance or save a ton of time and really boost your site performance.
Magic sync is sort of that next stage, so when you are ready to go live, or you want to do daily check-ins, you can really quickly iterate and push your site up to WP engine or poll it.
A magic sync builds on Local connect to in a verbose fashion show you exactly everything that’s going to be pushed and pulled from your site.
And as a result, you can quickly iterate, so instead of pushing and polling your entire WordPress uploads directory every single time you can just check a box and say, “I only wanna poll my 2020 media”, or “I only wanna push and poll over the last two years.”
Or if there’s specific themes or plugins that you only like to have when you’re working Locally you can do that as well.
A common request from very serious developers for using Git is they say, “I don’t want
to actually pull any files. I just wanna pull my database down. I just wanna test to
see the latest version of my database how that behaves with my code.”
So you can actually uncheck all of these files and just pull the database. And this actually augments Git for GoLive. So we hear people very commonly using Git to deploy code.
This isn’t the best, CI/CD are really what you should use if you’re using Git to deploy your code.
But for those developers that want something a little more simple, or don’t want to provision a CI/CD for hundreds of sites, magic sync for many is the best way to deploy on WP Engine.
So you might use Git sort of alongside Local, initializing it in the directory where it’s needed
in your WordPress site and making commits out to your repo, but then when you’re actually ready to go live, we see some developers switch to master on their Local computer and use Magic sync to push up.
Again, if you’re managing hundreds of sites, this can be a lot faster than using FTP or provisioning a CI/CD for each one of those.
Magic sync supports production, staging and development for all WP Engine sites. So Local really is that turnkey dev tool for all of your developers, advanced developers and WordPress developers, and with new pro features, it helps you launch with confidence and feel rock solid about the digital experiences that you’re building.
So give it a shot, it’s a fuss-free way to start your next WordPress project.
Thank you so much. This has been a really awesome time and give Local a try.
– Hope we can go over a good workflow that includes GitHub versioning.
So I did asked this before the presentation started, but Jack maybe you could
comment on this for us.
– Yeah, love it, Dave.
We actually get this question a lot and it’s something that, sort of, as we look throughout this year, we wanna improve our documentation on.
So Local doesn’t have an opinion about Git today, You can absolutely use Git, and initialize get repose within your Local sites, alongside Local. Local doesn’t block or interfere with any of this.
So what a potential workflow could look like is you pull a site down from WP Engine or Flywheel.
Let’s say you’re versioning your theme. You would go delete your theme, and then you’d clone down your GitHub repo. And you can make your code changes there, checking them out to Master, or the branch of your choice.
And you can do those two things side by side. Then at the end you have a decision to make, do you wanna use Local to push the site back up?
Or do you wanna rely on your GitHub repo, to deploy those changes using GitHub actions
or some sort of other service?
– Nice, nice, I think I’ll switch things up. I’ll ask one of my own here.
What do you think is the best feature in Local that people are unaware of? These are always my favorites, like these Easter eggs, like what’s the one, like view all unread in Slack is like a game changer. But what are these like unknown but helpful things in Local?
– Totally, so Local actually has a pretty powerful importing engine. So Local can automatically import run, search and replace completely unpack and move into place any zip file of a WordPress site, as long as there’s a WP content directory and a dot SQL a file of your database.
Where that file or folder lives within your zip file actually can be variable, and that’s what’s so powerful about it. ‘Cause you don’t have to worry about the files being in a super specific place.
For example, before we were acquired by WP Engine, Local was actually completely compatible
with WP Engine’s backup format. You could easily drag any unsupported host or migrating a project for someone else. You can really quickly import the site and get it completely working in Local.
– Nice, Nice, all right. Let’s switch gears. This question is from Owen, doesn’t Local use VirtualBox?
– Super great question. So when Local started back as Pressmatic a few years ago, it did a VirtualBox at the time, was the best way to support a whole bunch of operating systems.
Over time though, we’ve seen and actually a year ago we made a huge decision to completely refactor Local under the hood and move away from VirtualBox towards native system level services.
There were a couple of things happening in the tech space related to this, specifically a Macos Apple was imposing notarization security requirements, which meant VirtualBox, basically wouldn’t pass those without the project itself passing notarization.
And we also sort of realized that, we’re sort of going out on a limb by relying on VirtualBox and Locals and established product, and it’s used by a hundred thousand developers or more and we need to own the core technology of Local.
So we spent the last year on our Local lightening project. And it’s actually, it’s a lot of work
to like essentially host a website on thousands of different computers and tons of different operating systems.
But we’ve successfully moved away from VirtualBox, and we run everything natively now. So we don’t use Docker, we don’t use VirtualBox, zero virtualization.
And as a result, performance has gotten a lot better, creating a site from a
blueprint, importing, exporting. All of those things in Local are a lot faster.
We have gotten some complaints that performance isn’t the best in lightening and that’s typically because of other applications, creating noise or traffic and other ports.
I’d be happy to help dig to the bottom of those challenges in our forums, but generally for most users, Local Lightning’s been a whole lot faster and more stable than the classic version that required VirtualBox.
– Yeah, that was a huge update in the Local universe. I know a lot of people I know were super excited for Lightning. I also personally experienced the performance boost between those versions.
I mean, it was very powerful. All right, so let’s ask the next question. Can I use Local for
non-WordPress applications and should I?
– Great question, so I, myself I’m trying to learn Laravel right now to try and build some more sophisticated just SAS projects on the side. And it is kind of possible to sort of hack together craft CMS and Laravel in Local.
It’s definitely not first party supported, but recently with our Local add-ons API, we significantly improved what’s available. So theoretically you could write a Local add-on that would automate support for non-WordPress sites, but a lot of Locals functions like MailHog and Adminer and things like that, do really only work for WordPress, but we’ve definitely explored and thought about supporting other CMSs or other developing frameworks like Lavarel.
And feel free to go into the community forums, We have actually a feature request board where you can up vote support for things like that.
– Where can people find the community forums? I don’t mean to put you on the spot, every URL memorize.
– No worries. So if you head over to Localwp.com in the upper right-hand corner
there’s a resources dropdown and you can find the community there.
And then we also, if you’re familiar with Canny, which it’s a pretty popular community tool now, Local also has a public roadmap on Canny where you can request features.
– Nice, nice I love that open roadmap and open feedback that’s incredible.
– Yeah, oh and just to add, our add-ons documentation is at build.Localwp.com. If you wanna get started building an add-on.
– All right, awesome. This next question is from Lauren McNamara. She says we’ve definitely have some issues setting up Local correctly when we need to pull in a clone of a site needing an update for build from scratch it’s been great, but I think I have a knowledge gap on proper setup for a clone pull.
– Totally, yeah, so we’ve seen bring Local to another host,previously Local only supported seamless push pull with Flywheel, bringing it to another host like WP Engine, is a pretty big undertaking, and we’re working as fast as we can.
We actually launched this as an Elfa last November, and then it was launched on February of this year. So it’s been sort of a long project for us and every single release we’re making improvements to the specifically in the WP Engine side the push and poll process.
Really early on, we didn’t support database prefixes other than WP underscore and really quickly we tackled that bugs since most database tables don’t have that prefix, but definitely reach out. And we can look at those logs and dig to the bottom of it.
I would update to Local’s latest version 5.5.3, where we fixed a lot of bugs related to the pull process. Sometimes if you delete like last Easter egg, if you delete the Emmy plugins directory,
won’t cause any issues when you push back up to WP Engine for that’ll sometimes fix things in Local.
– All right, next question is from Jaybe, he asks, “Does Local
integrate with an IDE, or can I use the IDE of my choice by second example PHP store?”
– Absolutely, yep.
So Local’s own engineers. I rely on PhpStorm when they’re doing PHP driven work,and we actually have an add-on to enable Xdebug within PHP storm.
So if you open Local in the left sidebar, there’s an add-ons button where you can go install the Xdebug add-on for Phpstorm, and just super simply configure that in those break points and have the two talk to each other.
We’re really close to also shipping an add-on for VS Code to unlock the same functionality.
– Oh, nice. Another question here from Christopher, is there anything we can do to increase performance for large enterprise sites running in Local?
– Totally, yeah, so actually one of the reasons we moved away from VirtualBox is even small sites, primarily page builder sites like sites built on Divi and Elementor.
They sometimes struggle from performance because page builders traditionally make a lot of database calls. And when you’re working on a computer, your own computer and hosting your site, database calls are an expensive computer operation.
For large enterprise sites, the best recommendation we can make is, to run that on like a quad core machine, so that the newer 13 inch MacBook pros come with quad core processors by default or more powerful computers like that.
Otherwise, sometimes what will happen is antivirus programs, or if you’re doing any sort of network or traffic monitoring, if you’re running something like McAfee Antivirus end points,
so those are all scanning traffic, even Local host traffic.
And that can slow down Local. Local lightning, like I mentioned a little bit earlier is spinning up native PHP and Nginx processes. So it should be way faster, but sometimes other applications
can interfere with that.
– All right, let’s switch things up. I’ll do one of my own.
So I know you’ve kinda been around with Local basically since the beginning. Let me understand, like, what was the idea initially? Like why did Flywheel decide to tackle this?
– Totally, yeah. So if you talk to Rick and Dusty,
they’ll actually say that, like the inception for Flywheel was, “Hey, we wanted to make it real easy for you to hand off client billing, and then we happened to build a hosting company.”
And they sort of joke similarly, like WordPress development’s a struggle. It would have been cool to tackle that problem and then happened to start a hosting company.
And I think it really goes back to this slide that we show a lot in Flywheel’s keynotes and webinars of the creative workflow. And in that creative workflow, there’s a build, launch and manage phase sort of towards the end of it.
And that build launch and manage is challenging for WordPress sites. Right, there is like WordPress has this database where content lives, and using get alongside it is hard, there isn’t package management or really version control by default with WordPress sites.
And so Local attempts to solve a lot of the build and some of the launch phase. But really, all of the other WP Engine products like Smart Plugin Manager pair well with that for the manage phase, and so I think it started out as we see this challenge of developers handing off billing to clients.
And part of that is even getting the site up online, and wanting to tackle that. So Local connect in that push poll feature launched in November of 2017, and that feels so long ago now, but it was crazy to think at the time that a website host that does things on the internet
was like, “We’re gonna build desktop software and like help you install something.”
Like that’s just…
And even today as a PM on a Desktop Software team, that’s still so unique, but it’s an opportunity to solve that really challenging problem of doing push pull and building a feature like Local Connect.
– Yeah, it was so helpful. I remember when y’all released that for the WP Engine platform, that’s when I became keep and dock official with Local ’cause I use it so often, and I like pinned it there to my dock and my neck.
I know it’s just such been such a relief and such an effortless experience, really for a lot of people.
All right, next question comes again from the audience and it asks, sockets have been broken for WP-CLI for some time, running commands like wp db import loses connection, will there ever be a fix or CLI option that isn’t dependent on WP-CLI’s lack of support for sockets?
So I’m laughing about this ’cause this has been a personal journey and struggle for me as
well as a Product Manager. So the first thing I’d say is the admin are ships by default
with every Local site, and it’s a lightweight alternative to phpMyAdmin for importing and exporting and managing your database.
But we know that people love being able to right click and just instantly open WP-CLI with the proper environment variables set. We actually had to go upstream to the WP-CLI project and contribute code to support Local socket connections.
And so that patch shipped, I think in in a couple ago recent, so not the most
recent WP-CLI release, but a couple of versions before that. And we just ingested that update into Local, and I believe that went out in Local 5.5.3.
So this has been a months long process for us to work with, Alan on the WP-CLI project who is actually Chris Wigman with WP Engine who patched it.
So it’s been sort of like a WP Engine community effort, WordPress community effort to get this patch, but yes, we’re well aware of it and it should be fixed in the next Local update.
– Yeah, I’m a big fan of Alan the lead dev of the WP-CLI project.
WP Engine actually sponsors along with others, Alan’s work on WP-CLI, so Alan if you’re
listening big props to you.
All right, so we just have a few minutes left.
So I’ll ask a couple more questions. This question comes from Chris and I actually really love this one ’cause it’s been a while since I’ve done client work, but I could see how this is
a big question for folks. “Any recommendations on developing locally while still allowing clients
to make WP content edits?”
– Super great question.
I don’t wanna to share my screen since we only have a couple minutes left. But we’ll be releasing a new feature, I think maybe it was teased this morning, Live Links Pro.
So Local has this fantastic feature called Live Links for you to share a random URL with clients
so they can preview your site. And it it’s powered by Grok currently, and Grok wasn’t purpose built for WordPress and WordPress sites load a lot of files and make a lot of requests for a single page load.
And oftentimes users will encounter a too many connections limit on loading their first page. And that’s simply because we rely on a free service provided by Grok.
Again, sort of a funny story a year ago, we realized, “Hey, we need
to own this experience because it’s not good enough.”
And so we’ve actually spent the last six months building our own tunneling solution. And so on June 22nd, as part of our big Local pro relaunch, we’ll be launching Live Links Pro, which will offer tunneled connections to your Local site.
So you’ll have a persistent URL that doesn’t change. Still random to protect it. It’ll have basic auth to protect you from SEO and bots and malware, but you can share that URL with other people, whether it’s clients for reviewed ad content and things, and have everyone working on the same copy of your site, but still as a developer, it doesn’t slow you down. You can still iterate locally and use all of the advanced tooling you’d like.
So Live Links Pro will enable you to create a tunneled connection from anyone else in the world
to your Local site. We’re super excited about it, stay tuned.
It’s kinda crazy, no one else has done this yet for WordPress, and so we’re pretty excited.
– Nice, cool stuff.
And thank you for clarifying June 22nd is the launch for Local Pro.
I misspoke earlier in my presentation today on Local, but thanks for clarifying that here.
Well, Jack, we’re kinda getting to the end of our time here kinda running out of
time for more questions, but if you do have more questions, there is a Local channel
in the WP Engine Summit Slack accounts, And make sure to go in there, ask questions there.
Jack, I think you’ll be on there later today, right?
I’m committing you now for–
– Scot and Mill will be around to your answer questions, but thank you all for attending this session and just WP Engine Summit in general, we have a lot more here in this track, so please stay tuned and thanks again for attending the WP Engine summit.