Breaks in sites can be completely invisible sometimes and, even if you take all precautions, there is a chance you may miss something till much later. 

It happened to us last month, as a matter of fact. Our site faced an unexpected challenge: a complete loss of analytics data for three consecutive days.

Our first reaction was panic, naturally, so we checked if traffic had stopped coming to our site. Thankfully that wasn’t the case, as our pages were still indexed, Search Console still had data coming in, and we could see from heatmaps and other analytics tools that traffic hadn’t changed much.

Turns out, the Google Analytics tracking code had mysteriously disappeared from the site. 

We checked logs and reviewed with the team, and saw no deliberate alterations had been made. So what caused the abrupt disappearance of our analytics code?

Background

You may have noticed that MalCare, BlogVault, and WP Remote have undergone major redesigns recently. The changes were huge: including the theme, layout, and overall design.

As the redesign was such a massive undertaking, being applied to three high-traffic, live sites, we implemented a phased plan. As we made the changes, we obviously had daily backups for 365 days and there was no question that we would be using a staging site to test extensively. 

Additionally, between each phase, there was a cooling-off period during which we monitored the sites closely for any anomalies or latent issues.

And finally, once the design was in place, with the new theme, elements, design, and layout thoroughly tested, we would deal with updates. No one knows better than us how crucial updates are, so it was a well-considered decision.

For instance, the old design had UI elements that used a deprecated version of PHP. So updating PHP prematurely would have broken the site for sure.

All the updates were thoroughly tested on a staging site and then moved to the live site. Whatever niggling issues we saw on the staging site were quickly resolved, and the live sites went through the entire redesign without a hitch. 

Or so we thought. 

Troubleshooting process

Upon discovering the absence of Google Analytics data, our marketing team swiftly raised the alarm. As we said before, traffic was still coming to our site—thankfully, otherwise, this would have been a very different article—so the issue was with the Google Analytics integration. 

We took a systematic approach to figuring out the root cause.

1. Checking the integration

We saw immediately from view-source that the code wasn’t present on the site. Not on the homepage, nor any of the blog or feature pages. It had simply vanished into thin air. 

2. Checking the custom code plugin

Since we manage custom code snippets with the WP Code plugin, that was our next port of call. 

WP Code is a versatile plugin that enables us to add tailored functions and features, like GA snippets, and forms to our websites. 

To debug what had happened with the GA code snippet, it was important to first understand how WP Code works. 

Understanding how WP Code works

WP Code efficiently stores each code snippet as a custom post in the WordPress database. It easily categorizes code into PHP, Javascript, HTML, or CSS, and performs thorough anomaly checks upon activation. If any coding irregularities are detected, the plugin prevents the activation of the specific code snippet.

In WordPress terminology, a snippet is essentially a custom post, which is meticulously stored in the posts table of the database. Upon activation, the status of the corresponding post changes to ‘publish’ in the database. Conversely, if the snippet is not activated, its post status remains ‘draft’. Consequently, any snippet containing code irregularities will remain or be changed to ‘draft’ status.

Why we use WP Code for custom code snippets

Formerly, we used child themes to enhance the functionality or design of a parent theme. We did this by adding functionality code to functions.php, styling code to style.css of the child theme, and extending functionality in further child theme files.

Ideally, we should have been able to use the Gutenberg block editor, when it was launched. It was said to reduce dependency on child themes for customization. However, we noted it was still in development and therefore lacked full functionality.

3. Discovering the draft code snippet

Given the previous context, you can probably see where this is going. The custom code snippet responsible for Google Analytics had been deactivated. 

This left us with a pivotal question at hand: Why did the code snippet get deactivated?

What was the issue?

The root cause of this issue traces back to a critical PHP update, transitioning from version 7.3 to 8.1. 

This update brought about substantial changes, including the deprecation of certain code syntax. Significantly, the new PHP version no longer offered support for deprecated code, causing a cascading effect. This was particularly felt in the case of our GA code snippet.

As we stated earlier, we updated everything on our site after the redesign was complete, and the site was live. Therefore the GA code snippet was in place and thoroughly tested before the PHP update was applied. 

So when there were changes in the versions, the WP Code plugin found that the code snippet was incorrect, and quietly changed its status to draft. We were none the wiser until the marketing team had a collective meltdown.

Here’s what happened in technical terms

The website’s database has a posts table that stores post IDs as integers (bigint) by default. However, when retrieving post details via the global variable $post, the ID is returned in string format. 

Traditionally, it has been customary to maintain post IDs, as well as any other WordPress entity IDs, in integer format. Consequently, developers either perform a type conversion using (int) or leave it in its original string state.

In versions of PHP before 8.0, if a string was compared to a number or a numeric string, the string would be automatically converted to a number before the comparison took place. For instance, when determining the current page or post ID to execute specific code, developers would utilize the global variable $post, extract its ID using $post->ID, and subsequently compare it to the desired value.

Earlier, the following comparisons were valid:

$post->ID == 1234

$post->ID == “1234”

(int)$post->ID == 1234

However, after upgrading to PHP 8.0, only the following comparisons were valid:

$post->ID == “1234”

(int)$post->ID == 1234

We mostly used $post->ID == 1234 for a quick snippet.

When we started running our ad campaign this year, we needed to add distinct tracking codes for our landing pages. We did this using the WP Code plugin.

With an existing repository of numerous code snippets, we opted to consolidate the Google tracking code into a single file for streamlined management. Consequently, we invoked the ad-related tracking code for landing pages using comparison operators, while retaining our standard analytics code for all pages within the same snippet.

Upon upgrading our server to PHP 8.1, the WP Code plugin automatically deactivated our snippet, resulting in a change of the post’s status to ‘draft’. This action was triggered by the presence of $post->ID == 1234 within the code. PHP identified this as a critical error, prompting the plugin to prevent its execution. 

Since this snippet contained our analytics code as well, our website’s tracking capabilities were temporarily halted.

How did we resolve this?

It took some digging to figure out what was causing the PHP syntax issues within the code snippet. However once it was identified as deprecated code, we were able to review and modify our existing code snippets to the latest PHP version’s syntax and guidelines. 

With the updated code snippets in place, we promptly reactivated the custom code snippet responsible for Google Analytics. And sure enough, everything was back in place again. 

Learnings

Our encounter with the code snippet issue led to several key takeaways that will shape our approach for the future.

Incremental updates

The incident highlighted the importance of making updates more incrementally. Even though we used a staging site for extensive testing before the PHP update, the issue remained undetected. We learned that version changes up a level can introduce significant alterations that might not be immediately apparent.

Comprehensive QA checklist

We also recognized the need for a comprehensive QA checklist that is as detailed as possible. A more meticulous testing process can help us unearth issues that might otherwise remain invisible. We also needed to use the checklist after any major change to the site. 

Invisible breaks

The incident underscored that breaks on the site can sometimes be invisible. This reinforces the need for vigilant monitoring and testing.

Backups, backups, backups

This experience reinforces the critical importance of maintaining full site backups. Backups provide a safety net in case issues arise. If we weren’t able to find the issue quickly, reinstating a backup would have been the best option. Luckily, we have 365 days worth of backups easily accessible and restorable. 

Staging

We used staging extensively when implementing updates because staging environments allow for thorough testing before changes are deployed to the live site. It is because of staging that we haven’t got more case studies like this one to share about our redesign process. 

These lessons serve as a foundation for strengthening our commitment to robust and resilient site management.