Stop Kicking That Dead Horse: WordPress 6.9 and the End of IE Support

I had a client, a long-time WordPress user with a custom theme from way back. Solid build at the time, but hadn’t seen a proper audit in years. They hit the update button for WordPress 6.9, and suddenly, their admin area was a mess. Some custom fields looked off, a few of their legacy scripts just weren’t firing. Total nightmare, right? Turns out, it was all tied to the removal of legacy Internet Explorer code.

Look, IE is dead. Has been for years. WordPress officially dropped support for IE11 back in version 5.8 (that was July 2021). So, when WordPress 6.9 rolled around, the core team finally took the hammer to a whole lot of code that was only there for IE compatibility. And good riddance, I say. Less cruft, faster core. But for those older, custom-built sites? This is where the cleanup starts, and where you might hit some snags if you’re not paying attention.

Understanding WordPress IE Support Removal

The biggest change, and likely the one that’ll bite you, is the removal of support for IE conditional scripts and styles. Remember those? Back in the day, we’d use conditional comments to load specific CSS or JavaScript just for IE, like so:

<!--[if IE 8]>
<link rel="stylesheet" href="<?php echo esc_url( get_template_directory_uri() ); ?>/css/ie8.css" type="text/css" />
<script src="<?php echo esc_url( get_template_directory_uri() ); ?>/js/ie8-fixes.js"></script>
<![endif]-->

Or perhaps you used the `conditional` argument with `wp_enqueue_script()` or `wp_enqueue_style()`. My client’s theme was doing exactly this, specifically for some admin-side styling that needed a tiny IE-specific hack from 2010. After the 6.9 update, WordPress simply ignores these. Not only that, if you have `WP_DEBUG` set to `true`, you’ll start seeing deprecation notices screaming at you: "IE conditional comments are ignored by all supported browsers." And that was it for my client’s custom admin dashboard layout. Broken. Period.

My first thought, I’ll admit, was to just silence the deprecation notices. Maybe find a quick polyfill or try to re-hook the old conditional logic. But that’s a mistake. A big one. You’d just be patching over a rotting foundation. The reality is, no modern browser uses this stuff anymore. Trying to keep it alive is a waste of time and adds unnecessary bloat. The real fix isn’t to resuscitate IE support, it’s to modernize the code.

The Real Fix: Auditing and Modernizing Your Theme

So, what do you do if your site is relying on this ancient tech? You audit. Go through your theme and any custom plugins. Look for:

• Hardcoded conditional comments in your theme’s `header.php` or `footer.php`.
• `wp_enqueue_script()` or `wp_enqueue_style()` calls using the `conditional` argument.
• IE-specific CSS hacks (like `_filter` or `zoom: 1;` for `hasLayout`) that are no longer needed.
• EOT font files if you’re still using ancient `@font-face` declarations without modern formats.

The solution is almost always to remove these conditional comments entirely and refactor your CSS and JavaScript to be standards-compliant. If there was a specific layout issue in IE, it’s highly unlikely that same issue exists in any modern browser. If you absolutely need browser-specific fixes for current browsers (which is rare these days), use modern feature detection with JavaScript or CSS `@supports` rules, not archaic conditional comments.

For instance, if you had an old conditional style, you’d simply remove the conditional part. For example, replacing a conditional enqueue:

wp_enqueue_style( 'bbioon-ie8-style', get_template_directory_uri() . '/css/ie8.css', array(), '1.0', 'screen', 'IE 8' );

With just a standard enqueue, if the styles are still universally needed (which is unlikely if it was IE-specific):

wp_enqueue_style( 'bbioon-modern-style', get_template_directory_uri() . '/css/modern.css', array(), '1.0', 'screen' );

More often than not, if `ie8.css` contained only IE-specific hacks, you can just delete the file and the enqueue call. The same goes for scripts. WordPress is moving forward, shedding decades of baggage, and our themes and plugins need to follow suit. The official announcement on Make WordPress Core provides more details on this topic, if you’re into that sort of thing.

So, What’s the Point?

The takeaway here is simple: technical debt catches up to you. Ignoring deprecation notices or clinging to outdated browser support isn’t pragmatic; it’s a recipe for headaches down the line. WordPress is streamlining its codebase, and as developers, we need to adapt. This means regularly auditing your custom code, understanding core updates, and ditching anything that only served a browser that’s been in the digital graveyard for years. It keeps your sites lighter, faster, and much easier to maintain.

Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.