WordPress

This is the converse of slash companion to this guide.

Finalize everything in your live production environment (by adding, removing, editing, and updating plugins, themes, WordPress, content, etc.) before proceeding.

First: Back up

1. Local wp-content folder:
   open new Terminal window/tab
   cd [Local WordPress Path] (drag WordPress folder from Finder to Terminal to get path)
   mkdir -p my-wp-backups && tar -czvf my-wp-backups/wp-content-`date +%F`.tar.gz wp-content
2. Local wp-config.php file:
   cp wp-config.php my-wp-backups/wp-config-`date +%F`.php
3. Local MySQL database:
   [Local mysqldump Path] -u [DB_USER] -p[DB_PASSWORD] --opt [DB_NAME] > wp-database.sql (e.g., /Applications/MAMP/Library/bin/mysqldump) (see local wp-config.php file for DB_USER, DB_NAME, and DB_PASSWORD)
   tar -czvf my-wp-backups/wp-database-`date +%F`.sql.tar.gz wp-database.sql
rm wp-database.sql
4. Production wp-content folder:
   open new Terminal window/tab
   ssh username@example.com (e.g., ssh adamcap.com@adamcap.com)
   enter password
   cd [Production WordPress Path] (e.g., cd html)
   mkdir -p my-wp-backups && tar -czvf my-wp-backups/wp-content-`date +%F`.tar.gz wp-content
5. Production wp-config.php file:
   cp wp-config.php my-wp-backups/wp-config-`date +%F`.php
6. Production MySQL database:
   wp db export wp-database.sql
tar -czvf my-wp-backups/wp-database-`date +%F`.sql.tar.gz wp-database.sql
rm wp-database.sql
7. Production my-wp-backups folder:
   tar -czvf my-wp-backups.tar.gz my-wp-backups
   (rm my-wp-backups)
   (rm my-wp-backups.tar.gz)

Second: Download my-wp-backups

1. Download production my-wp-backups folder:
   scp [username@example.com]:[Production WordPress Path]/my-wp-backups.tar.gz [Local Desktop Path] (obtain from web host; e.g., adamcap.com@adamcap.com:/var/www/html/ad/adamcap.com) (drag Desktop from Finder to Terminal to get path or ~/Desktop)

Third: Unzip, rename, and move

1. Unzip:
   double-click my-wp-backups.sql.tar.gz file on Desktop to unzip folder
   enter folder
   double-click wp-database-`date +%F`.sql.tar.gz file to unzip database
2. Rename:
   add suffix -new to each item’s file/folder name
3. Move:
   drag wp-content-new and wp-database-new.sql to local WordPress folder

Fourth: Prepare wp-config.php

1. Copy local wp-config.php file:
   open new Terminal window/tab
   cd [Local WordPress Path] (drag WordPress folder from Finder to Terminal to get path)
   cp wp-config.php wp-config-new.php
2. Edit local wp-config-new.php file:
   nano wp-config-new.php
   Update DB_NAME, DB_USER, and DB_PASSWORD (and verify $table_prefix) (be certain to update DB_NAME, e.g., database-XXXX-XX-XX)
   control + O (to save), control + X (to exit)
3. (Switch local wp-config.php file:)
   mv wp-config.php wp-config-old.php && mv wp-config-new.php wp-config.php
4. (Revert local wp-config.php file:)
   mv wp-config.php wp-config-new.php && mv wp-config-old.php wp-config.php

Fifth: Import database

1. Create new local database:
   open new Terminal window/tab
   cd [Local WordPress Path] (drag WordPress folder from Finder to Terminal to get path)
   wp db drop ; wp db create OR drop/create via phpMyAdmin
2. Switch local wp-content folder:
   mv wp-content wp-content-old && mv wp-content-new wp-content
3. Switch local wp-config.php file:
   mv wp-config.php wp-config-old.php && mv wp-config-new.php wp-config.php
4. Import wp-database-new.sql file into local database:
   wp db import wp-database-new.sql OR [Local mysql Path] -u [DB_USER] -p[DB_PASSWORD] [DB_NAME] < wp-database-new.sql (e.g., /Applications/MAMP/Library/bin/mysql)
5. Search/replace local database:
   wp search-replace $(wp option get siteurl) [Local Site URL](e.g., http://localhost:8888/adamcap or http://adamcap.local)
   (wp search-replace [Production Hostname] [Local Hostname]) (e.g., adamcap.com) (e.g., localhost:8888/adamcap)
   (wp search-replace https://[Production Hostname] http://[Local Hostname]) (e.g, https://adamcap.com) (e.g., http://localhost:8888/adamcap)
6. Flush rewrite rules (i.e., save permalinks)
7. (Revert local wp-content folder:)
   mv wp-content wp-content-new && mv wp-content-old wp-content
8. (Revert local wp-config.php file:)
   mv wp-config.php wp-config-new.php && mv wp-config-old.php wp-config.php
9. (Delete unneeded/old local files and folders:)
   rm wp-content-new.tar.gz
rm wp-database-new.sql
rm wp-database-new.sql.tar.gz
rm -rf wp-content-old
rm wp-config-old.php

A website that pulls decent traffic may want to display the number of views each of its pages has gotten. This information can make a website seem more active or credible (or, generally, worthwhile perusing) than it would otherwise to a visitor. This datum can also subtly and meaningfully guide a user’s interactions with a website (i.e., a page with more views is likely worth visiting in preference to a page with less views). YouTube, for example, leverages view counts to (and which) influence whether a video may be worth watching.

WordPress doesn’t track pageviews out of the box, but Jetpack is a popular plugin, which many WordPress websites use, that does track pageviews. It does not save pageviews, however, in a way which makes this data readily available to plugin or theme developers. But it is possible to import Jetpack’s pageviews so that the data is useable. And it makes sense to piggyback off Jetpack’s stats, rather than devise a unique solution to track pageviews; such inventions are typically unstable, imprecise, or prone to bogging down performance. Holding hands with Jetpack is a pretty sure-fire solution which adds minimal overhead (and elegance, too).

How It Works / The Approach

The data that Jetpack collects is available through the WordPress.com Stats API which can be accessed with the stats_get_csv function provided by Jetpack. This API can be called while a page is loading, i.e., before the page is displayed to the visitor (in the wp_footer action, for example), but a better method is to call the API after the page has finished loading, via Ajax. An Ajax implementation allows the user to visit the page unimpeded—without waiting for the API request to process first, which may take a split second or two—a relative eternity in the context of the internet (where instantaneous responses are generally expected). Instead, the call happens in the background, after the page has loaded, which affords the user a better experience.

The Code (Action!)

First, load a JavaScript file to trigger an Ajax request:

This is the JavaScript file—place it in the correct path (defined by wp_enqueue_script above):

Finally, process the Ajax request (triggered by the JavaScript above):

Combined, this code will:

1. save the pageviews for each post
2. in post meta key views
3. every ~4 hours.

This data can be displayed with get_post_meta and posts can be sorted by views, e.g., to query for popular posts:

Hacking “days”

The WordPress.com Stats API caches requests. This is problematic for us, because it means that a page’s current view count may not be returned for our request; we could instead be provided a view count from days ago. Typically, -1 is supplied for the days parameter, in this API call, to return “total views” (views accumulated in the past “infinite” [or all] days). However, the results from 'days' => -1 cache for an indeterminate amount of time, and thus will not always be current when requested.

To work around this, we attempt to bust the cache with each call, by requesting a page’s view count from the past X days (instead of -1 days), where X is a random number from 36,500 to 2,147,483,647.

The former figure I chose somewhat arbitrarily; it is roughly 100 years in days. (I figure WordPress will be history by that point.) The latter figure comes from PHP’s getrandmax function.

This range has proven sufficient—for me, anyway—to reliably bust the Stats cache with each API request.

Git is a system for keeping track of changes in code. It’s particularly useful for collaboration (“Hello, world of fellow programmers!”) and reversion when a project’s source code has inadvertently ventured treacherously and irrevocably astray (fervently spamming CMD+Z is not always enough to re-establish baseline).

I obdurately refused to learn git for many years, because I am a doofus, and worked mostly solo on projects (verily to detriment). I recommend learning git, sharing code, and collaborating with others. Feedback is invaluable; you’ll get way better way faster than I did working this way.

Because I didn’t exactly hit the ground running, in terms of adapting git, I’ve typed out loose directions for personal reference—and for others whose interest is piqued and could use a guiding hand.

First: Initialize Git

1. Install Xcode command line tools:
   open new Terminal tab/window
   xcode-select --install (or xcode-select --reset) (see: link)
2. Go through seemingly pertinent GitHub setup guides: link
3. Generate SSH key (and add passphrase to keychain): link
4. Add SSH key to GitHub account: link

Second: Create Origin Repository

1. Visit: link
2. Choose repository name and public/private (skip other options)
3. Create repository
4. Leave succeeding page open (it lists helpful commands and SSH URL needed below)

Third: Initialize & Commit Remote Repository to Origin

1. Navigate to local, top-level project directory (e.g., WordPress theme or root):
   open new Terminal window/tab
   cd [Local Path] (drag folder from Finder to Terminal to get path)
2. Add remote repository:
   git init
git remote add origin git@github.com:[GitHub Username]/[Repository Name].git
3. (Pull remote repository:)
   git pull origin master (see: link)
4. Create .gitignore file to ignore files in repository:
   touch .gitignore
   edit w/ text editor (see: link for guidance w/ file contents)
5. Add files and commit changes:
   git add -A
git commit -am "[Message]" (e.g., git commit -am "first commit")
6. Push to remote repository:
   git push -u origin master

Misc. Maintenance

• View status:
  git status
• Remove .DS_Store:
  find . -name .DS_Store -print0 | xargs -0 git rm -f --ignore-unmatch (see: link)
  git add -A
git commit -am "delete .DS_Store"
• Remove remote repository:
  rm -rf .git
rm .gitignore

Many websites link to products on Amazon, this one included, in hopes of capturing commission from Amazon’s affiliate program. In order to be credited with the sales generated through their promotional efforts, the affiliate needs to affix a tracking ID (or tag; the verbiage varies) onto their links, like so:

• https://www.amazon.com/
• https://www.amazon.com/?tag=adamcapr-20

Here are a couple of options to automatically tag Amazon links, within post content, with a specified tracking ID, using regular expressions.

v1: Raw

This first version will indiscriminately add a tracking tag to (or replace an existing one on) any amazon.com URLs:

v2: Clean

This second version extracts ASINs from amazon.com/dp/ URLs, then rewrites those URLs, so that extraneous strings and parameters are stripped before adding the tracking tag. Other, non-/dp/ amazon.com URLs will have the tracking tag assimilated in the manner above.

The advantage to implementing automation like this is that it lessens cognitive demands for precision and thus can expedite publishing processes.

Of course, it’s probably more prudent to curate Amazon short links (e.g., https://amzn.to/2Mkz6k2) which are less susceptible to the type of manipulations performed above. Web browsers and other services can more easily hijack full links, diverting revenue away from those who instituted them.

Fancybox is my lightbox script of choice. I feel it improves the end-user’s web-browsing experience, so I use it in most projects.

To enable Fancybox on an image, it’s necessary to:

1. Surround the <img> element with a link that points to an image file.
2. Add a data-fancybox attribute (and optional group declaration) to the link.

Typically, you’ll be including the hyperlink along with the image when you insert it through the WordPress post editor. This code will automatically add the still-needed Fancybox attribute for you:

Other lightbox scripts are enabled similarly; this code is adaptable.

I first noticed the usage of lede styling on Wired.com, which styling, at least in Wired’s implementation, is where the first three words of a news story are styled differently that the rest of the piece, to attract the wandering eye’s attention. (“Reader: Start here!”) The concept is similar in principle to that of the drop cap, which has been used in print for centuries.

I wanted to apply similar styling to the content on my website, but I didn’t want to go through every post I’ve ever written to add the necessary HTML—a <span> element with an arbitrary class name around the first three (or however many) words of a post. So, instead, I wrote this content filter to do it automatically:

With the markup in place, the text can be styled as so:

It will likely be possible to achieve this targeted styling with CSS alone sometime in the future—through an `::nth-word()`-esque pseudo element, without HTML markup—but for now, this solution affords an immediate response and flexibility.

The number of lede words can be controlled through a custom field—here I use the meta key _lede_words—and I’m partial to solutions like Carbon Fields or CMB2 to assist with the selection. Here’s the corresponding metabox for Carbon Fields that I’ve created:

Note: If any of the lede words are hyperlinked, the above regex will fail. Manually add markup in those odd scenarios, or attempt to amend the code.

Follow these steps to move a local, MAMP development environment to a live, production environment (that has shell and WP-CLI enabled; good web hosts do). We will be using command line to achieve this end. The reason to use command line instead of graphical interfaces, like the myriad of available (S)FTP clients or phpMyAdmin, is that command line lends better performance and reliability. Graphical interfaces will time out, or seemingly take forever to load, if your files are large. There is a higher learning curve to command line—it will feel initially like yawping haphazardly into a void—but the reaped time savings make it well worth practicing.

Finalize everything in your local development environment (by adding, removing, editing, and updating plugins, themes, WordPress, content) before proceeding.

First: Back Up

1. Local wp-content folder:
   open new Terminal window/tab
   cd [Local WordPress Path] (drag WordPress folder from Finder to Terminal to get path)
   mkdir -p my-wp-backups && tar -czvf wp-content-`date +%F`.tar.gz wp-content -C my-wp-backups
2. Local wp-config.php file:
   cp wp-config.php my-wp-backups/wp-config-`date +%F`.php
3. Local MySQL database:
   [Local mysqldump Path] -u [DB_USER] -p --opt [DB_NAME] > wp-database.sql (e.g., /Applications/MAMP/Library/bin/mysqldump) (see local wp-config.php file for DB_USER, DB_NAME, and DB_PASSWORD)
   enter DB_PASSWORD
tar -czvf wp-database-`date +%F`.sql.tar.gz wp-database.sql -C my-wp-backups
rm wp-database.sql
4. Production wp-content folder:
   open new Terminal window/tab
   ssh username@example.com (e.g., ssh adamcap.com@adamcap.com)
   enter password
   cd [Production WordPress Path] (e.g., cd html)
   mkdir -p my-wp-backups && tar -czvf wp-content-`date +%F`.tar.gz wp-content -C my-wp-backups
5. Production wp-config.php file:
   cp wp-config.php my-wp-backups/wp-config-`date +%F`.php
6. Production MySQL database:
   wp db export wp-database.sql
tar -czvf wp-database-`date +%F`.sql.tar.gz wp-database.sql -C my-wp-backups
rm wp-database.sql

Second: Upload wp-content

1. Gzip local wp-content folder:
   open new Terminal window/tab
   cd [Local WordPress Path] (drag WordPress folder from Finder to Terminal to get path)
   mv wp-content wp-content-new && tar -czvf wp-content-new.tar.gz wp-content-new && mv wp-content-new wp-content
2. Upload local .tar.gz file to production:
   open new Terminal window/tab
   scp [Local .tar.gz Path] [username@example.com]:[Production WordPress Path] (drag .tar.gz file from Finder to Terminal to get path) (obtain from web host; e.g., adamcap.com@adamcap.com:/var/www/html/ad/adamcap.com)
   enter password
3. Unzip production .tar.gz file:
   ssh username@example.com (e.g., ssh adamcap.com@adamcap.com)
   enter password
   cd [Production WordPress Path] (e.g., cd html)
   mkdir wp-content-new && tar -xzvf wp-content-new.tar.gz -C wp-content-new --strip-components 1
4. (Switch production wp-content folder:)
   mv wp-content wp-content-old && mv wp-content-new wp-content
5. (Revert production wp-content folder:)
   mv wp-content wp-content-new && mv wp-content-old wp-content

Third: Prepare wp-config.php

1. Copy production wp-config.php file:
   open new Terminal window/tab
   ssh username@example.com (e.g., ssh adamcap.com@adamcap.com)
   enter password
   cd [Production WordPress Path] (e.g., cd html)
   cp wp-config.php wp-config-new.php
2. Edit production wp-config-new.php file:
   nano wp-config-new.php
   Update DB_NAME, DB_USER, and DB_PASSWORD (and verify $table_prefix)
   control + O (to save), control + X (to exit)
3. (Switch production wp-config.php file:)
   mv wp-config.php wp-config-old.php && mv wp-config-new.php wp-config.php
4. (Revert production wp-config.php file:)
   mv wp-config.php wp-config-new.php && mv wp-config-old.php wp-config.php

Fourth: Move database

1. Export local MySQL database:
   open new Terminal window/tab
   cd [Local WordPress Path] (drag WordPress folder from Finder to Terminal to get path)
   [Local mysqldump Path] -u [DB_USER] -p[DB_PASSWORD] --opt [DB_NAME] > wp-database-new.sql (e.g., /Applications/MAMP/Library/bin/mysqldump) (see local wp-config.php file for DB_USER, DB_NAME, and DB_PASSWORD)
2. Gzip local .sql file:
   tar -czvf wp-database-new.sql.tar.gz wp-database-new.sql
3. Upload local .tar.gz file:
   open new Terminal window/tab
   scp [Local .tar.gz Path] [username@example.com]:[Production WordPress Path] (drag .tar.gz file from Finder to Terminal to get path) (obtain from web host; e.g., adamcap.com@adamcap.com:/var/www/html/ad/adamcap.com)
   enter password
4. (Delete unneeded/old local files and folders:)
   rm wp-content-new.tar.gz
rm wp-database-new.sql
rm wp-database-new.sql.tar.gz
5. Unzip production .tar.gz file:
   ssh [username@example.com] (e.g., ssh adamcap.com@adamcap.com)
   enter password
   cd [Production WordPress Path] (e.g., cd html)
   tar -xzvf wp-database-new.sql.tar.gz
6. Switch production wp-content folder:
   mv wp-content wp-content-old && mv wp-content-new wp-content
7. Switch production wp-config.php file:
   mv wp-config.php wp-config-old.php && mv wp-config-new.php wp-config.php
   (wp config shuffle-salts)
8. Create new production database:
   wp db drop ; wp db create
9. Import production .sql file into production database:
   wp db import wp-database-new.sql
10. Search/replace production database:
    wp search-replace $(wp option get siteurl) [Production Site URL] (e.g., wp search-replace $(wp option get siteurl) https://adamcap.com)
    (wp search-replace [Local Hostname] [Production Hostname])
    (wp search-replace http://[Production Hostname] https://[Production Hostname])
11. (Revert production wp-content folder:)
    mv wp-content wp-content-new && mv wp-content-old wp-content
12. (Revert production wp-config.php file:)
    mv wp-config.php wp-config-new.php && mv wp-config-old.php wp-config.php
13. (Delete unneeded/old production files and folders:)
    rm wp-content-new.tar.gz
rm wp-database-new.sql
rm wp-database-new.sql.tar.gz
rm -rf wp-content-old
rm wp-config-old.php

See Also

• Move from Live Production Environment to Local macOS Development Sandbox (MAMP) (coming soon)

WordPress doesn’t ship with a deliberate method for keeping track of where attachments have come from. You can toss sources (names and URLs) into caption or description fields, but those fields are not intended to house that information, they are not conducive for displaying said information, and thus the average WordPress user never divulges the origins of their attachments/media.

Thankfully, attachment fields are readily extensible, and it’s easy to display attribution—with the right code!

First, the following will add Source URL and Source Name fields to the “Attachment Details” and “Edit Media” screens:

With these fields in place—and source info subsequently entered—attachments can be attributed in a variety of ways. Below are two examples for attributing images used within post content by means of affixing a source link to each image’s HTML markup.

For captioned images:

And non-captioned images:

Note: If the source name is excluded, the hostname will be extracted from the URL, and that will be displayed as the source link text. This allows you to consciously omit the source name, in most cases, to expedite data entry. The hostname is often sufficient for attribution (but not always; a source name should be specified for nearly all social media URLs, for example).

The next step is to style the source links so that they look agreeable within context. Here is the raw CSS I used for one project—which will need to be tweaked—to afford you a head start:

Finally, here’s a screencap of the finished product (image with source-link attribution in the bottom-right corner):

Attribution should be commonplace and easy, though it typically isn’t, and this implementation is at least one small ethical step forward.

Nonbreaking spaces are all-too-often inadvertently inserted into TinyMCE rich-text content, which can cause awkward and unintended line breaks within paragraphs. These few lines of code annihilate the issue, on the frontend, by replacing nonbreaking spaces with normal, word, spacebar spaces:

\xc2\xa0 is the UTF-8-encoded nonbreaking space character (which resides in a WordPress database and is manipulable here).

For more on nonbreaking spaces, see Butterick’s Practical Typography.