I had a client running WordPress for years on a custom theme built way back. It was solid for its time, but it hadn’t had a real audit in ages. They updated to WordPress 6.9 and the admin area fell apart. A few custom fields rendered wrong and some legacy scripts stopped firing. It all traced back to one thing: the removal of old Internet Explorer code.
IE has been dead for years. WordPress officially dropped IE11 support back in version 5.8, in July 2021. When 6.9 came around, the core team finally cleared out a big pile of code that existed only for IE compatibility. Good riddance: less cruft, a faster core. For older custom-built sites, though, this is where the cleanup starts, and where you can hit snags if you are not paying attention.
Understanding WordPress IE support removal
The change most likely to bite you is the removal of support for IE conditional scripts and styles. Remember those? Back in the day we used conditional comments to load CSS or JavaScript just for IE, like this:
<!--[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 maybe you used the conditional argument with wp_enqueue_script() or wp_enqueue_style(). My client’s theme did exactly that, for some admin-side styling that leaned on a tiny IE-specific hack from 2010. After the 6.9 update, WordPress just ignores these. On top of that, with WP_DEBUG set to true, you start getting deprecation notices: “IE conditional comments are ignored by all supported browsers.” That was the end of my client’s custom admin dashboard layout. Broken.
My first instinct, I will admit, was to just silence the deprecation notices. Find a quick polyfill, maybe re-hook the old conditional logic. That would be a mistake. You would only be patching over a rotting foundation. No modern browser uses any of this anymore, so keeping it alive just wastes time and adds bloat. The fix modernizes the code instead of trying to resuscitate IE support.
Auditing and modernizing your theme
So what do you do if your site still leans on this ancient tech? You audit. Go through your theme and any custom plugins. Look for:
- Hardcoded conditional comments in your theme’s
header.phporfooter.php. wp_enqueue_script()orwp_enqueue_style()calls using theconditionalargument.- IE-specific CSS hacks such as
_filterorzoom: 1;forhasLayoutthat you no longer need. - EOT font files if you are still running old
@font-facedeclarations without modern formats.
The fix is almost always to remove the conditional comments entirely and refactor your CSS and JavaScript to be standards-compliant. If IE had a specific layout problem, that same problem almost never shows up in a modern browser. On the rare occasion you do need a browser-specific fix for current browsers, reach for feature detection in JavaScript or CSS @supports rules instead of old conditional comments.
For example, an old conditional style just loses its conditional part. Say you are replacing a conditional enqueue like this:
wp_enqueue_style( 'bbioon-ie8-style', get_template_directory_uri() . '/css/ie8.css', array(), '1.0', 'screen', 'IE 8' );You swap it for a standard enqueue, assuming the styles are even still needed, which is unlikely if they were 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 held only IE-specific hacks, you can just delete the file and its enqueue call. Same goes for the scripts. WordPress keeps moving forward and shedding years of baggage, and our themes and plugins have to keep up. The official announcement on Make WordPress Core has more detail if you want to dig in.
So, what’s the point?
Technical debt catches up with you. Ignoring deprecation notices or clinging to dead browser support is not pragmatic, it just stores up headaches for later. WordPress is trimming its codebase, and developers have to move with it. That means auditing your custom code now and then, keeping an eye on core updates, and dropping anything that only ever propped up a browser nobody has used in years. Your sites end up lighter and easier to maintain.
This stuff gets complicated fast. If you are tired of debugging someone else’s mess and just want your site to work, drop my team a line. We have probably seen it before.
