Latest OMGF (Pro) update causing Internal Server (500) errors? Here’s how to fix it.

About 2 weeks ago, I’ve released OMGF 5.6.0 and OMGF Pro 3.8.0. These releases seem to have caused errors on some servers. In this post I want to inform you about possible causes and, more importantly, how to prevent these errors so your site can keep running smoothly.

Is it a bug?

Let’s begin with the elephant in the room: is it a bug? No.

Is it something that could’ve used a bit more preparation had I known about it? Yes.

OMGF 5.6.0 and OMGF Pro 3.8.0 include major performance improvements in code execution and database read/write behavior. I’m not going to bore you with the details, but basically, the whole framework both plugins are built upon has been rewritten.

So, what’s causing the 500 error?

Since PHP isn’t a runtime language, running “new” code shouldn’t be a problem in most cases. However, in the last two weeks users have reported experiencing 500 errors when using:

• Server caching mechanisms, e.g. Memcached or Opcache, and/or
• WordPress’ Automatic Updates feature.

Let’s dig into each one and fix this, shall we?

Cause #1: Stale Server Cache

First and foremost, server caching mechanisms like Opcache or Memcached seem to generate 500 errors after updating OMGF and/or OMGF Pro. Or, more specifically, stale server cache.

You know that OMGF Pro is an add-on that requires OMGF to be installed. And, what’s unfortunate, is that WordPress’ update API is a bit clunky — which I’ve learned now and trust me, I won’t make the same mistake again. I promise.

I say clunky for two reasons:

1. It doesn’t run updates in batches, even when you select multiple plugins to update at once. It runs the update process for each plugin separately. Which isn’t so bad, if it wasn’t for the fact that…
2. It loads the entire WordPress instance (including all plugins) when updating said plugins.

Why does that collide with a server caching mechanism like Opcache or Memcached, you ask? Great question!

These caches cache PHP files in the server’s memory, to ensure much faster execution. Which is awesome, but here’s what happens once you selected OMGF and OMGF Pro to be updated to their latest versions:

• The cache still consists of the files included in OMGF v5.5.6 (or older) and OMGF Pro v3.7.6 (or older)
• WordPress calls the Update API to update OMGF to v5.6.0
• OMGF has finished updating. So, the files have changed.
• The cache is smart and thinks: Hey! That plugin appears to be updated, I’m refreshing the cache for OMGF to v5.6.0.
  • At this point, OMGF v5.6.0 and OMGF Pro v3.7.6 are cached in the memory of the server. So far, that shouldn’t be a problem. But then…
• WordPress calls the Update API to update OMGF Pro to 3.8.0 — and loads the entire WordPress instance and all of its plugins from the server cache.
• While updating OMGF Pro to 3.8.0, OMGF Pro is 3.7.6 is executed, which is trying to call classes and methods from OMGF v5.5.6 — which no longer exists! And…

Well, not really. But you get the point.

Other CMS’ have their update mechanism running separated from WordPress, e.g. by using Composer. There are even Composer-managed versions of WordPress. But, ofcourse, only a handful of hosting providers run these services. Most rely on WordPress’ own Update API, which makes perfect sense.

The Solution

If you’ve already installed the update, and you’re experiencing errors, there’s only 1 thing you can do: disable the plugins manually by heading into your server through e.g. FTP or SSH and renaming the plugin folders. Then install the update for OMGF Pro manually after updating OMGF.

If you haven’t installed the update yet, you can simply prevent this by flushing your server’s cache before installing the updates.

Cause #2: WordPress’ Automatic Updates feature

Another reason why the most recent update of OMGF and OMGF Pro might cause a 500 error, is due to WordPress’ automatic update feature.

OMGF Pro blocks its own updates, if it sees that an update for OMGF is available. This has worked fine — until recent versions of WordPress.

At the moment, when Automatic Updates are enabled, OMGF Pro’s roadblock is ignored and its updated before OMGF is updated. Which should never happen.

The Solution

If the Automatic Updates feature has already installed the update for OMGF Pro, the update of OMGF should still be able to install from the Plugins screen. If not, you can go one of two ways:

1. Disable OMGF Pro manually, by heading into your server using FTP or SSH, then rename its folder, refresh WP’s Plugins overview and install the update for OMGF, or,
2. Disable OMGF Pro manually, and install the update for OMGF manually.

Can this happen again in the future?

This update has been a great learning experience for me and I’ve been thinking of ways to prevent this in the future.

The next release of OMGF Pro will have, what I came to call: safety wrappers. These wrapper methods explicitly check OMGF’s current status before attempting to access its code.

This will make sure that when e.g. Opcache is serving stale cache, OMGF Pro will just silently stop working until the required version of OMGF is available again.

Besides that, I’m still looking into ways to block Automatic Updates until OMGF is running at its latest version.

To Summarize

First off, allow me to apologize to everyone that has experienced this error. Your server exploding due to something as little as a plugin update sucks. Nothing more, nothing less.

Although it’s not entirely my fault, I definitely learned a great deal about quirks in WordPress’ Updates API and its Automatic Updates feature.

I have implemented failsafes to make sure these errors won’t happen again in the future.

But, before I leave you, I want to address an urgent matter to those of you using any type of caching:

Always flush your cache before installing updates!

Wishing you an excellent day!