How I Fixed WPML .htaccess Overwrite Issue in 5 Minutes

As a WordPress developer, encountering unexpected issues is almost inevitable. Recently, I faced a peculiar problem: my
.htaccess file was being overwritten with the language folder path on a WPML-powered website,
causing significant front-end issues. After a bit of investigation, I discovered that the culprit was a plugin excessively calling the
flush_rewrite_rules(true) function. Here’s how I identified the problem and resolved it in just five minutes.

The Problem: WPML and .htaccess Conflict

On my WPML-enabled website, every time I browsed the site in another language, the .htaccess file was overwritten
with incorrect rewrite rules. The culprit? A plugin was calling WordPress’s flush_rewrite_rules(true) function far too
often, triggering the .htaccess rewrite process unnecessarily.

This behavior resulted in WPML adding the language folder to home_url() correctly but also inadvertently modifying the
RewriteBase in the .htaccess file, breaking the site’s front-end.

What Is flush_rewrite_rules(true)?

The flush_rewrite_rules(true) function regenerates WordPress’s rewrite rules, which dictate how URLs are handled.
It’s an essential function, but when called too frequently—especially during every page request—it can lead to issues, such as
the one I encountered.

The Culprit: A Third-Party Plugin

The plugin responsible for the issue was wpml, which was flushing rewrite rules excessively.
Although the plugin worked well otherwise, its misuse of this function caused the conflict with WPML.

The Quick Fix

After identifying the problem, I implemented a workaround that prevented WPML from adding the language folder to the
.htaccess file. Here’s the code I added to my theme’s functions.php file:

add_filter('mod_rewrite_rules', 'fix_rewritebase');
function fix_rewritebase($rules){
    $home_root = parse_url(home_url());
    if ( isset( $home_root['path'] ) ) {
        $home_root = trailingslashit($home_root['path']);
    } else {
        $home_root = '/';
    }
  
    $wpml_root = parse_url(get_option('home'));
    if ( isset( $wpml_root['path'] ) ) {
        $wpml_root = trailingslashit($wpml_root['path']);
    } else {
        $wpml_root = '/';
    }
  
    $rules = str_replace("RewriteBase $home_root", "RewriteBase $wpml_root", $rules);
    $rules = str_replace("RewriteRule . $home_root", "RewriteRule . $wpml_root", $rules);
  
    return $rules;
}

Why This Fix Works

This code hooks into the mod_rewrite_rules filter and adjusts the rewrite rules dynamically. It ensures the
RewriteBase and rewrite rules in .htaccess match the correct path set by WPML, eliminating the
conflict caused by the rogue plugin.

Additional WordPress Services

If you’re encountering issues like this—or more general WordPress problems such as HTTP 500 Internal Server Errors—we can help! At 3 Zero Digital, we specialize in diagnosing and resolving WordPress errors efficiently, so you can focus on growing your business.

Final Thoughts

In just five minutes, I was able to resolve a potentially time-consuming issue by adding a small snippet to my theme. If you’re encountering similar problems with WPML and .htaccess, this approach might save you a lot of trouble. And don’t forget to reach out to the plugin developer to address the root cause.

Have you faced similar WordPress challenges? Share your experiences in the comments below!