[Résolu] Erreurs 500 causées par mauvais RewriteBase dans .htaccess

Bonjour Andrés,

Merci pour votre réponse rapide.

Je n'ai actuellement plus de site de test. Cependant, lors de mes précédentes tentatives, je n'avais pas réussi à reproduire le problème sur celui-ci (ce n'est pas la première fois que je rencontre des erreurs 500).

Il est possible que le souci provienne d'une incompatibilité entre WPML et LiteSpeed Cache. En effet, LiteSpeed Cache ne fonctionne pas sur les sous-domaines comme mon site de test (c'est la seul différence notable avec le site live).

Pour un autre client ayant un environnement très similaire (WPML, LiteSpeed Cache, thème Flatsome) et qui a rencontré le même problème pendant longtemps, j'ai découvert récemment que l'erreur venait d'un mauvais port (11211 au lieu de 6379) configuré dans LiteSpeed Cache pour le cache objet en mode Redis. Cependant, j'ai vérifié pour ce site-ci, et le port est correctement configuré.

Le fix "temporaire" suggéré dans la documentation date déjà de 2017. N'y a-t-il pas eu de nouvelles avancées depuis ? Je me demande, peut-être à tort, si ce fix ne fait que "cacher la misère" sans résoudre le problème à la source.

Merci pour votre aide.

Bonjour Nicolas,
Merci pour votre réponse.

Le problème étant aléatoire, le staging n'avait bien souvent pas de problème durant de longues périodes. La comparaison n'est pas totalement fiable, car le staging est inactif, contrairement au site live qui reçoit des visites et des commandes. Aussi, O2Switch indique que LiteSpeedCache n'est pas compatible sur les sous-domaines donc non actif sur le staging.

Je vais chercher une solution pour pouvoir loguer les appels à la fonction flush_rewrite_rules(true) pour trouver quel plugin/thème génère ces nombreux appels.

Quant à la question de savoir ce que fait le fix temporaire (temporaire depuis 2017 tout de même) proposé par WPML et si celui-ci "cache la misère", la réponse de GPT-4 est la suivante : :

"Le code donné est un correctif temporaire pour un problème où le fichier `.htaccess` est mal écrit à cause de l'interaction entre WPML (un plugin de traduction pour WordPress) et certains autres plugins tiers qui réinitialisent fréquemment les règles de réécriture (`flush_rewrite_rules()`).

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;
}

Voici une explication détaillée de ce que fait le code :

1. **Ajout d'un filtre** : `add_filter('mod_rewrite_rules', 'fix_rewritebase');`
- Ceci ajoute un filtre à la fonction WordPress qui génère les règles de réécriture pour le fichier `.htaccess`. Lorsque WordPress est sur le point de générer ces règles, il passera par notre fonction `fix_rewritebase()`.

2. **Fonction `fix_rewritebase`** :
- Cette fonction prend en entrée les règles actuelles de réécriture (`$rules`).

3. **Récupération de l'URL de base du site** :
- La fonction `parse_url(home_url())` est utilisée pour obtenir l'URL de base de votre site.
- Si une partie 'path' existe dans cette URL, elle est récupérée, sinon, elle utilise `/`.

4. **Récupération de l'URL de base de WPML** :
- La fonction `parse_url(get_option('home'))` est utilisée pour obtenir l'URL de base configurée pour WPML.
- Si une partie 'path' existe dans cette URL, elle est récupérée, sinon, elle utilise `/`.

5. **Remplacement des règles** :
- Le code remplace ensuite deux règles de réécriture dans `$rules` :
- `RewriteBase $home_root` est remplacé par `RewriteBase $wpml_root`
- `RewriteRule . $home_root` est remplacé par `RewriteRule . $wpml_root`

6. **Retour des règles modifiées** :
- Enfin, la fonction retourne les règles modifiées, qui seront alors utilisées pour écrire le fichier `.htaccess`.

En résumé, ce patch modifie la génération du fichier .htaccess pour qu'il utilise l'URL de base de WPML au lieu de celle du site. Cela permet de s'assurer que l'URL correcte est utilisée même si un autre plugin tente de réinitialiser les règles de réécriture pendant que WPML est en cours d'utilisation.

Si vous vous demandez si ce patch "cache la misère", la réponse est oui. C'est en effet un correctif temporaire. Le vrai problème est que le ou les plugins tiers réinitialisent les règles de réécriture trop souvent. Le correctif idéal serait de trouver et de corriger le ou les plugins tiers responsables. En attendant, ce patch empêche le site de se casser à cause de cette interaction."

Merci Nicolas.

Merci Nicolas.
Pour l'instant, pas d'erreur, mais j'aimerais pouvoir dormir sur mes deux oreilles sur le parc de sites où j'utilise WPML.
Dans mon cas, je pense que l'incompatibilité est entre LiteSpeed Cache et WPML car, en dehors de celui-ci, je n'utilise pas de plugins sensibles et j'utilise le thème Flatsome qui est reconnu compatible avec WPML.
Bonne continuation.