Create A WordPress Site With Lando

For local WordPress and Laravel development, I tend to use a Docker-based solution, most of the time. Depending on the project, I either use Lando or docker-compose. This post is about Lando.

Lando, is no DesktopServer. DesktopServer gives you a simple GUI for creating WordPress sites. Lando has no user interface, you do everything from the command line. That’s good or bad, depending on what you need.

This article explains how I create new sites for local development using Lando. You can see my current .lando file that I use for Caldera Forms development here.

Create The WordPress

Initialize lando in current directory:

lando init --recipe=wordpress

Add a WordPress:

wp core download

That downloaded WordPress core and setup wp config to match Lando’s default variables:

wp config create --dbname=wordpress --dbuser=wordpress --dbpass=wordpress --dbhost=database --skip-check

Add xdebug and MailHog and phpunit

Optional step, but it’s best before going further to add phpunit, MailHog and xdebug. MailHog intercepts all emails coming from the application and provides a webmail-like UI for reading the caught emails.

I love xdebug, I can’t imagine PHP development without it.

In order to run tests “The WordPress Way” you need phpunit installed globally. I disagree with this approach, but Lando makes it pretty simple to do, so fuck it. Here is a .lando.yml file that adds all of these things:

name: formcalderas
recipe: wordpress
config:
  env: dev
  xdebug: true
proxy:
  mailhog:
    - mail.formcalderas.lndo.site
services:
  appserver:
    composer:
      phpunit/phpunit: '*'
  mailhog:
      type: mailhog
      hogfrom:
        - appserver
      portforward: true

Build Containers And Start the site

lando start

This builds the new site and then shows URLs for the site.

At that point you have a WordPress at the URL listed for “APPSERVER URLS”. Click the https link and then finish installing WordPress through the UI. Alternatively use wp cli.

Chrome will not trust the SSL certificate. I normally just click the “Advanced” option and then tell Chrome to trust it. There is a better way to handle this documented here.

Path Mappings For xdebug In phpStorm

In phpStrom preferences go to Language & Frameworks > PHP > Servers and select the current server. Map the root directory to /app

Use It With Bedrock!

Bedrock, along with the Sage Framework is a great option for WordPress app development. Here is a guide to using Lando with Bedrock.

Also Great For Pantheon!

This article is about setting up local sites for general plugin development. We also use Lando for local development of the Caldera Forms site. CalderaForms.com is hosted on Pantheon. We git commit the Lando config file in the repo for the site. That way we have a shared environment and can pull database and file changes using Lando’s CLI, thanks to their Pantheon integration.

Learn more about Lando + WordPress here.

Using Dropbox To Keep VVV In Sync on Multiple Computers

Updated November 3, 2014 See below for a few issues we’ve come across.

I’ve been plotting for a while now to get a kick-ass desktop for development. Since I work once or twice a week at a co-working space and travel for WordCamps or to visit family fairly regularly, I’m going to need to keep my laptop for those situations. One of the things, besides clients owing me money that has kept me from getting said kick-ass desktop machine  is worrying about how to keep my development environment in sync between the two machines.

Lucky for me Scott Kingsley Clark, figured out how easy it is to keep VVV in sync between his shiny new iMac and his laptop. Scott was kind enough to share his strategy with me, which I have tested with a loaner computer and found to work very well.

Before We Get Started

I’m assuming that you’re already using VVV and are familiar with it. If you’re not, you should probably be reading my guide to getting started with VVV for local WordPress development instead.

Since you’re familiar with VVV, it’s a safe assumption that you know to install Vagrant itself and a Virtual Box or some other VM software on both computers. Right?

You can either use an existing VVV setup or create a new one for this. In this guide, I will be starting from scratch, but you could also do the same thing by temporarily moving your existing one into your Dropbox folder instead of creating a new one.

Also, for this guide, I will be calling the vagrant folder dvv, for Dropbox Varying Vagrants. You can call it whatever you want.

Setting It Up

Install VVV In Dropbox

The first step is to clone VVV itself into Dropbox:
cd ~/dropbox
git clone https://github.com/Varying-Vagrant-Vagrants/VVV dvv
You could also download the ZIP and extract it in Dropbox.

Symlink VVV Folder

On both computers you are going to want to symlink the VVV folder with a folder in your user root. This is mildly optional, as you could just work out of Dropbox. Personally, I agree with Scott on symlinking, as I love the ease of being able to cd directly into my VVV from a new bash shell. It’s a little thing, but I have to do it after every restart.

If you’re using an existing install, this step is extra important as it let’s you put the install back where you found it on the originating computer.

You must do the symlink on both computers:
ln -s ~/dropbox/dvv ~/dvv

Vagrant Up

On the remote machine you do a new vagrant provision and that’s it you’re good to go.

What This Doesn’t Do

This does not keep the virtual machines themselves in sync. I don’t think it makes any sense to do so, though I’m sure it’s possible. That means whenever you make changes to your configuration or add a new site, you will need to do a new vagrant up on the other computer.

Also, since the database is in the virtual machine. It does not keep the database in sync. If you have the Vagrant Triggers plugin installed you get a database backup every time you vagrant halt. You can use that to rebuild the DB when doing a new vagrant up or vagrant provision.

That’s Actually Very Simple

That’s it. Turns out this is very simple,  Scott’s pretty good at creating ways of making WordPress simpler.

OK, Maybe Not That Simple

Here are some caveats that Scott has discovered since starting to use this strategy since implementing Dropbox to sync his VVV between two computers:

1. My virtual machine tends to be recreated from time to time, forcing 100% install over again when doing a `vagrant up`, this is likely because some files synced by Dropbox are unique to the computer, and keep changing between ‘up’s on the different vagrants.

2. Because of the virtual machine recreation, DB changes can disappear and most commonly be restored by Vagrant during it’s provisioning. It’s important to note that when you use `vagrant halt`, it will backup the databases on the current virtual machine, and on `vagrant up` (first, or `vagrant provision`) it will attempt to restore those DB .sql files on the other machine.

Approach with caution, I currently now believe the best way to sync VVV is to limit the sync to the `www` folder, not the entire VVV folder contents.

WordPress 3.9 Is Coming: Get Ahead Of Any Suprises

WordPress 3.9 is due to be release on April 16th and there is no reason why you should be surprised by any changes or plugin or theme compatibility issues. If you don’t have a local testing environment, ie a version of your site running on your personal computer, yet, now is the time. A local test site is easy to create and it allows you to test out changes to your site without risking anything that goes wrong being broadcast to the world or taking down your site.

Clone Your Site

duplicatorThe easiest way to make a copy of your live site is with the plugin WordPress Duplicator.  Simply install this free plugin via the plugin installer in WordPress and use it to create a new installer. Don’t worry about any of the database settings. Just go to the “Create New” tab, give the package a name, click the “Skip Scan” option and click the blue “Next” button. Download the package and then delete it from your server.

If you haven’t already installed DesktopServer by ServerPress do so now. DesktopServer is the easiest way to create a local development and testing site for WordPress, which is something everyone should be doing. From the DesktopServer UI, you simply select “Export, import or share a website” and then the “Import an existing WordPress website archive” options. You will then be given the ability to navigate to the file you downloaded from WordPress duplicator, and the address and location for your new local site.

It’s really that simple. If you need more detailed instructions, see this tutorial.

serverpress-install

Install The WordPress Beta Tester Plugin

There are a lot of ways to get the latest development version of WordPress. The easiest is by installing the WordPress Beta Tester Plugin. Install the plugin in your test site and from its settings set it to “bleeding edge nightlies.” Save the plugin settings, update WordPress and you are now beta testing the most popular content management system on the internet.

Now What?

Make sure that you have WordPress’ debugging mode activated by setting WP_CONFIG to true in your test site’s wp_config.php file, by adding this code:


define('WP_DEBUG', true );
define('WP_DEBUG_DISPLAY', true);
define('WP_DEBUG_LOG', true);

Now navigate to your test site in your browser and see if you can generate any errors on any of your site’s pages, front-end or in the admin. Be sure to check any forms, widgets, media players, JavaScript-powered do-dads or anything else that could break. If you see any errors, you should report them in the appropriate location, either the theme or plugin developer’s support forums or if you have found a bug in WordPress itself, report it in core trac. Always be sure to search for reports of similar issues before creating new tickets.

If everything works, you can safely upgrade your production site to WordPress 3.9 when it’s released. If not, you can use your new local environment to test any fixes to the problems that you have identified that you are provided before implementing them on your live site for the whole world to see.

Bonus: You Now How a Testing Environment For Your Site!

Not only have you saved yourself from any surprises when you upgrade to WordPress 3.9, you also have one of the most important tools that any WordPress site owner should have: a local testing environment for your site.

Three Things I Wish Someone Had Told Me When I Started Doing WordPress Development

Like most people, I started learning WordPress development by downloading files from the theme I was using for my site, editing them, and then uploading them back and seeing if what I did worked–on my live server, via FTP. Experience developers will shudder at the thought, while newcomers to the exciting world of WordPress development are probably asking why not.

You may think that the things I’m laying out in this article are optional things, not worth taking the time to learn, but they are worth the investment in your time. I’m not saying that because you will get the time spent learning how to do these things back 100-fold or more as they will make you a more efficient developer. No, the real reason I think you must do these things is that it was only once I started doing these things that I started to get any good at WordPress development.

My system might not be the most efficient, hell I’m not even using Grunt, yet, but once I started developing smartly–ie locally, with version control, and using the debug bar, I was able to concentrate on what I was doing, not how I was doing it. I got more done, solved more problems and was able to actually accomplish something.

So, I want to share the three biggest things I wish someone had told me when I started doing WordPress development, in hopes that others will read this and skip as much of the struggles I went through when I started.

What I Wish I Had Known Then

Develop Locally

serverpressLife is too short for regrets, but I regret the amount of time I wasted by developing on a remote site. All of the time I spent uploading a file–from a different program than I was writing the code in since I wasn’t using an IDE–refreshing my browser page, waiting for it to load, I want that back. I wasn’t just wasting time, every time I broke my site, I was showing the error in my site or presenting a broken version of my site to the world.

If you’re still developing on a remote site , stop. Clone your remote site using WordPress Duplicator, and import that into a local site using DesktopServer. Once you start developing locally you will never go back. Being able to click save and immediately see the changes–well after a browser refresh if you’re not live reloading your browser–will improve the quality of your life. Seriously, spend less time breaking your live site, waiting for files to upload and dealing with caches, and more time developing.

By the way DesktopServer is the easiest, but not the best or fastest way to create a local development and testing environment for WordPress. Vagrant is better, but harder to set up. Keep that in mind.

Use The Debug Bar Plugin(s)

The plugin Debug Bar and its many add-ons, especially the Debug Console plugin is another one of those that will allow you to do the same thing that you had been doing more efficiently. The debug bar plugin by itself gives you an easy way to see your PHP debug errors, and get some info about the current query, but the add-on plugins are what makes it really shine.
The debug console lets you execute any PHP code and see what happens. Any errors you create will show in the console, and will not break your site. Debugging is all about testing your assumptions. For example, does a piece of code generate the output you expected? Does an option contain the data you expect it to? The debug console, not your current theme’s header.php is the place to do this detective work.

When developing, it is important to work through problems systematically, making sure that every part of your code does what it’s supposed to do and creating the expected output is important. The quickest way to do this process is drop the code into the debug console, and print_r() or even print_r2() the results. Using the console means there are no page refreshes involved.

Use Version Control

sourcetreeDo you make mistakes? So do I, but it doesn’t bother me since everything I do is under version control. Using version control means that you can revert any change you made to a file, even if you’ve made 100 changes since then, without loosing those other changes. It also means you can start your projects by “forking” other people’s work, and it means you can contribute to other open source projects.

Do you have a subfolder of every project you are working on filled with files with names like “index.php-9:14pm” and “single.php-before-adding-new-sidebar” and such? I used to. Then I started using version control.

Using version control isn’t hard since there are great GUI tools for Git, the best version control system that also happens to be the technology that powers the source code hosting and social code sharing site GitHub. I use SourceTree for handling version control, but others like Tower or the GitHub app.

What Else?

I’m sure there are some advanced developers out there reading this, yelling at their screen about what I didn’t cover. For example, using an IDE. Set me right in the comments.