WordPress Updates and your Core Mods

It’s true, you do not want to change the WordPress Core Code, but let’s say you make a minor change that if overwritten by a WordPress Update isn’t a big deal, like our Active Only Tag Cloud mod described in this blog post. We want to make sure our mod is still in effect after an upgrade, so let’s talk about managing WordPress Updates with Core Mods.

Before we discuss our approach to updating WordPress with one or more Core Code Mods, here is why we went that route with Active Tag Display. Look at this Call Stack and ask if your client wants to pay for writing an independent Tag Retrieval Process or add 3 lines of code to class-wp-term-query.php. Yeah, that would be a pretty big bill for your struggling small business client to swallow.

class-wp-term-query.php:566, WP_Term_Query->get_terms()
class-wp-term-query.php:297, WP_Term_Query->query()
taxonomy.php:1221, get_terms()
taxonomy.php:2089, wp_get_object_terms()
taxonomy.php:3525, update_object_term_cache()
post.php:6880, update_post_caches()
post.php:7267, _prime_post_caches()
class-wp-query.php:3021, WP_Query->get_posts()
class-wp-query.php:3448, WP_Query->query()
class-wp.php:624, WP->query_posts()
class-wp.php:747, WP->main()
functions.php:1285, wp()
wp-blog-header.php:16, require()
index.php:17, {main}()

First thing we’ll do is to make sure we disable automatic WordPress Updates. We know the source file we tweaked is class-wp-term-query.php. Each WordPress Upgrade has its own Documentation Page. Notice the URL matching the release number.

There’s a “List of Files Revised” section, where we’ll search for any file or files we might have changed.

If our affected source file is not on the list, we’re golden. If it is we’ll simply re-apply the mod according to instructions we recorded our site README.md.