Skip Navigation


Overview of the issue

In certain cases, the .htacess may get overwritten with the language folder. However, this issue is not caused by WPML.

The problem actually comes from certain third-party plugins calling flush_rewrite_rules(true) function too often. This causes WordPress to overwrite .htaccess. However, in some cases, this happens so often, sometimes even on every page request, that it’s called while browsing the front-end in another language.

When this happens, WPML goes ahead and adds the language folder to home_url as usual. This, however, results with an incorrect RewriteBase in .htaccess and ends up breaking the front-end.


The proper fix is for the third-party plugin to flush the rewrite rules only once. This would result in better performance of plugins in question because flushing rewrite rules is a server-expensive operation and extra care should be taken.

However, we can also avoid the language folder from being added within WPML. As a temporary workaround you can add the following lines to the functions.php of your theme:

Temporary workaround for avoiding the language folder from being added
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;

There are many different cases depending on the plugin you are using, so if you need more help please report in our support and we’ll help you.

23 Responses to “.htaccess is rewritten with language folder”

  1. hello
    this fix works with standard wordpress
    but when use other plugin as HideMyWP that create new rule in htaccess there are some fix to add

    Ex. plugin add:
    RewriteRule ^other/(.*) /it/wp-includes/$1?iLuK_hmwp=xxxxxxx [QSA,L]
    RewriteRule ^file/(.*) /it/wp-content/uploads/$1?iLuK_hmwp=xxxxxxx [QSA,L]
    RewriteRule ^ext/(.*) /it/wp-content/plugins/$1?iLuK_hmwp=xxxxxxx [QSA,L]
    ….. and many other ….

    how can extend fix_rewritebase to fix /it/ adding base into this RewriteRule too?

    • Hello Matteo,

      Looking at the forum thread you’ve linked, Itamar, the supporter who was taking care of the issue, is waiting for a feedback from you.

      Please continue in the forum, as there is where we can provide you better and faster support.


        • Hello Matteo,

          We have a possible fix in our queue.

          If everything looks good, it will be included in WPML 4.0.0.

          Unfortunately, I can’t provide you with an ETA yet.

          We have provided here a workaround which should solve the problem for the time being.

          If that’s not the case, please continue in the support forum, as we can’t provide proper support through post’ comments.

  2. It seems that is why I got “too many redirects”.

    Should I wait for WPML version4 and use the above php snippet for temporary?


    • Can you please post about it in our support? A supporter will need to see more details of your site to figure out what’s wrong and fix it.

  3. I noticed this issue too for our site! It apparently isnt fixed? Im getting tons of internal redirect issues! What to do?

    • Hi there, sorry for that – I have just reopened the ticket – mind you, Bruno is away today so expect a reply tomorrow (Monday).

  4. I’ve had this problem for years. I’ve finally gotten around to checking out which of my plugins call flush_rewrite_rules. This is the ful list of suspects; no other plugins on my site call flush_rewrite_rules().

    We can probably rule out JetPack, since I don’t use Portfolios or Testimonials, so call to flush_rewrite_rules() after creating those custom post types should not happen, I think.

    Which leaves WooCommerce, WooCommerce Multilngual, and WPML String Translation. Two of those are WPML-related. Could it be that this issue is caused by a WPML-related plugin after all?

    – portfolios.php
    – testimonial.php

    – class-wc-admin-settings.php
    – class-wc-api-products.php
    – class-wc-install.php
    – class-wc-post-types.php
    – class-wc-rest-prodict-attributes-v1-controller.php
    – wc.attribute-functions.php
    – wc-core-functions.php

    WooCommerce Multilingual
    – class-wcml-endpoints-legacy.php
    – class-wcml-install.php
    – class-wcml-upgrade.php
    – Hooks.php

    WPML String Translation
    – Hooks.php

  5. Hi, same annoying problem here in the last few days…
    Finger crossed for identify the cause and… the solution!

  6. Hi support,

    Having 500 internal server error quite often lately.
    “The Work around” mentionioned on the top does not work at all.

    Issue arise while we are trying to change something in the post of othe language or just by clicking “view” in the dashboard….

    So beause of that, WPML change my .htaccess rule regulary

    RewriteEngine On
    RewriteBase /fr/
    RewriteRule ^index\.php$ – [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /fr/index.php [L]

    So I would need to fix this manually by applying the correct rules every single time which is not a solution…..

    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ – [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]

    Please advise