Category: Developer

  • Create a new public repository on GitHub without using the command line

    Create a new public repository on GitHub without using the command line

    How to create a new Public repository on GitHub so you can:

    • start coding on your development computers.
    • track revisions to your code and restore if needed,
    • share your open source code with the world, or a small team of developers.

    All of this, without using the command line.

    There are lots of great reasons to use GitHub to share a repository of your code, like:

    What you need

    Before you start, be sure that you:

    • Have a GitHub account set up correctly.
    • Know what language you want to use to develop your project.

    Git repositories (also called a “repo”) are easier to manage if you select a single development language.

    Your public repository needs an open source license

    These steps assume that you want to create a public repo, which means that anyone can view your code. This is ideal if you want to release your code as an open source project.

    An open source project must include an open source license. We recommend the MIT License to get started. According to GitHub, the MIT License is:

    A short and simple permissive license with conditions only requiring preservation of copyright and license notices. Licensed works, modifications, and larger works may be distributed under different terms and without source code.

    You may want to select a more restrictive license, like the GPL, but that’s a topic for another post.

    Or, you may want to keep your repository private, in which case you don’t need a license.

    The steps to create a private repository are therefore slightly simpler than the steps described here to create a public repo.

    Create a new public repository on GitHub

    To get started, log into GitHub.

    A sample Create a new repository page for an open source (public) project in Python
    1. In the upper right corner, next to your avatar, click [+] and then select New repository. The Create a new repository page will open.
    2. Name your repository.
    3. Write a short description. This will automatically appear in your new README.md file.
    4. Select Public, since this is an open source project.
    5. Select Initialize this repository with a README.
    6. Recommended – Add .gitignore: select your development language.
    7. Recommended – Add a license: MIT License
    8. Click [Create repository]

    At this point, your new repo contains three files:

    • .gitignore — tells Git to ignore certain files, like temp and cache files, that you don’t want to include in your repo.
    • LICENSE — contains the text of your actual open source license, including your name that you used to set up your GitHub account.
    • README.md — this file is the primary project documentation. Use it to:
      • describe your project,
      • list a version history,
      • keep important developer notes,
      • add links to other resources (like a project wiki and additional documentation).

    Now that your repo has at least one file, you can clone your repo to a local development computer.

    When you clone a repo, you can also create a branch. For more information on how to use branches (especially if you’re coding with others), review Hello World (GitHub Guides).

    Let’s keep it simple for now so you can:

    • start coding right away on your favorite development computer, and
    • use Git to track all the changes you make to your code.

    Clone your new public repository

    After you create a new public repository on GitHub, you need to clone it so you can work with it on your local development computer.

    In addition, you can apply these steps to clone any public repository on GitHub, too — not just repos that you create.

    Cloning a repo means you’re going to create a full copy of all the data in your repo — not just the code, but all of the different versions of the files contained within.

    Cloning a repo also means that you can contribute code back to the repo.

    If you just want to look at code in a repo, and maybe play around with it on your computer, then you can simply download a ZIP of the current state of the code files.

    Downloading a ZIP, however, means you

    • you don’t receive a copy of the version history,
    • it doesn’t allow you to use git to update the repo with your changes.

    Therefore, you want to clone your project so you can use git to:

    • track all the changes you make to your code
    • work with branches
    • collaborate with other developers

    So: clone your new repo to take advantage of all the features git has to offer.

    Select a connection type for your repo

    You can clone a GitHub repository using two types of connections: HTTPS and SSL. Both are secure, encrypted connections.

    HTTPS is easier to use, because:

    • You typically won’t run into a firewall blocking HTTPS connections.
    • You can use the handy GitHub Desktop app to clone your repo — no need to use the command line.

    To learn more about the differences between HTTPS and SSL connections to your GitHub repo, read Which remote URL should I use?.

    Also, you can always change your mind later and switch from HTTPS to SSL. For details, learn how to change a remote repo’s URL and connection type.

    Finally, If you are comfortable working at the command line, or you’d like to understand the specific git commands you need to clone a repo, check out Getting a Git Repository.

    To keep things simple for now, we’ll use the GitHub Desktop app to clone a public GitHub repo.

    Clone your new public repository with GitHub Desktop

    First, download the GitHub Desktop app to your Windows or Mac development computer.

    Note: if you’re using Linux as your development platform, GitHub Desktop isn’t available. But, you can select from a number of other Git GUI Clients.

    If you’ve followed the steps above to create a new public repo, you’ll have your new repo open in your browser.

    If not, just log into GitHub and click the repo name you want to clone to your computer. Or, find any other public repo you want to clone.

    Then, on the repo’s main page:

    1. Click the big green [Clone or download] button.
    2. Select either SSH or HTTPS as your connection protocol. I prefer SSH, but HTTPS is easier to start with (no SSH key required).
    3. Click the [Open in Desktop] link that appears.
    4. Your browser may display a Launch Application window.
    5. The GitHub Desktop app opens and displays the Clone a repository dialog box.
    6. Review the Local Path proposed for your new repo. If you’d like to change it, click [Choose…] and select the folder that you want to contain your new repo. In other words, your new repo will appear as a folder inside of the folder you selected.
    7. Once you’re satisfied, click [Clone].
    Use GitHub Desktop to choose where to store your new public repository on your development computer

    After that, the GitHub Desktop app will display a progress indicator, then the contents of your new repo. You’ll also see some handy buttons to:

    • launch your favorite code editor
    • view the files in the repo on your local computer
    • view your repo on GitHub.com

    Adding files and code to your new public repository on GitHub

    Now that you’ve set up a repo on your local development computer, you can start coding, or add existing files.

    Add existing files

    Use your favorite file management tool (such as the Mac Finder, Windows Explorer, the command line, whatever) to move files into your new repository folder. Then:

    1. open GitHub Desktop,
    2. commit the files to your repo,
    3. (optional) add a comment,
    4. push the changes to your master branch on GitHub.

    Start coding

    If you aren’t already, you should certainly use a code editor with integrated support for Git. This includes some terrific open source editors like MS Visual Studio Code, or Atom.

    So, you don’t have to use the command line to work with your repository, even after you start coding.

    When you open a folder that’s also a clone of a git repo, your code editor will automatically recognize that the folder is a git repo, because of the hidden .git folder contained inside.

    Then, you can fetch, commit, push, and pull your code to your repo branches in your code editor. All of this without having to enter any commands at the command line.

    Photo by Annie Spratt on Unsplash

  • Use git to develop WordPress sites with a team of coders

    If you work with a team of coders, you’ll want to use git to develop WordPress sites, themes, and plugins.

    Even if you’re the only developer working on a WordPress site, you’ll want to maintain a history of all the changes you make to your site’s custom code, using a source code control tool like git.

    If you’re working in a team, this history of changes is especially important.

    By keeping a record of each version of your site’s code, you can restore your work if anyone on the team introduces a show-stopper bug, or overwrites a file.

    That’s why you need to use version control software, like git, to develop WordPress sites.

    These types of software tools (also called “source code control”)

    help a software team manage changes to source code over time … Version control protects source code from both catastrophe and the casual degradation of human error and unintended consequences.

    What is version control | Atlassian Git Tutorial

    Remember, it’s always important to fight against “casual degradation,” in source code, at least.

    Using git

    This guide doesn’t teach you how to use git, but it teaches you how to use git with WordPress.

    If you aren’t familiar with git or source code control, first take some time to familiarize yourself with at least the basic concepts, and learn how to create a code repository on GitHub or BitBucket, and how to push and pull changes using your favorite git tools.

    There are lots of great lessons and tutorials about using git out there, and great tools for developers to integrate git into their development environment (two of my favorites are Visual Studio Code and Atom).

    To get started with git, you can check out our free guide on how to create a new public repository on GitHub without using the command line.

    If you don’t want to learn all the commands for the dread command prompt, there are also GUI tools for GitHub or BitBucket to help you manage your code repositories.

    Go ahead and learn the basics of how to use git. I’ll wait…

    Great! You’re back. By now, you should know the basics of git and source code control, like:

    • The location where all of your source code is stored is called a repository (or repo for short).
    • Your repo is comprised of at least one branch, the master branch, but you may fork your repo to create multiple branches.
    • To work with your git repo, you’ll pull, commit, and push your files.
    • You can put any kind of file into your repo, but git works best with text files (like source code, for example).
    • You can exclude files from your repo with the .gitignore file.

    If these terms don’t make sense, take a moment to go back and learn the basics of git.

    But if these terms do make sense, you’re ready to use git to develop WordPress sites.

    Do I have to use git and GitHub?

    No. You can use any version or source code control system you want to manage your WordPress source code.

    But, since the WordPress development team uses GitHub, and git is one of the most popular source code control tools, I’ll just use “git” as a short synonym for “the version control tool you’re using.”

    You can also use any code repository server you want. This includes GitHub, BitBucket, or your own code repository server.

    I’ll use GitHub as an example, but feel free to pick your own — use the one that’s best for your team.

    Using git to develop WordPress sites

    If you’re working on a development team and hacking reams of C++ source code files, it’s obvious what to add to git source code control: your source code!

    You might also want to add some script files, notes, and other source code and configuration files. That’s pretty easy to figure out.

    Not so with a WordPress project. A new WordPress installation includes many files and folders, plus lots of media files (images like .png and .gif files, maybe other media like .mp4 or .pdf files).

    Also, there’s a WordPress database file somewhere you need to copy, as well.

    To understand exactly which WordPress source files you want to put under source code control, you need to understand how a WordPress site is set up on your server. This server can be a development, staging, or production server — it doesn’t matter.

    Let’s look at the site structure from the point of view: what parts of the site change, and what parts don’t (or shouldn’t)?

    Which source code files (like .php, .js, .css) should you place under version control, and which can you safely ignore.

    A WordPress server setup: parts of a WordPress site

    Let’s look at the parts of a working WordPress site to determine what we can manage with git source code control.

    At the highest level, a WordPress server hosts:

    • the WordPress database.
    • WordPress files (including code and media).

    The WordPress database

    The WordPress database is already managed by a database server, like MySQL or Marimba (this depends on your server configuration).

    Don’t use git to manage your WordPress database, even though it might be a text file.

    The database file changes often, and can grow to become quite large. It’s best to use git with many small files — like, say, source code files.

    Also, using git to revert a database file to an older version can introduce all kinds of problems.

    Instead, use database tools, like phpMyAdmin, to backup your database. You can also use wp-cli to export your database, or a backup plugin to make a copy.

    It’s a good idea to back up your WordPress database at least once a day, using some kind of automated tool.

    The WordPress database is arguably the most important single file in your WordPress setup, so you can’t have too many backups.

    The WordPress software or your database administration software should make changes to your database file.

    It’s a bad idea to edit the database file directly. Therefore, it’s not a good candidate for version control.

    Besides, the WordPress database server is already set up to handle multiple users (for example, all the different accounts in your WordPress site).

    So, let’s leave the WordPress database aside, and look at how we can use git with the files in your WordPress website.

    WordPress files

    Let’s take a look at the files and directories installed on a WordPress server and organize them by the frequency of changes, and who’s changing them.

    Here’s a list of the files and directories in a brand new WordPress installation:

     index.php
 license.txt
 readme.html
 wp-activate.php
 wp-admin/
 wp-blog-header.php
 wp-comments-post.php
 wp-config.php
 wp-config-sample.php
 wp-content/
 wp-cron.php
 wp-includes/
 wp-links-opml.php
 wp-load.php
 wp-login.php
 wp-mail.php
 wp-settings.php
 wp-signup.php
 wp-trackback.php
 xmlrpc.php

    Only some of these files are good candidates for source code control. Let’s group these files based on how they change, if they should change, and who has permission to change them.

    The three categories of WordPress files are:

    • the wp-config.php file that stores the settings and configuration for a specific site, including how to access the database.
    • the WordPress core files: the exact set of files that are installed when you first create your site, and will be updated when you update WordPress.
    • your site’s unique content files, including plugins, themes, and uploads, all contained in the wp-content directory.

    Note that if your site has been hacked or compromised, your WordPress site may also contain another category: malware files. Unless you’re a computer forensic specialist or security researcher, you don’t want to add malware to your git code repository.

    Before you add your code to a repository, make sure it’s clean and doesn’t include malware. Better yet, rebuild your site on a development server to ensure it’s virus free.

    Don’t add these files to your git code repository

    Let’s eliminate all the types of files you don’t want to add to your code repository.

    wp-config.php

    Because the wp-config.php file contains the server specific settings for your WordPress installation, don’t put your wp-config.php file in your git repository — here’s why:

    • Since the wp-config.php contains the server specific user name and password to connect to your WordPress databse, you don’t want to share this sensitive set of credentials with anyone who doesn’t need it. It’s a massive security risk to add your wp-config.php file to your git code repository! Don’t do it.
    • One of the best reasons to use git with WordPress is so you can easily set up a copy of your site on a development server, make your changes to the source code, and then share them back to the code repository. This means your development server will have its own, unique, wp-config.php file. If you put the wp-config.php into your code repository, it can overwrite your local wp-config.php file and break your development site.

    So, just back up your wp-config.php file separately and securely. After your WordPress site is set up and you’ve confirmed it works, there’s rarely a reason for anyone except the site admin to change anything in wp-config.php.

    Also, wp-config.php is one of the primary targets for WordPress hackers, so you can’t back it up enough. But back up wp-config.php to some place safe, to prevent unauthorized access or accidental deletion.

    The WordPress core files

    You don’t want to make changes to the WordPress core files. Therefore, you don’t need to add them to your git code repository. Here’s why:

    • You can always grab a fresh copy of the WordPress core files from wordpress.org to ensure your site is running the latest version of WordPress. No backup required!
    • When you update your version of WordPress using the Adminstrator Update page (or wp-cli), the update will overwrite the outdated WordPress core files. This is exactly why you don’t want to change these files, either: any edits you make will be overwritten the next time you update the site.

    What exactly are the WordPress core files? It’s easiest to describe them by what they aren’t:

    • as noted above, wp-config.php isn’t really part of the WordPress core files, even though it’s part of the initial installation, because it isn’t altered when you install a WordPress update. Instead, it contains settings that are specific to your server.
    • The files in the /wp-content directory are where you’ll find the specific files that make your WordPress site unique: plugins, themes, and uploads.

    The “uploads” directory

    You’ll find the uploads directory inside of the /wp-content directory. Inside this directory (/wp-content/uploads), you’ll find all of the media you’ve uploaded to your site, organized by year and month.

    Like this:

     wp-content/uploads/
     └── 2019
         └── 07

    These are the media files you’ve added to pages and posts. These files include:

    • images like .png, .gif, and .jpg files.
    • other media like .pdf or .mp4 files

    These files are unique to your site, so you need to back them up. But, your uploads folder should never contain code!

    Code files include .php, js, .sh, and other script files that instruct your server to execute commands. There’s no reason for these types of files to be in your uploads directory.

    If you find code files in your uploads directory, it probably means your site’s been hacked. Time to clean that up!

    Keep in mind that your media files aren’t source code, but instead are (relatively) large static files that don’t change once you’ve uploaded them. This means they are poor candidates for version control.

    Instead, use a backup plugin or script to back up the uploads folder automatically. Because these files don’t include security credentials, you can share them widely with your development team, unlike wp-config.php.

    Great ways to share the uploads directory include:

    • Zipping up the uploads directory and sharing it on a web, FTP or file sharing server, and then sending out the link to the dev team.
    • Using rsync or SFTP to grab a copy of the files in the uploads directory.

    This leaves just the plugins and themes directories, inside of wp-content, to place in your git code repository.

    Let’s look at each individually.

    Use git to develop WordPress plugins

    If your team is coding a custom plugin, you definitely want to use git to develop WordPress plugins.

    But you don’t want to use git to manage other plugins you’ve installed from other, third-party sources.

    Only use git to manage your plugins if you are writing a custom plugin!

    The /wp-content/plugins directory contains all of the plugins installed in your WordPress site, active or deactivated.

    If you’re just using plugins that you’ve downloaded or licensed, there’s no reason at all to put these plugins in your git source repository.

    You don’t want to change the code in a plugin file that’s maintained by someone else: just like with the WordPress core files, any changes you make will be overwritten and lost as soon as you update the plugin.

    Pro tip: using wp-cli, write a simple shell script to install all the plugins you need for your specific WordPress installation.

    If you’re developing a custom plugin, create a project repository for it on GitHub (you can also use BitBucket or your own git server if you prefer). This way, you can give only your plugin development team access to the code.

    If your plugin contains some media files, they’re probably small and need to be included, so add them to your repository, even if they’re not files you’ll change often. That way, your dev team can find all the files they need to work on the plugin in one place.

    Pro tip: use your .gitignore file to keep development files out of your repository, like .tmp or cache files, that you might generate during development.

    Use git to develop WordPress themes

    Just like your site’s plugins, if all of your themes are from third-party developers, don’t put them under source code control!

    You don’t want to change the code in a third party theme, because your changes will be vaporized as soon as the theme is updated.

    But, if your team is working on customizing the appearance of your WordPress site, you’ll want to use git to develop WordPress themes or child themes.

    Use git to develop WordPress child themes

    WordPress child themes are the preferred way to modify an existing theme to preserve your changes when the parent theme is updated by the third-party theme developer.

    Use git to manage the code in your custom child theme.

    Because your child theme is stored in a separate directory from the parent theme, it’s easy to add only your child theme directory to a new git source repository.

    Use git to develop WordPress themes from scratch

    If you’re building a new WordPress theme from scratch, or based on a simple starter theme like “_s” then use git to manage the code in your custom theme.

    Just like your code repository for a custom plugin, your custom theme repository will benefit from a .gitignore file, to filter out unwanted development, temporary, and cache files.

    Also, do incorporate theme-specific media in your theme repository, so your development team can find everything in one place.

    But what if I want to use git for the entire wp-content directory?

    Just because adding the entire wp-content directory isn’t the most efficient use of git with WordPress, that doesn’t mean you can’t do it. There are advantages of putting all of wp-content into your git repository:

    • All of the files that make your site unique (except for wp-config.php — which should never go into your git repo) will be tracked in your repo.
    • It’s easy for a developer to recreate your site. All they need is a) a copy of the site’s WordPress database; b) a fresh installation of the WordPress core files; and c) access to the git repo that contains wp-content.

    But there are some disadvantages, too:

    • The files in /wp-content/uploads are typically much larger than all of the other files in wp-content since these files are typically larger images and other media files.
    • If you’re using a shared repository at GitHub or BitBucket, your costs may go up significantly if you need a lot of storage space.

    So, weigh the pros and cons for your team’s unique situation. If everyone is working at the same physical location, or if you have the technical ability (or good devops skills) you can set up your own git server and keep costs to a minimum.

    Also, if you want to put your entire wp-content directory in a git repo, your probably don’t want to share the repo with the public. Instead, set up your repo as private and only give access to the developers on your team.

    TL;DR: only use git to develop WordPress custom plugins and themes

    You don’t want to use git source code control for:

    • your WordPress database
    • wp-config.php
    • the uploads directory (unless you can set up your own git server, or don’t mind paying extra for more storage)

    It’s potentially expensive, or even disastrous, to manage these files with git source code control. Instead, back up these site-specific files with the backup tool(s) of your choice.

    Also, there are a number of files on your site that you don’t want to change at all, and can be easily replaced or updated. These include:

    • the WordPress core files
    • third party plugins and themes

    This just leaves two types of files for git version control:

    • custom plugin directories, and
    • custom or child theme directories.

    In both cases, set up a separate code repository project for each plugin, theme, and child theme. This way,

    • You can decide whether the project is private, or publicly available (if, say, you release your code with a GPL licence).
    • The project is focused and easier to understand.
    • You won’t be able to add any strange dependencies to your code repository
    • You can manage the team for each project separately.

    Alternatively, if you want to set up your own git server, or pay extra for storage, you can put the entire wp-content directory into your git repo — but you probably don’t want to share this repo as a public project.

  • Use vv to set up a new WordPress installation in VVV

    The vv script is no longer maintained, and this page is currently preserved for historical purposes. From the vv GitHub repo:

    This project is no longer maintained. Please update your copy of VVV , which has most of the vv features built in.

    from bradp/vv: Variable VVV – a VVV Site Creation Wizard.

    So many V’s! vv is short for Variable VVV, a VVV site setup wizard command line tool, automating the process of creating a WordPress installation in VVV. If you’re not comfortable working with the command line, this tool probably isn’t for you. But if you want to Use Varying Vagrant Vagrants (VVV) as a WordPress Development Environment, using vv to set up your virtual WordPress websites is incredibly handy and makes it much easier to automate common VVV website creation and maintenance tasks.

    The following instructions assume you know how to execute commands on the command line, using your computer’s Terminal or Command application. You also need to install VVV — see Using VVV for details.

    To get started, install vv. I prefer the git installation for my Mac development computer, but you can also use Homebrew. Follow the installation instructions for your OS.

    Using vv

    Once vv is installed, you can list the sites that are currently configured in VVV:

    vv list

    Create a new VVV WordPress site with vv

    To create your new VVV WordPress site, use vv create, like this:

    vv create -d example.com -n example

    Replace “example.com” with your production server domain for the -d(omain) parameter, and replace “example” with your domain root for the -n(ame) parameter. Or use the more readable version:

    vv create --domain example.com --name example

    When you run this command, you’ll need to answer a number of questions. If this is your first site you’re setting up with vv, the default options should work just fine.

    After vv provisions your new site, you need to complete one more step: Update the vvv-custom.yml configuration file to add the host entry for your new WordPress installation.

    First, make a clean exit from VVV:

    vagrant halt

    Then, open the vvv-custom.yml file in your favorite text editor. On my Mac, this file is located in ~/vagrant-local/vvv-custom.yml.

    Scroll down and locate sites: (or use Find) and then add your new site as follows:

    sites:
 example:
   hosts:
     - example.com
     - www.example.com

# Tip: add a blank line after your list of hosts

    Important: don’t use tabs to indent the entries! You must use spaces only or VVV will cough up an error message when you try to reload it (this is a requirement of the YAML file format).

    Save vvv-custom.yml and re-provision vvv:

    vagrant reload --provision

    Now, open your favorite browser, open an incognito or private window, and enter the domain you just created. Your new website should appear, with a generic WordPress installation. To log in to the WordPress dashboard, browse to:

    example.com/wp-admin

    and enter the admin account that vv created:

    • username: admin
    • password: password

    Obviously, you’ll want to change this before your site goes live!

    Now you have a virtual WordPress server that’s available any time you run VVV on your, and goes away whenever you halt VVV (but is still stored on your local drive).

    Delete VVV WordPress sites with vv

    VV can also delete sites. Deleting a website with VV is simple:

    vv delete site_name

    Don’t know the site name? Use:

    vv list

    If you delete a site using VV, remember that you’ll still need to edit the vvv-custom.yml configuration file manually to remove the host entry for the WordPress installation you just deleted. If you deleted a site so that you can install a new, clean version, just leave the entry in vvv-custom.yml and recreate the site with the vv create command.

    Advanced vv features

    One of the biggest advantages of using vv is automating common website deployment tasks with VVV. These advanced automation features let you:

    Check the list of vv Options and Commands to see a comprehensive listing of everything you can do with vv to automate site maintenance with VVV.

  • The VVV WordPress development environment: set it up on your computer

    The VVV WordPress development environment runs on your local development computer in a virtual machine (VM) so you don’t need to connect to a remote server to build your WordPress site.

    Varying Vagrant Vagrants, or VVV, is an open source project that runs on all major operating systems, including Windows, Mac, and Linux computers.

    Because VVV is a WordPress development environment that runs locally on a virtual machine (VM), there’s no network lag as you wait for your changes to be saved to the remote server … and then wait again to reload your pages to check your work. You don’t need a remote staging or production server to start creating your WordPress site.

    It also means you can develop your WordPress site without a direct connection to the Internet — although you’ll want to set everything up first while you are still online.

    VVV also works great with Git, to help manage you codebase and share your code with other team members.

    How does the VVV development environment work?

    VVV helps you configure new virtual WordPress servers quickly, so you can set up multiple WordPress VM local development environments on your computer easily.

    VVV needs two other components to work:

    • Vagrant
    • A Virtual Machine (VM)

    Vagrant is free, automated open source tool from HashiCorp for building and managing virtual machine (VM) environments. Since maintaining a virtual machine is at least as difficult as maintaining an actual computer, anything that you can do to simplify this process will make a huge difference in your productivity.

    To use Vagrant, you’ll also need to use a virtual machine environment (VM). VVV recommends that you use Oracle’s free Open Source VM VirtualBox.

    Get started with the VVV WordPress development environment

    To use VVV effectively, you’ll need:

    • a computer with a decent amount of RAM (at least 8 GB, but 16 GB or more is ideal).
    • a modern CPU that supports virtualization.
    • an SSD drive is optional, but recommended.
    • depending on the size of the websites you’re developing, you’ll probably want copious storage space.

    Install VVV

    Use the menu on the right side of the VVV website to complete the steps under the headings

    Once you’ve installed VVV, you’ll find a vagrant-local folder in your home (or user) folder. This folder contains all of the files the VVV web server uses to set up your development sites. You can access and edit these files any time, even if VVV isn’t running.

    Set up HTTPS

    This means you can connect to your local development site like this: https://example.com – especially handy when WordPress automatically generates links as you add menus, pages and posts.

    To set up HTTPS on your VVV development machine, follow the instructions for Setting Up HTTPS on the VVV site.

    TL;DR: add tls-ca to the core section of your vvv-custom.yml file and reprovision VVV with vagrant reload --provision

    Version 3 of VVV already includes this tls-ca addition the core section of your default vvv-custom.yml file, so you can use the https: protocol right away.

    Note that earlier versions of Firefox did not accept a self-generated certificate of the kind used by VVV.

    Now, you can also use Firefox to test your site on VVV using https connections — as with Google Chrome and Safari, warnings appear, but you can choose to proceed.

    Testing your new VVV local VM development environment

    If everything is working, this page displays a list of the active websites on your VVV installation, plus some other handy links to the tools installed on VVV, like:

    • phpMyAdmin
    • phpMemcachedAdmin
    • Opcache Status
    • MailHog
    • Webgrind
    • PHP Info
    • PHP Status

    Plus many more — see the VVV Software Packages section below for a complete list.

    Set up VVV WordPress websites

    This setup process essentially consists of adding a new site section to your vvv-custom.yml file, and then reprovisioning VVV with vagrant reload --provision

    Other VM development considerations

    • Back up your databases while your VM is running! Your updated WordPress database only exists in the VM. Use the included phpMyAdmin or WP-CLI to back up your database(s).
    • Always remember to exit VVV with vagrant halt to free up the RAM your virtual server uses, and to restore your host file to its original state.
    • Back up your development files in your vagrant-local folder on your development computer. One great backup option: use Git to place your code under version control.

    Working with SSH and WP-CLI in VVV

    • If you need WP CLI or PHP Codesniffer, or want to administer your virtual machine from the command line, run vagrant ssh (no password required). This drops you in the /home/vagrant user directory on the VM.
    • VVV maps the ~/vagrant-local/www folder on your development computer to /srv/www in the virtual machine. Simply enter cd /srv/www after you log into VVV with ssh to work directly with these files via SSH.
    • In the /srv/www directory, enter ls to see a list of all the sites that are set up in VVV.
    • Use the cd command to open a site directory. Once you’ve entered a site directory, you can use WP-CLI to administer that specific site.
    • When you’re done using SSH on your VVV machine, enter exit to log off of the VM and exit SSH.

    More Info on VVV

    Detailed information about VVV.

    VVV Software Packages

    1. Ubuntu 18.04 LTS (Bionic Beaver)
    2. WordPress Develop
    3. WordPress Stable
    4. WP-CLI (master branch)
    5. nginx (mainline version)
    6. MariaDB 10.1
    7. php-fpm 7.2.x
    8. memcached
    9. PHP memcache extension
    10. PHP xdebug extension
    11. PHP imagick extension
    12. PHPUnit
    13. ack-grep
    14. git
    15. subversion
    16. ngrep
    17. dos2unix
    18. Composer
    19. phpMemcachedAdmin
    20. phpMyAdmin (multi-language)
    21. Opcache Status
    22. Webgrind
    23. NodeJs
    24. grunt-cli
    25. Mailcatcher

    — from What is VVV? | Varying Vagrant Vagrants

    Relative and Absolute Hyperlinks

    The relative path replaces the protocol and domain with a single slash character (“/”). The absolute path to this article, for example, is https://cadent.net/use-vvv-as-a-wordpress-dev-environment/ and the relative path to this article is /use-vvv-as-a-wordpress-dev-environment/.