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.
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.
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.
So how does this provide value?
Google Plus didn’t care about my Coffee and Reading post where I shared it.
I didn’t properly tag the post’s subject “Getting Things Done” maybe that would have helped.
The post didn’t resonate, perhaps I should stick to Instagram coffee postings.
Readers of my website just don’t come here for this stuff.
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.
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
Digital Ocean offers snapshots and backups that can be manually deployed at any time. I didn’t bother to create one.
I had months of weekly backups. I didn’t bother to take a few minutes to download one.
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.
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.