Bulk Updating Any Meta Values in WordPress Posts Automatically

I updated the look of my site, today, and with that came a non-standard setup for featured images and the realization I’d have to manually update a lot of posts.

The theme requires custom meta be used for the featured image setting to determine how to display an image. As of this post, I have roughly 170 blog posts in the database that would need updating from the beginning of January until now. I definitely didn’t want to spend the next 60 minutes (170 posts * time to click) updating each post, so I did a bit of quick and dirty PHP coding.

Placing the code within the_loop() allowed it to run automatically for each post that was presented. Setting the per-page post count to 200, I effectively had all 170 posts pushed on screen at the same time. This subsequently updated all 170 posts at the same time. This of course put a little bit of a hit on my SQL database, but not so much that it bogged it down. I’m sure having 170 * 2 reads then writes all at once blew out a few of the cobwebs. Most of this site is cached pretty effectively so the database doesn’t do much.

Screenshot 2015-05-02 18.23.56

You’ll see in the image above where I made the updates. The first spike should have been the only one, but I entered the wrong value for one of the custom meta fields so I had to go back and do it again. The code has logic so if it was already correct, it skipped it, hence the smaller second peak.

If you’re curious, the above came from NewRelic, a service offering made by some pretty cool people. They’re free to use for the basic stuff and their customer service rocks. </shameless plug>

Anyway, without further delay, here’s the code that made this happen:

Pretty neat, eh? I know it’s nothing spectacular but it gets the job done, for sure.

Share this post with everyone you know who’s even just remotely interested in WordPress development. One could even bulk-update posts themselves with zero clicks or interaction necessary.

I feel like I did a great thing, today. Time for a beer.


The Stack

(This post is wildly out-dated. The most current info is here.)

Yesterday someone asked me what my stack looked like.

Today I think it makes a good blog post.

I’m always open to share the tech behind my sites and this one is no different. While not incredibly in depth, here’s how it goes:

Layer 1: Infrastructure

The core of it all is DigitalOcean. They provide the resources my site sits on and so far they’re doing amazingly well. If I ever need more space or resources, I just need to click a few buttons and I’m on my way. I could also set up load balancing, too, with little effort if it comes to that. Their claim to fame are their awesome little (or big) droplets that start at $5. For $5 you get 512mb of RAM 20GB of SSD-backed storage, and 1TB of bandwidth. That’s enough for a small, site, for sure. I’ve moved higher than that mainly because of one member of my software stack that naturally uses more RAM. I’ll cover it later.

Layer 2: Operating System

Within my DigitalOcean home, Ubuntu 14.04 sits. I’ve chosen the LTS branch because I’m very much of a set-and-forget mentality when it comes to supporting architecture. I like the idea of not having to worry about my OS becoming outdated in a short window of time. It’ll effectively be supported until 16.04 comes out, and to give you an idea of when that is, 14.10 is currently the newest in line and 15.04 isn’t slated until the end of April for a release date. In essence, I’m good until at least April 2016. 

Layer 3: Web Server

Presenting all of these bits is hard work. That’s why I chose nginx to take up the task. It’s a great server application that I’ve combined with SSL to make every visit to https://jlyman.net secure. Minimal configuration is needed in order to make things hum along smoothly, and I’m glad for that.

Layer 4 1/2: Interpreter

PHP. Given I run WordPress, this is a given. However there are several ways to run it. In my case, I’ve taken then PHP5-FPM route. I could also use FastCGI (the more generic form of FPM) or MOD_PHP (which is actually not that fast in today’s environments). FPM allows me to keep PHP from sucking up too many resources and limiting its worker count. If something gets stuck, I can gracefully shut it down and bring it back up without any major headaches.

Layer 4 2/2: Database

This one is also a given because I run WordPress. MySQL is on the back side hosting the actual content of this site. It’s backed up every hour for good measure and backups are stored in a safe place that can be reached via the outside. There are much more efficient databases however getting WordPress to work with them is rough going if not impossible at this time and I don’t see much changing any time soon.

Layer 5: WordPress

This is the cream on top. WordPress is my CMS of choice and it’s one I’ve used for several years. I remember when I first started using it back on version 2.5. WordPress has come a very long way and I’m grateful that development of such a product continues today with a massive community behind it. 

Layer 6: CloudFlare + SSL

On top of all this, CloudFlare + SSL takes care of all my caching needs. They’re very intelligent about what can be cached and what’s dynamic. I have yet to run into a case where stale content has been served. With their system comes continued use of SSL. This means that from the server to their server is secure, and from their server to you is also secure, no questions. DDoS efforts are limited quickly and geographic-dependencies are removed. Wherever you are, you’ll get quick load times and a lot of burden is taken off my system, which keeps my costs low. I love keeping costs low.


page 1 of 1