Category: Tools

  • Why Markdown Is the Best Way to Write Web Pages

    Why Markdown Is the Best Way to Write Web Pages

    Tired of reformatting documents for your website or your blog? Maybe you don’t want to have to learn how to use another online text editor just to write a post. Then use Markdown to write your web pages.

    Do you write for the web? Do you post to any of these?

    • a static HTML site
    • a WordPress blog
    • Medium
    • any other online platform

    If you do, wouldn’t it be great to be able to create well-formatted web pages without having to learn how to use a bunch of different online editors?

    Enough with the reformatting — I just want to write a web post

    Have you ever converted a file that you wrote using your favorite word processor, like Microsoft Word or Google Docs, only to discover that your new page won’t format correctly on your website?

    Maybe you looked at the HTML code and discovered a bunch of formatting tags all over the place that you never added in the first place?

    No problem, you say, as long as it looks OK, I don’t care about all the extra formatting. The problem is, all of these extra formatting tags increase the size of your page, which slows down the performance of your site.

    Also, if your page has extra formatting embedded in it, the page might look fine on your computer’s browser, but might turn into a hot mess when you display it on a mobile device with a smaller screen.

    Maybe you manage a WordPress site and one of your writers sent you a Word or Google doc — now you want to post it, but when you convert it to HTML you get a massive file full of formatting tags.

    Even worse, now the new page doesn’t look like any other page on your site. Instead of pressing Publish, you need to spend hours reformatting the page to make it consistent with the rest of the site … and there’s still that one section that won’t format the right way.

    All of these problems stem from the same cause: most major word processors embed all kinds of specialized formatting tags into the HTML documents they produce.

    If your ultimate goal is to post your document to a web page, these custom formatting tags are a nightmare to clean up. In fact, for Microsoft Word, this type of reformatting is such a problem that there are countless specialized sites that will convert your Word documents to “clean” HTML.

    But why add an extra step when you don’t have to do that? If you want to publish new content frequently, every extra step in your workflow makes it more difficult to finish a new post.

    Too many formatting choices

    Another problem with using word processors to create web pages is this: the typical word processor presents many formatting options that simply don’t exisit in HTML, or are very difficult to reproduce.

    For example, you may specify certain type faces and sizes (fonts) in your Word document, only to find out that they simply don’t match any of the typefaces you’re using on the website where you want to publish.

    What if you could use a simple text editor, like vim, to write all of your documents, and format them in a way that would produce clean HTML? That way you didn’t have slog through a huge checklist of steps just to convert the document to HTML, and then have to convert it again to clean up the HTML.

    That’s why I use Markdown to compose all of my articles and documents I want to publish on the web.

    I can create Markdown files in any text editor or word processor, and save the file as a simple text file — usually, with the .txt extension, but I’ll use the .md extension if it’s formatted with Markdown.

    In either case, the file contains only text (letters, numbers, punctuation) with no special or proprietary formatting codes or tags.

    Your blog may already know Markdown

    Most blogging platforms, like WordPress, will format your Markdown document if you just paste it in to the editor.

    For instance, you can type or paste Markdown directly into the WordPress editors (Classic or Gutenberg) to format your text, without having to take a special trip to the toolbar with your mouse to create, say, a bullet list.

    If your favorite blogging platform won’t read Markdown directly, there are plenty of free tools to convert your Markdown file to clean HTML, without introducing any extra formatting tags into your document.

    Keep your fingers on the keyboard: use Markdown to write web pages

    After I learned how to compose in Markdown, it became the easiest way for me to write web pages.

    Why? Because I can keep my fingers on the keyboard, and just type.

    If I want to format some text — say, to make the text bold, or a level 2 heading, or to create a bullet list — I don’t have to take my hands off the keyboard and move the mouse up to some toolbar, after I select the text.

    I don’t have to memorize a different set of keyboard commands to format the same kind of headings in different online editors.

    And I don’t have to remember to press the Command key if I’m on a Mac or the Ctrl key if I’m on a Windows or Linux computer.

    I just type.

    That’s because Markdown is basically a way to format text by typing in simple, easy-to-remember characters.

    In fact, you may already be using a form of Markdown if you’re using Slack or Discord, or other online chat tools that support simple formatting.

    How does Markdown work?

    The best way to understand how Markdown works is to see it in action. Let’s take a look at some simple Markdown formatting.

    For example, if you want to make text bold, you simply surround it with two asterisks, like this:

    here's some **bold text**!

    That text will look like this on your blog:

    here’s some bold text!

    Italics is even easier:

    let's make _this text_ italic!

    That Markdown text will appear like this:

    let’s make this text italic!

    You can easily create blockquotes:

    > Just add an angle bracket at the beginning to make a blockquote.

    That Markdown text looks like this:

    Just add an angle bracket at the beginning to make a blockquote.

    See? It’s simple.

    If you want to get started with Markdown, check out the open source (and free) Markdown Guide.

    Keep it simple

    Another handy thing about Markdown: it’s designed to be “human-readable.” That means you can read the original Markdown document and figure out the formatting — you don’t even have to convert it to HTML to understand how it’s formatted.

    Markdown formatting is, of course, limited. That’s the whole point. You won’t be tempted to do any excessive formatting in Markdown. You (or your webmaster) should be implementing all of your site’s formatting using CSS anyway, instead of using the embedded <span> tags that so many word processors insert.

    Use Markdown to write web pages: structure, don’t format, your documents

    When you Markdown to write web pages, you have to focus on the structure of the document, not the appearance. This is how HTML was designed to be used: HTML files should contain only the document’s text and its structure, and CSS should contain all the document’s formatting.

    In other words, you can use Markdown to define headers, lists, hyperlinks, blockquotes and even boldface or italic text (the document’s structure) but not to define the colors, fonts, text or margin sizes, or any of the the document’s formatting — all of that formatting belongs in your site’s CSS files.

    A well-structured web page is easier to read and understand, and this in turn improves your SEO. Separating your pages’ structure and formatting makes it easier to update the appearance of your site, too. Using Markdown to write your web pages helps you achieve these goals, and makes it easier to publish clean, fast-loading HTML, which also improves your search engine rankings.

    To learn more about the development of Markdown, check out the Markdown page on Wikipedia that describes the history and various implementations of the Markdown syntax, plus the many software libraries available.

    Featured image by Windows on Unsplash

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

  • bash for loop: apt-get Linux system update and upgrade

    Here’s a little bash gem for updating Ubuntu (or, really, any apt-get box). Check out the sweet bash for loop:

    sudo bash -c 'for i in update {,dist-}upgrade auto{remove,clean}; do apt-get $i -y; done’

    This single line bash command to runs a complete apt-get update that’s essentially a one line compression of this multi-line bash script:

     sudo -s -- <<EOF
 apt-get update
 apt-get upgrade -y
 apt-get dist-upgrade -y
 apt-get autoremove -y
 apt-get autoclean -y
 EOF

    from Ask Ubuntu – How to install updates via command line?

  • WordPress.com Two Step Authentication

    If you’re using WordPress.com, or Jetpack with your WordPress.com account, protect yourself by setting up WordPress Two Step Authentication.

    In fact, you should use Two Step Authentication (also known as Two Factor Authentication) for every website that supports it, especially your social media accounts, your Gmail account, financial websites like your bank, and any other website where losing control of your account would be a disaster.

    Here’s how it works:

    1. You set up your WordPress.com account using a strong password or passphrase.
    2. You tell WordPress.com about another device you control, (usually your smartphone), and use that device to receive a second authentication code.
    3. You enter this second code after you enter your user name and password.

    It’s this second step of entering the second code that dramatically increases the security of your login. It turns out that passwords are pretty easy to guess, especially if you use a computer to help guess it. This is called a “brute force” attack. Because the additional, second code is generated right when you need it, and isn’t saved, there’s no way to guess the code. Also, you presumably control your smartphone, and that’s not something that a hacker on the other side of the planet has easy access to, either.

    If you’re using your smartphone as an authentication device — and that’s really the best choice, because you probably carry it with you everywhere — you’ll want to secure your smartphone, too. At the very least, set up a password on your phone, and use Touch ID or Face ID to unlock your phone. If you want to secure your smartphone to the highest degree possible, use only a password to unlock it (not Touch ID or Face ID) and use the longest password you can stand to type in each time you unlock your phone. Also, set up your phone to automatically erase itself if there are too many attempts to unlock it unsuccessfully.

    So, your smartphone is secure and you want to use Two Step Authentication. Here’s what you do:

    • Install the Google Authenticator app (Apple or Android). If you can’t install or run the Google Authenticator app, you can still use SMS (texts) to receive authentication codes, but this option is not as secure.
    • Install the WordPress app (Apple or Android). Once Two-Step Authentication is set up, you can also use the WordPress app to authenticate, without having to type in an additional code.
    • Visit the Two Step Authentication settings page for your WordPress.com account. Note that you may need to log in to your WordPress.com account to view this page.

    Set up Two-Step Authentication

    Once you’ve opened the Two Step Authentication settings page you can set it up using Google Authenticator:

    1. Click Two-Step Authentication then Get Started]
    2. Select your Country Code and enter your Phone Number for the mobile device you want to use to authenticate your account.
    3. Click Verify via App (or, if you can’t use Google Authenticator, click Verify via SMS and follow the instructions below for SMS authentication).
    4. Open the Google Authenticator app on your phone.
    5. Tap the “+” symbol and then tap Scan barcode
    6. Use the barcode scanner to scan the QR code that WordPress.com displays. If this works, Google Authenticator displays a new six-digit code for WordPress.com
    7. Enter the six-digit code on WordPress.com and click Enable.

    Now, WordPress.com will display a list of backup codes and ask you to print them. I prefer to copy them and paste them into the Notes field of my password manager. Either way, save your backup codes! You’ll need them if anything happens to your phone.

    Click [All Finished] after you’ve printed your backup codes, or pasted them into your password manager.

    Backup Codes

    If for any reason you didn’t save your backup codes in your password manager, or print them out, it’s not too late!

    On the the Two Step Authentication settings page, scroll down and click the [Generate New Backup Codes] and print them or save them in your password manager.

    Copy one of the backup codes and paste it into the Type a Backup Code field. Click [Verify].

    Use SMS Codes

    If you can’t use the Google Authenticator or another app like Authy, you can use SMS (text) authentication instead. When you’re setting up Two-Step Authentication, click Verify via SMS instead of Verify via App. You won’t see the QR code appear. Instead, WordPress.com will ask you to Enter the code you receive via SMS. Once you’ve typed or pasted the code into this field, click [Enable] and follow the same steps (above) to save your backup codes.

    What’s the difference with SMS codes?

    The biggest risk with using SMS codes instead of an authenticator app (like Google Authenticator) is that SMS (text) messages aren’t encrypted. This means someone could possibly steal your authentication codes when they are sent to your phone. This is highly unlikely, but not impossible. It’s also possible to SIM-swap your phone to redirect your texts to another device. Again, this isn’t common, but it’s not impossible. To prevent SIM swapping, ask your mobile provider to add a PIN to your account.

    Also, your mobile provider might block these authentication text messages, because they come from automated systems. If this is the case, you can call your mobile provider’s support line and ask them to allow these types of messages (don’t forget to set up that PIN, too).

    Finally, even if your SMS messages aren’t hacked, it can take some time to get the authorization code via SMS. The authenticator apps, on the other hand, display the codes as soon as you open the app. There’s no delay.

    Using Two Step Authentication

    Once you’ve set it up, using Two Step Authentication to log in to WordPress.com is the same as before, except for one new step: after you type in your username and password, and click Sign In, you’ll  be asked to enter the Verification Code, and click Log In. Enter the code you retrieve from your authenticator app, or SMS, depending on which option you selected when you set up Two Step Authentication.

    Remember to click the Remember Me checkbox so you won’t have to re-enter a new authentication code every time you log in. But, keep in mind, only the browser you’re using will remember you. If you switch to another browser, or to another device, you’ll have to re-enter a new authentication code.

    More Information

    From WordPress.com Support:

    • Two Step Authentication :includes screen shots and also instructions on how to switch to a different device, if you lose your smartphone (or get a new one).
    • Selecting a Strong Password: excellent ideas on how to select and maintain unique, hard-to-crack passwords for all your web accounts.

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

  • Virtual Machine (defined)

    A Virtual Machine (VM) is essentially a second computer that runs in the memory of your computer hardware, the host computer. This computer-within-a-computer runs on top of the operating system of the host computer, and therefore can be started and stopped just like any other application on the host computer. If software on the virtual machine misbehaves, and causes the virtual machine to crash, it’s simply a matter of restarting the virtual machine, while your host computer continues to run.

    Also, your VM may run a completely different operating system from the host machine. You could, for example, run a Windows or Linux virtual machine on a Macintosh. Since VMs share the hardware resources of the host computer, VMs run best on host computers that have copious amounts of RAM, disk space, and powerful CPUs.

    Web developers use VMs to:

    • Build and test web sites on a virtual web server on their own local development computer.
    • Test a website from browsers running on different operating systems installed on different virtual machines, all on the same host computer.
    • Run multiple web servers on a single physical computer.

    More Information about Virtual Machines

    From the Virtual machine article on Wikipedia:

    There are different kinds of virtual machines, each with different functions:

    Virtual Machines – Wikipedia
    • System virtual machines (also termed full virtualization VMs) provide a substitute for a real machine. They provide functionality needed to execute entire operating systems. A hypervisor uses native execution to share and manage hardware, allowing for multiple environments which are isolated from one another, yet exist on the same physical machine. Modern hypervisors use hardware-assisted virtualization, virtualization-specific hardware, primarily from the host CPUs.
    • Process virtual machines are designed to execute computer programs in a platform-independent environment.

  • Firefox Quantum Ships Today

    These days, I’m just looking for any reason to use Firefox as my default browser. So starting today, I’m going to try for at least one week. Why? Mozilla just shipped Firefox 57.0, based on the new Quantum engine. Download Firefox Quantum and set it as your default browser, or read more about my experience using Firefox, and how it compares to Google Chrome, here.

    Need some reasons to use Firefox as your favorite browser? Here are a few:

    • Unlike Microsoft’s or Apple’s browsers (among others) Firefox runs on all major computing platforms: Windows, Mac, Linux, Android and iOS. This means you can use one browser across all of your devices.
    • Firefox lets you sync your settings, history and bookmarks across all of your devices so you never have to remember where you saved that bookmark or started that article you want to finish later.
    • Firefox uses less memory than many other browsers, like Google Chrome. This means faster performance and less waiting.
    • Firefox protects your privacy. Even more importantly, Mozilla, the organization that maintains Firefox, is on a mission to make the Internet a better place. Unlike the for-profit tech companies like Google, Microsoft and Apple, who make more money the more they know about you and your browsing habits, Mozilla builds a browser that’s designed to protect your privacy instead of monetizing you.

    This doesn’t mean that Firefox is perfect, or that it’s even the best browser for you. But it’s worth a try!

  • Windows Laptop Buyer’s Tips

    Fall 2017

    Here are the things to look for in a new Windows laptop. If possible, go to a store like Best Buy to see the laptop and try it out. For the most typical uses, follow these guidelines. If you want to use your laptop for more demanding tasks, like video editing or gaming, you’ll probably want to look at the higher end.

    In general, shoot for the middle in terms of pricing. You don’t need the most cutting edge tech unless you want to pay a premium. On the other hand, if you can’t afford to pay too much, consider a ChromeBook or a refurbished laptop.

    Hardware

    • Price: you don’t need to get anything too expensive, but you’ll pay in other ways if you get the cheapest options. Computers are so powerful these days that even the cheapest are quite capable, so you don’t need to get the fastest computer you can afford,
    • CPU speed (don’t get anything too slow). The truth is that most computers are so fast now that you’ll be fine with a middle of the road CPU.
      RAM: Go with 8 GB if possible. 4 GB is not really sufficient, and 16 GB is probably more than you need unless you plan to do video editing.
    • Go with an SSD (Solid State Drive) instead of a “spinner” hard drive, even though they are more expensive. The 10x speed boost is worth it. It’s really disk access that slows things down, assuming your CPU doesn’t suck and you have 8 GB of RAM.
    • Size and weight: if you plan on carrying your laptop, make sure it won’t throw your back out of alignment when you pick it up, or that it’s not too big to fit in your bag
    • Screen quality: this includes both the screen resolution (number of pixels, and how small they are — the smaller the better as everything will look crisp) and the view angle. Flip the lid up and down and stand off to the side. You will see the screen become dim at a certain angle. If this is too narrow, you’ll constantly be adjusting the screen.
    • The keyboard: try typing and make sure it’s comfortable, and that the keys feel good. This is the primary way you’ll interact with your laptop, so make sure you like it.

    Software

    • One of the first things you should do when you start your new Windows laptop is to install Google Chrome or Firefox and set this as your default browser. You can then sync your browser settings across computers, even if you find yourself using another computer that isn’t running Windows.
    • Instead of paying hundreds of dollars for a Microsoft Office license, consider using Open Office or Google Drive for word processing, spreadsheets, and presentation software.