If you are considering using either of these free solutions for building websites locally, this guide will tell you everything you need know before making a decision. We’ll talk about what Local and XAMPP offer, laying out their features, advantages, and differences. Get ready for a detailed rundown.

Local vs XAMPP: Setup

Local and XAMPP are both powerful tools that share some common ground. Both are free to use, making them accessible to a wide range of developers. And, they both provide environments for local testing and development. 

Despite these similarities, Local and XAMPP differ significantly in their feature sets and approach. So let’s get started with a closer look at how the setup process compares. 

Local

To get started with Local, you’ll need to first visit the Local website and download the version compatible with your operating system.

Run the installer and follow the prompts. The process is intuitive, similar to installing any standard software.

Once installed, open Local. The initial setup involves a few basic configurations, like selecting your preferred language and agreeing to terms and conditions.

XAMPP 

Getting started with XAMPP is a similar process. Go to the XAMPP official website and choose the appropriate version for your operating system.

During the installation, you’ll select components like Apache, MySQL, PHP, and Perl.

After installation, use the XAMPP control panel to start Apache and MySQL services and set up your local server environment.

Local offers an easier, more streamlined setup process, ideal for beginners or those who prefer simplicity. XAMPP, while still accessible, requires a bit more technical involvement and is suited to those who want more control over their server environment.

Local vs XAMPP: Creating Development Sites

Once installation and setup is complete, you can move forward with creating your first development site. Here’s a brief rundown of how that works on both platforms.

Local

In Local, click on the button that says Create a New Site.

Enter the name and specify the local domain and path.

Choose between Preferred or Custom environments. The Preferred setup is quicker, while Custom offers more control.

Local automatically installs WordPress. You’ll just enter admin credentials to access your WordPress dashboard.

XAMPP

The process to set up a new site is completely manual in XAMPP. You start by launching the XAMPP Control Panel to activate Apache and MySQL. 

Then, you manually download WordPress and place it in the htdocs folder of your XAMPP installation. 

You also have to set up a database for the installation just like you would on a remote server. In XAMPP, this happens under http://localhost/phpmyadmin inside your browser.

Finally, to complete the setup, you navigate to localhost/your_site_name and run through the WordPress installation wizard. 

This process gives you full control over every step but requires more technical involvement compared to Local.

Local vs XAMPP: Importing an Existing Site 

Importing an existing site into Local and XAMPP involves distinct processes as well. 

Local

Importing a site into Local is straightforward and you have basically two options for doing so.

Using the Connect Feature

For WP Engine or Flywheel users, Local’s Connect feature lets you easily manage your site. Simply log into your account and upload or download your site directly from Local’s interface.

There’s also a MagicSync tool that helps you synchronize only the modified files instead of the entire site, streamlining updates.

Manual Import

For non-WP Engine or Flywheel users, manually importing a site into Local is simple, too. You’ll need a zip file containing your site’s SQL database file and wp-content folder. Drag and drop this file into Local, or use the Import option, and Local will handle the rest, including setting up the WordPress environment.

For more detailed instructions, check our Local import and export guide.

XAMPP

For XAMPP, the process is more manual and involves several steps.

You’ll need to prepare your WordPress site for migration. This typically involves exporting your WordPress database and compressing your WordPress files (especially the wp-content directory) into a ZIP file.

Once XAMPP is installed, you’ll need to set up a database for your WordPress site using phpMyAdmin and import your SQL database file.

Then, extract your WordPress site’s ZIP file into the htdocs folder of your XAMPP installation. You’ll then need to edit the wp-config.php file to match your database name, user, and password as set in XAMPP.

After moving your files and database, you may need to update the site URL and home URL in the database to reflect the local setup. This can be done either through phpMyAdmin or using a database database search-and-replace tool.

This method requires a more hands-on approach and is suitable for users comfortable with manual server and database management.

Alternatively, you can use a WordPress migration plugin to complete this task. A couple of options include All-in-One WP Migration and Duplicator, which simplify the process by handling the migration of files and databases automatically. They are particularly useful for seamlessly updating URLs and other settings without manual interventions. 

Local vs XAMPP: User Interface and Experience

When comparing the user interfaces and overall user experiences of Local and XAMPP, there are distinct differences worth noting.

Local

Local features an intuitive user interface that is neatly divided into three primary sections: Sites, Blueprints, and Add-ons.

• Sites – Here, you can easily manage your WordPress websites. The interface allows for quick creation, starting, and stopping of sites. You can also view each site’s details, including its URL, SSL status, and PHP version.
• Blueprints – This section allows you to save site configurations, including themes and plugins, which can be reused to create new sites quickly.
• Add-ons – This area provides access to additional features that can be integrated into your Local environment to enhance your development workflow.

Local’s interface goes beyond basic server management, providing a comprehensive tool set for site-specific actions, from easy access to the WordPress admin and database, to utilities for debugging and site performance.

XAMPP

XAMPP offers a more traditional user interface centered around its control panel.

• Control Panel – The main interface in XAMPP is the control panel where you can manage server services like Apache and MySQL. It’s functional and straightforward, mainly focusing on starting and stopping services, and checking server statuses.
• Server settings and configurations – XAMPP’s control panel provides detailed control over server settings and configurations. However, it doesn’t have an integrated interface for site-specific management like Local. Instead, you often have to edit system files manually.

XAMPP’s interface is less about website management and more about managing the server environment itself. It’s more suitable for users with a technical background who prefer direct control over server components.

Local vs XAMPP: Features and Functionality

Next, let’s compare the features Local and XAMPP offer.

Local

Local has the ability to switch between Apache and NGINX server environments with a click, accommodating various PHP versions. This flexibility is beneficial for testing your site under different server settings.

Setting up a new WordPress site is streamlined in Local as well thanks to one-click installation, making the process quick and efficient. This feature is particularly handy for developers looking to rapidly deploy WordPress sites.

Local includes SSL certificates, which allow for secure HTTPS connections for testing purposes. While they don’t secure the site in the same way as a certificate from a trusted authority would for a live site, they do allow you to simulate a secure HTTPS connection.

Another included feature is Live Link, which makes it so you can share your work effortlessly with clients or collaborators using shareable URLs. This feature eliminates the need for setting up staging servers, allowing real-time presentation of your local WordPress sites.

Additional Features of Local

Other notable features include: 

• HTTP/HTTPS tunneling – Enabled by ngrok, this allows your WordPress site to be accessed from any device with an internet connection, aiding in browser compatibility and responsiveness testing.
• Mailcatcher – Integrated into Local, it handles outgoing emails from PHP sendmail, useful for email debugging without overwhelming your inbox.
• Blueprints, clones, and exports – These features let you save your site as a template, clone sites easily, and export or import them with all configurations.
• Dev Mode and new site defaults – You can customize your environment (like PHP and MySQL versions) and use Dev Mode to prevent aggressive caching.
• Database connectivity and MailHog tool – These allow easy connection to your site’s database and the use of MailHog for testing transactional emails, streamlining processes for e-commerce sites.

For more details, check our comprehensive list of Local features.

XAMPP

XAMPP is a versatile option as well. It runs on multiple operating systems, including Windows, macOS, Linux, and Solaris, providing flexibility for various user environments.

It includes Apache, MySQL (now MariaDB), PHP, and Perl, making it a comprehensive web server solution. XAMPP also uses phpMyAdmin as a web-based utility for easy administration of MySQL databases.

Other features include: 

• Supports various CMS platforms – This includes WordPress, Joomla, Drupal, and Magento. 
• Application prototyping – Suitable for rapid prototyping of web applications in a local setting.
• Security features – Provides options for encrypting MySQL databases and setting passwords, enhancing data protection.

Local vs XAMPP: Site Management

As you might expect, managing sites varies between these solutions as well. 

Local

Local streamlines the site management process, particularly for WordPress users. You can easily navigate to the site’s folder or open a command shell with a single click. Quick access buttons are also available for the WordPress backend and the live site.

In addition, while in the Overview section, you can perform the following tasks: 

• Modify the site domain.
• Trust SSL certificates for browser safety.
• Change web server type and PHP version.
• Enable one-click admin login.
• Turn on Xdebug for PHP debugging.
• Update WordPress directly from Local.

The Database tab provides essential database details and a link to Adminer for management.

And the Tools tab is where you can set up and manage MailHog for email testing and use Live Links for external site access.

Right-clicking on a site offers more functionalities like starting/stopping servers, cloning, exporting sites, and saving as blueprints.

The hamburger menu in the upper left corner leads to settings, software updates, and log access.

XAMPP

XAMPP, being more manual, doesn’t offer too much in terms of site management. It basically consists of the aforementioned control panel where you can manage its different services. The panel also provides direct access to key components like phpMyAdmin for database management and it’s where you can configure and monitor logs and access settings for each service. 

However, that’s about it. Anything else you want to do always happens directly on the websites and their CMSs themselves.

Local vs XAMPP: Support

When it comes to support and community resources, both Local and XAMPP have unique support options.

Local

Local has a strong community and support system around it, making it an attractive choice for those who might need assistance or want to connect with other users. Here’s what you can expect:

• Community support – Local has a dedicated community forum where users can engage in discussions, ask questions, and find answers to frequently asked questions. This active community is a valuable resource for both new and experienced users.
• Documentation – On the Local website, you can find detailed help documents, providing immediate help for common issues and questions.
• Opportunities to get involved – Local also offers opportunities for Local users to give back to the community by writing a tutorial, building an add-on, or even speaking at a WordCamp.

You also get access to all of these support routes from inside the Local user interface.

XAMPP

​​XAMPP, while not having as centralized a support system as Local, does still have easy-to-find help resourced.

There is the Apache Friends forum, supported by users worldwide, with sections in various languages, including English. This forum is a valuable resource for troubleshooting and gaining insights from other users.

Here, the diverse, global user base surrounding XAMPP contributes to a wide range of discussions, covering various aspects of using XAMPP for different development needs.

Local vs XAMPP: Which is Better Overall?

After comparing Local and XAMPP, it becomes clear that each tool has strengths tailored to different user needs. However, if we were to lean towards one, Local is the favorable option for most people, particularly those working with WordPress.

Local excels with its user-friendly interface and simplified workflows, making it a standout choice for both beginners and experienced WordPress developers. Its one-click WordPress installation, comprehensive SSL support, and seamless integration with WP Engine and Flywheel enhance its appeal. And the supportive community and extensive documentation behind it offer valuable resources for troubleshooting and learning.

While XAMPP offers greater flexibility and control for diverse web development projects, its technical nature and manual setup process can be more challenging, especially for those new to web development or specific to WordPress.

That’s why Local presents itself as a more accessible tool, especially for those prioritizing ease of use, efficiency, and a WordPress-centric development environment. 

When it comes to Local vs XAMPP, which do you prefer? Please let us know (and why) in the comments below! 

The post Local vs XAMPP: Which Should You Use for Local Development? appeared first on Torque.

If you’re like me, you may feel intimidated by what I’ll refer to as “die-hard” developers—devs who are innately fascinated by development languages, patterns, and tools, particularly new ones. Watching the endless flood of new tools year after year (Grunt? Node.js?) can feel like falling further and further behind the “real” programmers.

The test of a new tool. . .

My advice for this situation is not to hide from new knowledge, or to rush into it, but to investigate exactly what you’ll have to put into, and get out of, learning a given tool. In other words: How is the new thing better than what you’re currently doing, and how steep is the learning curve to make the switch? If the benefits of using the tool outweigh the costs of learning it, then go for it! If not, it’s best to wait for the tool to get more useful or more intuitive, or for something better to come along.

. . .And three tools that pass it

The remainder of this article looks at three development tools that I personally love:

1. Sass
   • The default: CSS
     • Repetitive
     • Static
   • The fix: Sass
     • DRY (Don’t repeat yourself)
     • Dynamic
   • Getting Started with Sass
     • Sass compilers
2. Local Development
   • The default: Remote “dev” environments
   • The fix: Local Development
     • Why this is cool
   • Getting started with local development
3. Git
   • The default: Versioning chaos
   • The fix: Git
     • How to use Git (Or. . . How to use Git?)
     • Getting started
4. Conclusion

Each one of these tools—Sass, local development, and Git—really does make my life as a WordPress developer much easier. I’ll walk through each one with the idea that I’m pitching to pragmatists, like myself.

For each tool, I’ll try to explain the problems with the default it replaces, how the tool helps, and what you’ll need to understand to implement it.

1. Sass: The CSS preprocessor from heaven

THE DEFAULT: CSS

The default is, quite simply, CSS. CSS has two problems:

1. It forces you to repeat yourself.
2. It’s static.

I go into these issues in more depth in a recent post I’ve written, but here I’ll try to summarize them briefly.

Repetitive

For repetition, first look at the following markup:

.container { background: #fff; }
.container .box { background: #eee; }
.container .box .link { color: #333; }

Notice a lot of repetition? These styles are all properly related in a way that CSS simply isn’t able to capture, because every CSS style stands completely alone.

Static

CSS is also basically static, or unprogrammable. Let’s look at why that’s a problem:

.small-rounded-square {
height: 16px;
width: 16px;
border: 1px #333 solid;
border-radius: 1px;
}

.medium-rounded-square {
height: 32px;
width: 32px;
border: 2px #333 solid;
border-radius: 2px;
}

.large-rounded-square {
height: 48px;
width: 48px;
border: 3px #333 solid;
border-radius: 3px;
}

This also seems pretty repetitive, right? It’s not literally repetition, though, because every CSS styling rule is different from every other one. What’s predictable and repetitive is the relationships between styling rules. Unfortunately, CSS is static: It has neither variables nor functions that can use them, so it has no way to map the kinds of relationships that we see above.

THE FIX: SASS

DRY

Relative to CSS, Sass is extremely DRY (“don’t repeat yourself”). Sass solves the “Repetitive” example above as follows:

.container { background: #fff;
.box { background: #eee;
.link { color: #333; }
}
}

That’s much better, right? Sass has nesting, which lets us really clarify the relationships between CSS selectors, and cuts down on needless repetition. The Sass markup above will compile to the longer CSS, so your browser won’t know the difference.

Dynamic

Here’s how Sass might handle the “Static” example above:

@mixin rounded-square($side: 16px) {
width: $side;
height: $side;
border: $side/16 #333 solid;
border-radius: $side/16;
}

.small-rounded-square {
@include rounded-square;
}

.medium-rounded-square {
@include rounded-square(32px);
}

.large-rounded-square {
@include rounded-square(48px);
}

Without getting too technical, here are a couple of keys to reading the above:

• Anything with a $ before it is a variable.
• A mixin is a styling template, and it can take variables as arguments, just like a PHP or JavaScript function could.
• How you invoke a mixin is with the command @include.

One major advantage of this setup is that you centralize repeated relationships into one place, which is again much DRYer than CSS. Let’s say we want to give our squares dashed instead of solid borders: now we just change that once, instead of three times, and all our squares inherit that style.

Or let’s say your theme uses color #EF5223 (a dark orange) really often. Do you really want to write out that color hundreds of times in your CSS markup? It’s much better to centralize it into a single variable, $main-highlight-color, which you use across the theme. Then if you want the theme to be mostly blue instead of orange, you only have to change it in one place.

Another huge advantage of dynamic styling is that you can do things with variables. As you can see, the squares’ border-radius is set to be 1/16 of their width—a logical relationship that could hold across any width, and which we never have to manually define.

As another example, if you want to lighten your dark orange slightly to make it a better background for text, you don’t have to calculate new color values with some color software package—you just do background: darken($main-highlight-color, 10%). Again, this will still work even if you change everything from orange to blue. None of this is available in static CSS.

GETTING STARTED WITH SASS

Here are some tools on the basics of the Sass language:

• Sass and WordPress: A Love Story, by yours truly. Covers Sass’s role within WordPress and gives advice on getting started.
• Sass Basics: The official Sass documentation. A great place to start understanding the what, why, and how of Sass.
• “How To Use Sass With WordPress–A Step By Step Guide”: A general tutorial on Sass and WordPress. Includes Ruby command-line tutorials and a list of Sass compilers.
• “Sass for WordPress Developers”: A lot about organizing your Sass into separate partials, and about compiling Sass. Also has a list of tutorial resources at the bottom, to add some nice recursive-Sass-tutorial-link depth.
• “A Guide to learning Sass in 20 minutes or less“: An introductory tutorial on how to get started using Sass with WordPress.

Sass compilers

Perhaps the biggest obstacle to getting started in Sass is figuring out how to compile it — meaning how to programmatically turn it into the CSS that a browser understands.

The standard way is via command line, but if that’s too intimidating for you, there are some GUI-based compilers that make the process a lot less technical. The one I’ve tried is called Koala. It works great in Windows, and claims to do the same in Mac and Linux, as well.

2. Local development: Go away, Internet

THE DEFAULT: REMOTE “DEV” ENVIRONMENTS

In general, to see how a change to a website looks, you have to put the change online and navigate to it with a browser. The default for this is the following process:

1. Save edited file
2. Upload local file to remote server via FTP, overwriting the current version, if necessary
3. Reload browser tab to see new version of file

This is less than ideal for a ton of reasons, including, in no particular order:

• Someone has to pay for the hosting
• You have to be wary of both server- and browser-side caching
• You’re manually syncing two versions of a file, allowing for all sorts of mistakes
• A teammate with FTP access to the site can accidentally overwrite or otherwise ruin your work
• If you fail to take precautions your dev site can be seen by unwanted visitors, draw SEO juice away from the live site, etc.
• You can’t do development at all without a steady internet connection

But the most important problem with the flow above is simply that there are three steps, which require using three distinct programs (a text editor, an FTP client, and a browser) to make and view the simplest of changes. That’s an awful lot of work for a change like renaming an image’s CSS class from top-image to top-banner.

THE FIX: LOCAL DEVELOPMENT

Local development refers to setting up a server locally, on your personal computer. In other words, your computer becomes your web host, and you use your browser to view web files stored directly on your own computer.

For example, I’m writing this article (using WordPress’s beautiful but incomplete Front-end Editor), as a post on a WordPress site that exists only on my personal computer. That’s what the localhost:8080 in the URL bar means: the files are hosted (stored) locally, on the server that’s located on this computer, and accessed through that server’s port 8080.

Why this is cool

The first, most immediate benefit of local development is that changes to local files automatically sync to the server, because your local files are on the server. So making a change to a locally hosted site looks like this:

1. Save file
2. Reload browser tab

The change will show up in your browser, with no need to use an FTP client. Removing a third step and a third piece of software means that this process takes three seconds instead of twenty, which means hours of time saved across large projects.

A lot of the other advantages of this arrangement are the inverse of the problems with uploading to a remote server, but they’re still worth repeating:

• You can do web development with no internet connection.
• You’ll never lose a day of work because of a downed server—unless your computer itself is broken.
• Hosting’s free!
• You’ve got complete control over who sees and changes your project.
• You can test your project with different server configurations without having to buy a dedicated box.

GETTING STARTED WITH LOCAL DEVELOPMENT

• “How to run PHP at home: WAMP, MAMP and LAMP”: A great tutorial that will walk you through setting up a local server on a Windows, Mac, or Linux machine.
• Why You Need a Local Testing Server (and How To Do It): A verbose but good MAMP setup walkthrough with screenshots.
• Setting Up a Local Server for WordPress Development: A good WAMP setup walkthrough with screenshots.

3. Git: Smart version control for smart people

Version control, though Git, is probably the most technical of the three topics I’m covering today. It’s also very useful, so buckle up!

THE DEFAULT: VERSIONING CHAOS

Do any of the following sound familiar?

• Modifying a file, uploading it, and accidentally overwriting a partner’s changes to a different part of the file
• Multiple versions of a file, and you can’t remember which one is the “newest”
• Deleting some code that turns out to be really helpful and having to rewrite it from scratch
• Filenames like “style_old.css” and “index_final_before_redesign.php” cluttering up your filesystem

These are all examples of versioning chaos — the problem Git is designed to solve.

THE FIX: GIT

In a nutshell, Git creates a repository: a full record of all the versions of every file that are under version control, meaning that they are tracked in the repository.

Once this repository (or “repo” for l33t hackers) is set up, you can browse between versions at will. This lets you do things like:

• Compare all the differences between a file’s current code and its code at any point in the past.
• Restore any previous version of a file.
• Create a centralized repository (e.g. on GitHub) that everyone on the project can view, and that interacts with everyone’s local repositories.
• Track both the changes you and others make to a project’s codebase, including comments explaining the nature of the changes.
• Quickly and easily load the most up-to-date version of a project onto any location on your local machine.
• Create an entirely new branch of a project, which you merge back into the project’s core code once it’s ready.

How to use Git (Or. . . How to use Git?)

Now for the bad news: Git is hard to use. It’s a command-line tool by default, meaning you’ll be typing an awful lot of stuff that looks like:

git checkout -b old-state 0d1d7fc32

Git’s command-line flavor also means that some of the cool features of Git, like browsing version differences, are trapped in the Purgatory of ASCII –||– looking tables, substantially reducing usability.

Git is also just plain difficult to learn. It’s packed with obscure functions, terse error messages, and “gotchas” that break everything you try to do. More than that, Git itself is trying to solve a very hard problem: to record, organize, and reconcile every (possibly conflicting) change that anyone might make to a mass of code.

So Git is difficult to use, and very easy to get messed up in. For example, if you make changes directly to a file that’s in use by the remote master repository, Git gets very confused and you’re going to have a bad time. These types of snafus can be difficult for even a Git expert to fix, and if you’re new and get into deep water there’s a good chance you’ll give up long before you find your way out.

GITTING STARTED

To use Git, you’ll need to understand the core Git concepts:

• The basics of what a Git repository is
• Revisions, and the “Head” revision
• The Diff, Add, Commit, Push, and Pull commands

Please have these key elements in mind as you start to browse tutorial resources. Here are a few:

• “Getting Started” in the official Git documentation
• A list of Git graphical user interfaces (GUIs)
• A great introductory article, “Getting Started with Git”

In conclusion. . .

For my money, all WordPress developers should start to familiarize themselves with these or similar tools. None is a drop-dead necessity (in fact, I worked for a long time without any of them), but all three make life so much better in so many situations that they’re definitely worth learning.

So when you’ve got a spare afternoon and haven’t spent all your brain cells for the day on something else, why not crack one of these open and try learning it? You’ll be glad you did.

The post Truly useful WordPress development tools: Sass, local development, and Git appeared first on Torque.

In this article, I’ll introduce Vagrant, and I will walk you through setting up VVV, a popular WordPress vagrant setup.

The real advantage of Vagrant is that it’s totally customizable. This means you can emulate your production environment in your local development environment. When done right, this means no surprises when you go live.

Developing with the same technologies as you use on the live server can save you from running into bugs on your live site, which never happened locally since the situation that caused them doesn’t exist locally. For example, how can you know that your site has no problems with NGINX if your local web server is powered by apache? Or, how can you be sure your code is compatible with PHP 5.2 or 5.3, which many hosts still use, if you only tested it in the latest version of PHP?

What is Vagrant?

The heart of Vagrant is the vagrant file, which contains a recipe for creating and configuring the virtual machine. While this may sound tricky, and it probably is, don’t be scared. The internet is full of vagrant files and use-case specific vagrant systems you can download, which are ready to use with just a few commands. There are a ton of great vagrant setups that are designed especially for using WordPress.

Most importantly, for all of its power, Vagrant is pretty easy. There is no GUI for Vagrant yet. It must be operated from the command line. Don’t let that scare you. There are really only four commands you ever need to type: “vagrant up” to start vagrant, “vagrant halt” to stop it, and “vagrant provision” to add a new site, which is something I’ll discuss later.

Vagrant and the alternatives

Vagrant isn’t for everyone. I always say it’s the best, but not the easiest way to develop WordPress locally.

There are many GUI tools for creating WordPress sites using XAMMP or a similar technology—for example, DesktopServer by ServerPress, and AMPPS by Softaclous. DesktopServer allows you to easily create a local WordPress site. AMPPS, is very similar to the Softaclous module in cPanel, which allows you to create more than just local WordPress sites.

Services like DesktopServer and AMPPS are very easy to use and as an added bonus, DesktopServer even includes the ability to easily deploy your local site to a production server.

Beyond the customization offered by Vagrant, and the ability to create parity between local and development sites, is the portability. Sharing Vagrant sites is super simple. Since the configuration file and the rest of the site is all contained in one directory, you can send an archive of that directory to another developer. The only thing the recipient needs to do is extract it and run “vagrant provision,” and then they’ll be working in the exact same environment as you do.

WordPress vagrant solutions

Unsurprisingly, given WordPress’s popularity, there are plenty of great pre-built vagrant configurations for WordPress. I’m not going to compare them all in detail, for that you should see the comparison table of WordPress vagrant configurations that Micah Wood curates.

By far, the most popular WordPress vagrant system—and it really is a whole system—is VVV.

VVV, which stands for Varying Vagrant Vagrants, was started by Jeremy Felt at 10up, and is now a community project with many contributors from across the WordPress community. VVV comes preconfigured with four WordPress sites and makes it easy to add more. It also includes a long list of tools for modern WordPress development, from advanced object caching, to debug tools, to version control and dependency management.

The rest of this article will focus on using and installing VVV. Keep in mind that VVV might not be the right choice for you. One good alternative is Chassis. Chassis is sort of the anti-vvv. It’s designed to run one site per vagrant box. Chassis is configured to make it easy to mirror a production server in local development. This makes it perfect for when you’re writing code for a specific site and provides control over how it is configured.

Alternatively, if your concern is testing a theme or plugin in multiple “real world” examples, you should check out wp-vagrant by Bryan Petty. This setup allows you to run three separate virtual machines, each with a different version of PHP, but all sharing the same source files and database.

Installing VVV

Installing Vagrant itself is easy, just download it from VagrantUp.com and run the installer. Also make sure you have VirtualBox or some other compatible virtualization software installed. Personally, I use VirtualBox, though I’ve heard good things about using VMWare.

Before installing VVV, you’ll want to install two vagrant plugins. They are technically optional but make life so much easier. The first one, vagrant-triggers, allows VVV to backup your databases every time it shuts down, which is an incredibly useful feature. The second, vagrant hosts-updater, makes it easier to update hostnames.

To install these two plugins, simply open up your terminal and type:

vagrant plugin install vagrant-hostsupdater

And once that’s done type:

vagrant plugin install vagrant-triggers

Now you are ready to install VVV.

First, make sure you are in the root of your user by typing:

cd ~/

Now, if you already have Git installed, you can clone the VVV repository from GitHub by typing:

git clone https://github.com/Varying-Vagrant-Vagrants/VVV vagrant

You can also use VVV as a zip file, and unpack the zip file in a folder called “vagrant,” in the user root. Personally I prefer to use Git, so it’s easy to stay up to date with improvements to VVV.

Now in the terminal switch to the new vagrant directory by typing:

cd vagrant

From there, you need to do your first vagrant up. Vagrant up is the command that powers up Vagrant. The first thing it does is check if Vagrant is already provisioned. If it is, it loads the existing Vagrant box and you’re ready to work in about 10-20 seconds.

Since this is your first vagrant up, Vagrant will need to provision a new virtual machine. This can take a while, so unless you like watching commands go by in the terminal, now is a good time to go get a drink, or, if your internet connection is really slow, go get lunch.

Once its done, you should be able type http://local.wordpress.dev in your browser and see a brand new WordPress site.

Using VVV

By default, VVV gives you four sites. You can see the source code for each one in the www folder of the main Vagrant directory. That’s actually symlinked to the www directory of the virtual server. All you need to do is drop one of those directories into your IDE and you can start developing.

VVV provides four sites by default:

• http://local.wordpress.dev: The latest released version of WordPress
• http://local.wordpress-trunk.dev: The latest trunk (the “bleeding-edge”) build of WordPress.
• http://src.wordpress-develop.dev: The latest trunk build of WordPress plus files useful for core development.
• http://build.wordpress-develop.dev: This is for creating a build of WordPress trunk and development files via Grunt.

VVV adds a cool utility site at http://vvv.dev that has links to the default sites, as well as to phpmyadmin for database management, as well as utilities for monitoring the object cache and for accessing webgrid.

When you’re done with Vagrant, to shut it down, simply type in the terminal “vagrant halt” and it will shut down. You can also destroy your virtual machine with “vagrant destroy.”

For more information on using VVV, see the VVV wiki.

Adding custom sites to VVV

For some people the default sites may be enough. What makes VVV cool is that it’s very easy to add new sites to the existing vagrant configuration. There are lots of great add-ons out there, which you can use simply by cloning or downloading them into the www directory and then in terminal by typing “vagrant provision.”

There are many pre-built VVV site configurations you can use. For example, there is a theme review VVV configuration. It’s designed for reviewing themes for WordPress.org but makes for a perfect theme-development environment. There are also configurations that use composer for dependency management, and one that uses Facebook’s HHVM for improving PHP’s performance.

You can also create your own new site from scratch by adding a new directory to www with a few files. I have posted a GitHub repo with a boilerplate VVV new site configuration. You can use this as a starting point for your sites or modify it as need be. You should also check out this page in the VVV wiki for more information on this process and links to other starting points for new sites.

To use it, download or clone the repo into the directory you created and then make a few changes to the files. First, open vvv-hosts and set the url you want to use for this site, ensuring it ends in “.dev.” Then open nginx.conf, and on the line that starts with “server_name” change the rest of the line to the url that you set in the host’s file. Also, in nginx.conf, you will need to change the line that starts with “root” to point to the directory you’re using.

Lastly, open up the file vvv-init.sh. Currently, the name of the database is “site.” You will want to change that to something more meaningful. If you intend to import an existing database, you should set the database name to match the one you’re importing. You may choose to change the username and password for the MySQL user, but I generally leave it with the same user that the default VVV sites use.

Keep in mind that this configuration doesn’t actually include WordPress itself. That’s intentional, as how I add and setup WordPress varies from project to project. Often times I’m copying from a client’s live server. Other times I’ll install it via Git, or use composer to manage it as a dependency. How you add and configure WordPress is up to you.

This configuration will create an empty database. Once it’s done, you will be taken to the WordPress installer. If you’re copying a live site, you will want to go into phpmyadmin and import the database now. You can access phpmyadmin from http://vvv.dev/database-admin/ when Vagrant is running

Once you’re ready, go to the terminal and type “vagrant provision.” When it’s done, depending on your OS, your new site may be available to you at the URL you specified in vvv-hosts. If not, you will need to use vagrant halt and once it’s stopped vagrant up again.

Welcome to the world of Vagrant

If you’re still with me and you got Vagrant up and running, congratulations and welcome to the wonderful world of using Vagrant for local development. I know it can be frustrating at times, it sure has been for me, but using Vagrant and VVV has made me a better developer.

It’s a tool worth mastering if you want to get more serious as a WordPress developer, as you can use it to work more efficiently and solve complex problems more quickly. At the same time you can avoid issues that arise from using a development environment that doesn’t match your production environment.

Did you find this introduction useful? Share your thoughts in the comments below!

The post Getting Started with Vagrant for Local Development appeared first on Torque.