My Local WordPress Development Environment

Local WordPress development in Peppermint OS

I just spent part of the day setting up and  testing my local sandbox environment using the following tools.

Operating System
Peppermint 8 running LAMP and WordPress

Plugins

  • WP Local Toolbox¬†– Creates the Admin Bar notification so I know I’m still in the right place just in case I end up on my live server
    • Normally I won’t use plugins that haven’t been updated in the last year or so but this is just for testing code and looking for conflicts.
  • Debug Bar – It’s always happy hour at this bar. Used to hunt down more information and make sure everything is nice and lean.

Other tools

I’m also using phpMyAdmin to drop and import tables. I could do this in the terminal but hitting those red buttons is a lot more fun.

Tables tables tables
Never name your kid DROP tables. xkcd

I drop everything except wp_usermeta and wp_users

  • wp_commentmeta
  • wp_comments
  • wp_links
  • wp_options
  • wp_postmeta
  • wp_posts
  • wp_termmeta
  • wp_terms
  • wp_term_relationships
  • wp_term_taxonomy

I then import my site’s sql backups after changing my domain references from linuxbookpro.com to localhost so it won’t redirect to my live website.

I also replace my wp-content folder from the default wordpress installation with the one from my backup.

This isn’t a step by step guide I had to do a few apache permissions but it all seems to be working nicely.

Happy hacking.

P.S. this is really just here for me to discover later when I forget something I did.

Why I use Jetpack to track what’s unpopular

Tracking has become synonymous with spying. What information should I collect, why is it collected and what will I do with it.

First it should provide value to the readers

It sounds squishy and it is. In short, any data collected should do something for the consumer. In this case myself and my readers.

Jumpack Stats from June 14
Jumpack’s statistics page from June 14.

I recently added a paid version of Jetpack to my website for daily backups, anonymous viewing statistics and video hosting. As a result it brought along with it nearly a dozen third party trackers, Specifically 11 on my homepage. While I’m not thrilled at the number at least it’s clear who is tracking this information.

Trackers installed along with Jetpack.
Trackers installed along with Jetpack.

All 11 are domains are owned by Automattic and most are specifically heading to wp.com which redirects to WordPress.com and not a random advertisement or “service” relentlessly tracking your every move. Jetpack is a WordPress.com service so this looks good to me.

By providing basic statistics, I can now research whether a post is viewed or is mostly ignored.

Largely no one viewed my Cold Brew and GTD post.

So how does this provide value?

  1. Google Plus didn’t care about my Coffee and Reading post where I shared it.
  2. I didn’t properly tag the post’s subject “Getting Things Done” maybe that would have helped.
  3. The post didn’t resonate, perhaps I should stick to Instagram coffee postings.
  4. Readers of my website just don’t come here for this stuff.
  5. No one is reading this.

Tracking should be anonymous and not follow people around

Don’t be creepy, if someone views your blog post the last thing they want to see  are ads loosely related to the subject elsewhere tomorrow.

Tracking services should clearly describe what they collect, how they do it, and what it’s used for. I think Automattic does a good job on their Privacy Page. So lets give this a go and see if I can improve my site.

Break stuff, but don’t forget to have backups

Hole
Pixabay

I’m one of those WordPress guys who rant about keeping regular backups. Even using a fantastic plug-in that automatically runs a backup every weekend. Everything was running great and I had months of backups safely stored on my web server.

Until today, I decided try and install Certbot without testing it on a non-production server first.

Everything seemed to work perfectly. Until I rebooted my server droplet and it was serving up my index.php template as straight code. Certbot and My Digital Ocean WordPress droplet had a conflict, likely I made a mistake.

As best as I could tell Certbot expected Apache to be configured a particular way; perhaps it the droplet’s customizations were at odds. Either way I no longer had access to my droplet via ssh, sshfs, or ftp to download my server side backups. To make things worse I didn’t store any backups locally or on another server.

This could have been easily avoided

  1. Digital Ocean offers snapshots and backups that can be manually deployed at any time. I didn’t bother to create one.
  2. I had months of weekly backups. I didn’t bother to take a few minutes to download one.
  3. My backup plug-in, online communities and my own rants about keeping multiple backups were not heeded.

It’s not all bad – This blog is where I test ideas and break stuff

Of all the posts only three or four contained useful content. The rest was old posts imported from social media and a few bits of custom wallpaper. Nothing was irreplaceable or important.

Feel free to break stuff in production, just don’t forget the backups.

WordPress Codex Resources:

Remove Google Fonts from Twenty Sixteen theme

Remove Google Fonts

In this example I removed Google Fonts from the WordPress TwentySixteen child theme.

function lbp_twentysixteen_child_dequeue_google_fonts() {
wp_dequeue_style( 'twentysixteen-fonts' );
}
add_action( 'wp_enqueue_scripts', 'lbp_twentysixteen_child_dequeue_google_fonts', 20 );

First create a unique function in the child theme’s functions.php file where style can be dequeued using the parent theme’s handle. Then add this as an action to run a little later than the parent theme’s enqueue process.

I’ve read that the default enqueue value in most themes is 10, so running it at twenty will remove it later in the loading process.