Tag: wordpress

  • 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.

  • Publish every day to send a flood of traffic to your site

    You want more traffic to your site. But no one knows your site even exists. What do you do to drive more traffic to your site? You can pay for traffic by running ads, or you can use content marketing to send organic search engine traffic to your site.

    Organic traffic is free, once you’ve spent the time it takes to create and promote the content. Paid traffic also requires your time to create content and promote it, but you have to pay for all of your traffic. Over time, free organic traffic will start to add up, from a trickle to a flood.

    How to create your content creation machine

    In his detailed and long (~6,850 words) post, How To Publish Like A Huge Content Creation Team (When It’s Really Just You), Niklas Goeke describes the process he used to:

    grow Four Minute Books to almost 30,000 visitors, 837 email subscribers, and a cool $736.00 in affiliate commissions in just 60 days.

    The key elements of his approach:

    Set clear goals and validate

    Because his approach is very labor intensive, it’s important to know that what you’re working on will pay off when you start getting traffic.

    • First, figure out why you want traffic (probably, money) and how you’ll make money.
    • Validate your idea before you start creating content.
    • Calculate how much you’ll need to sell each month to reach your financial goal.

    Build a system to streamline content creation, publishing and promotion

    If you want to succeed at publishing new content every day, you need a clear process, an “assembly line,” that will reliably result in a good post or article, without having to reinvent the wheel each time you start.

    This approach also happens to be a great way to learn about any subject, especially how it’s presented online.

    Plan and structure your posts ahead of time

    1. Use the “1-in-1-out” system to generate new posts: pick one piece of content — another blog post, a YouTube video, a question on Quora, an infographic on Pinterest — as the basis for your post. Write a summary, or a rebuttal, or your interpretation of the item. Spend a half hour reading or watching the original content (the input), and then spend a half hour writing about it (the output): 1-in-1-out.
    2. Plan at least one month’s worth of posts, and write your headlines, in advance. Use a spreadsheet to organize your post ideas.
    3. Create an “evergreen” structure for your blog posts — “a way to outline your blog posts that you can use over and over again” to ensure that you include the valuable elements that you need in each of your blog posts, without having to think about it.
    4. Include a “signature” graphic near the top of your post.
    5. Shoot for “roughly 1,000 words per post” — longer than a blurb or listicle, but shorter than the long form guides that take a long time to write.

    Perform basic SEO and keyword research

    Because of the volume of material you’ll be publishing, you don’t have to implement an elaborate SEO strategy.

    1. Perform simple SEO to identify basic keywords, and then tune up your headlines with the limited set of keywords you’ve identified.
    2. Check search volume on the Google keyword planner for your basic list of keywords.
    3. Check Google auto complete for any of your keywords that don’t show any search volume.
    4. Integrate your keywords into your content structure in a handful of critical places: the title or headline, slug, a couple times in the body text, maybe in a header, in the alt tag of your signature picture, and in your meta description (excerpt)
    5. Use Yoast in WordPress to make this easy.
    6. Overcome any deficiencies in your SEO by publishing a huge volume of blog posts.

    Collect emails

    It’s critical to collect emails. Use these three tools from Sumo:

    • Welcome Mat: display a simple pop-up with a simple giveaway to gather emails when visitors arrive at your site.
    • List Builder: show another pop-up when your visitors are about to leave your site. The Wait But Why popup is a great example.
    • Scroll Box: this pop-up appears when visitors scroll down the page.
    • Focus on making the text copy displayed in these pop-ups as convincing and humorous as possible.

    Promote

    Spend 10 – 15 minutes in a handful of channels, right after publishing, to promote each and every post you publish.

    Here’s what Niklas uses for his blog:

    • Submit to StumbleUpon
    • Submit to Hacker News
    • Post to relevant Slack groups
    • Send post to 1 person via email
    • Tweet at input creator
    • Buffer tweets
    • Check in on coach.me (or another community you’re a part of)

    Other options he mentions include returning to the content that you used as the inspiration for your “1-in-1-out” post:

    • Write a comment to the YouTube video you originally watched with a link to your posted response.
    • Republish your article as the answer to the Quora question that you wrote.
    • Respond to the Medium article.

    Once you develop your promotional checklist, which will be different for your audience, especially if it includes posts to online communities that are focused on the subject you’re posting about, save your checklist. Use a tool like Buffer to automate your promotional posts, tweets, and other social media outreach.

    Publish every day

    Now that you’ve built the machine, and tested it out, it’s time to go to full production mode:

    Read, learn, write repeat. The reason this system works so well is because you don’t have to think. In order to keep it that way, I suggest you create a rigid structure for your daily writing and stick to it like a monk to his monastery.

    Some tips to make your writing easier and more efficient:

    • Write at the same time every day. Put this on your calendar and stick to it.
    • Use the Pomodoro Technique to structure your “1-in-1-out” blog post production system. Use a 25 minute Pomodoro segment to read or view your input content, take a five minute break, then use another 25 minute segment to write your blog post. Then publish.

    This whole process should take about an hour and a half, once you’ve set up the machine and run through it a few times. If you do that every day for 30 days, that’s 45 hours out of your month.

    What’s great about this approach

    Although the original article didn’t discuss these benefits, there are other benefits to this kind of content marketing:

    • Learn about a subject. You’ll read, watch and review an enormous amount of material on the subject you’re positing about, and writing about it will help you master the material. Within a month or two, you’ll be an expert.
    • Develop ideas for information products, like online courses, videos, podcasts, or ebooks. You can sell or promote these new information products to your audience (you have lots of visitors and email addresses, if you’ve followed these steps) which will lead to more sources of income and more traffic.
    • Master the practice of publishing daily. If you are agonizing over your posts and find it difficult to press the publish button, this is a way to teach yourself how to write and publish, without getting hung up on trying to perfect what you’re writing.
    • Improve your writing. Writing every day will help you become a much better writer, especially because you’re publishing your work, and ideally getting feedback from your audience.

    I wrote post you’re reading now using the principles and guidance of the method in How To Publish Like A Huge Content Creation Team (When It’s Really Just You.

    This post is a mere 1300 words or so, where the original post is more than five times longer, at 6,850 words. That’s partly because the original post includes lots of valuable examples and links to other resources.

    If this post is helpful to you, I’d recommend reading the original article, and then get after it! Try it out. Learn something new while you build traffic to your site.

  • 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/.

  • Update an Existing WordPress Page

    To update an existing WordPress page on your site, first log in using your favorite browser.

    You can edit your site’s pages using a smaller screen device, like a tablet or a smart phone, but it’s much easier using a browser on your computer, or on a device with a larger screen, with a keyboard and a mouse. These instructions and screen images apply to that kind of setup.

    Find the Existing Page You Want to Edit

    To find an existing page to edit, from the Dashboard, select Pages : All Pages

    Pages are often organized by how they appear in your site menus. Pages with a dash prefix (like this: — Sample Subpage) appear as sub-menu items under the parent page’s menu item, which is listed above, with no dash next to the title (like this: Sample Page).

    If your site contains a lot of pages, you can also use the search box in the upper right corner to locate a page quickly by typing a search term. Type your search text in the box and click [Search Pages]. Shorter search terms will match more pages. Matching pages appear in the page listing below.

    To edit your page, mouse over the page title in the page listing and click Edit.

    Update the Page Contents

    On the Edit Page, you can update and format your selected page’s text, formatting, images, media, and page attributes.

    Page Editing Tips

    • Use the Visual editor to update the content on your page. The Visual editor is fast, accurate, and shows you a formatted version of your page. It creates pages that are quick to load and optimized for SEO. You can use other WordPress editing tools besides the Visual editor on your page, but the Visual editor is the first and best choice.
    • When you paste text into your page from other sources (like Word or other word processors) be sure to paste clean text to avoid formatting problems, and improve performance and SEO.
    • Format your text in WordPress so it’s easier to read, This will also improve your page’s SEO performance.

    Publish and Review Changes to Your Page

    After you’ve updated your page, you’ll need to save your changes so that they are visible to visitors to your site.

    To save and update your page, in the Publish box (top of the right hand column), click the [Update] button.

    Important: you must click [Update] to save your changes and see your changes appear on your site.

    After your page saves (updates), a message appears right below the Edit Page title:

    Page updated. View page

    Click the View page link to see your changes as they appear to visitors to your site.

    Click Edit Page on the WordPress Toolbar to return to the page editor quickly. Once you’re done editing your page, click [Update], then click any menu item on the left menu to leave the page editor. You can always go to the Dashboard, or click Pages : All Pages to view the list of pages in your site and select another page to update.