From grinding to ground: the book review tweaking is done

The PolyBlog
June 14 2025

So, I’ve added seven data fields to 273 book reviews, eliminated approximately 30 pages of manually maintained lists, and added several pages that compile all my book reviews into a series of indices. It was quite the grind.

As I mentioned earlier, many of the early book reviews had remnants from previous attempts to establish a common look and feel. Back in the Stone Age, I had tried using pre-established plugins that developers had created. I eventually removed them; they were designed to leave some of the information behind in case I wanted to reinstall the plugin later or just have the pages continue to look fine. I didn’t want the remnants; I didn’t need them, but well, that’s what I had. In a few old book reviews, that meant 100s of old data fields, slowing things down. On average, the first 150 or so had about 50-75 remnants, I think. Far too many to remove manually. Now THAT would have been a grind.

Instead, I found some tools to batch remove extraneous content, leaving me with about 20 fields per post, but at least they were easy to work with one by one. I thought I would do about 10 BRs per day, and thus it would take me about a month to cover 273 old posts. I was doing them a bit faster after #150 or so, partly because the steps weren’t all the same:

  1. Open the post
  2. Delete 20 old fields
  3. Add 7 new fields
  4. Enter the data for the 7 new fields
  5. If it was a new sub-category, go to the “series” page and create a new category AND create a shortcode for a subcategory “list” within that page.

The farther and farther I got into the updates, step 5 became less and less relevant — most of the categories were already established. In which case, I could update the data and press save before moving on.

When I reached 200 BRs, a minor miracle occurred…I had redesigned the reviews at that time and created a fresh review format. Since it never had any of the old remnants in it, the BRs from 200-273 had NO old fields to remove. I could just add 7 new ones, save the data, and move on.

Initially, it took me about an hour to update the code for approximately 10 reviews. Maybe 50 minutes or so. Not very speedily, hence the month estimate. However, when I reached about #100, I could manage about 15 in an hour. By #150, I could do almost 20. When I hit #200? I did the last 75 in one go, only two hours in total. My planned month-long project was completed in just over a week, with approximately 12 hours of work. Maybe a bit more. Definitely more than I wanted, but it is a much better approach than doing everything manually. I suspect I saved myself perhaps 5-7 hours worth of maintenance per year, so call it approximately a 6-hour incremental investment. I suspected I would have some data entry issues. How could I not, since I was designing on the fly? But I would have ways to verify things at the end.

If I review my original approach, which was to prioritize completion over perfection, I was going to delete a bunch of content, reduce my ongoing maintenance work, and functionality. Instead, I streamlined some backend things, which gave me a bit of room to spend some extra time under the hood now and add some bells and whistles. Let’s look at the result.

Results

I mentioned previously that I now have a very detailed set of pages that essentially do what the old lists did, but they are now automatically updated. Once the data is posted? It automatically adds the review to the various lists. Reviews are broken down by:

I thought I would reduce it to just the first two options above, but I managed to find some other tools that expanded the project beyond barebones, offering a lot more functionality with a smaller footprint. Not fully optimized, but still quite impressive for a revision.

Now, I have to admit, I am anal retentive, and I wanted to do a bit of data integrity checking on the list. For most of the main lists of “all posts”, those are relatively impossible to get wrong — they are generated by WordPress itself using most of its base functions.

The only real issue was, if everything was listed in a full list, would it show up WHERE it should in the sub-lists? The full archival text and by date of review were super easy and completely correct. The book review number had a glitch with one post, which turned out to be that the data I put in that field was for another field. Easy tweak, list went to normal. The ones by title, author and rating went fine from the word go, while the one by the year of publication had another glitchy entry that was easily corrected.

For the fiction and non-fiction lists, with all the sub-lists, the posts should show up exactly twice — once in either the fiction or non-fiction list and then once in one of the sub-lists for that genre, and grouped by series under the sub-headings.

But — spoiler alert — I apparently suck at data entry. I was expecting maybe a 2 or 3% error rate, but almost 10% of the posts had SOME sort of coding issue. The biggest glitch were about 8 non-fiction posts where I had simply defaulted to “fiction” because almost all the posts are fiction. I remembered on one post late last night that I hadn’t been paying attention to that field much in a few previous ones, although I wasn’t sure if that meant I coded them as fiction or I just mindlessly put in non-fiction correctly without remembering. It turns out that, yeah, I was mindless all right, just not correctly mindless. Easily fixed.

I also created a few categories and sub-categories that changed a bit over time. There were a couple of posts in non-fiction where I gave it a sub-category that would apply to that book, and probably no other in the whole collection. So why was I creating a sub-category for it as a series or genre? No idea. Again, easily fixed, but that was more about having designed on the fly without knowing the full data set. Once I saw the full data set, it was easy to correct. Originally, I thought “magic” would go into fantasy, but then I have some that are more paranormal in nature than fantasy. So I modified the paranormal grouping so that magic is clearly there (IF it isn’t fantasy with magic, that is). I also decided to set up some of my larger collections of readings (Nancy Drew, Sherlock Holmes and the Three Investigators) knowing they probably deserve a sub-grouping all on their own, given the size of the series. Oh, and haha, I realized that for Stephanie Plum where there are 20+ books, I wasn’t seeing them all…huh? Oh, right, the default is to show you just the first TEN in a series, not all of them. Oops, I need the whole list. But I would say third on the long list of little tweaking was that I coded something wrong…a few were simple typos like “ficton” instead of “fiction”, or I put RASC even though the code for the other RASC headings were “rascastronomy”. Another was a spelling mistake.

But the process was interesting. Looking at the list and cross-referencing everything was a pain in the patootie today, and sure, I could have waved it away as being anal-retentive. But the reality is that if I didn’t find those errors NOW, I would NEVER find them when there are 500 reviews or more. I am still not 100% sure I have everything grouped in the right order and sub-groupings, but unlike my previous manual lists, if I decide to reorder something, I can do it in about 60 seconds. I’m pretty happy with the new functionality and approach.

And did I mention that the grinding is done? 🙂 Even if I still have over 300 reviews in my book system to write and will be lucky to get even a quarter off the pile before the end of the year. I’m wondering though if there are any lessons learned for my other collections of reviews (music, TV, movies, recipes, etc.). None of them are anywhere near as elaborate yet, but when I designed them, I built off the book review infrastructure and approach. Maybe later this year, I’ll figure out if I should be coding it that way. I’m also wondering if my index for photo galleries should be auto-generated instead of manually maintained.