qtranslate-xt
qtranslate-xt copied to clipboard
qtranslate
Too many HTTP redirections
The plugin caused AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.
This is a sporadic error that occurs always on a different page showing an Error 500 and it lasts for a couple of seconds showing an Error 500 on any other pages that are called right after. So it basically crashes the server.
With recent Wordpress, all other plugins except for wp bakery deactivated with 2 languages.
It slowly filled the PHP-FPM pool and made the page randomly crash on an error 500 on random pages (when FPM was filled)
It might not do this with any configuration but it did with mine.
LOG File of Redirects: https://0bin.net/paste/MY+Wj6xq#zTZKcsODP95L8tlkkI8cUWH7c0HK-wGWq2f97DkFNRa
CONFIG
{ "default_language": "de", "enabled_languages": [ "de", "en" ], "flag_location": "plugins/qtranslate-xt-master/flags/", "language_name": { "de": "Deutsch", "en": "English" }, "locale": { "de": "de_DE", "en": "en_US" }, "locale_html": { "de": "", "en": "" }, "not_available": { "de": "Leider ist der Eintrag nur auf %LANG:, : und % verfügbar.", "en": "Sorry, this entry is only available in %LANG:, : and %." }, "date_format": { "de": "%A, \\d\\e\\r %e. %B %Y", "en": "%A %B %e%q, %Y" }, "time_format": { "de": "%H:%M", "en": "%I:%M %p" }, "flag": { "de": "de.png", "en": "gb.png" }, "url_mode": 2, "use_strftime": 3, "filter_options_mode": 0, "language_name_case": 0, "detect_browser_language": false, "hide_untranslated": true, "show_displayed_language_prefix": false, "show_alternative_content": false, "hide_default_language": true, "use_secure_cookie": false, "header_css_on": true, "header_css": ".qtranxs_flag_de {background-image: url(https://www.DOMAIN.COM/wp-content/plugins/qtranslate-x/flags/de.png); background-repeat: no-repeat;}\n.qtranxs_flag_en {background-image: url(https://www.DOMAIN.COM/wp-content/plugins/qtranslate-x/flags/gb.png); background-repeat: no-repeat;}\n.qtranxs_flag_nl {background-image: url(https://www.DOMAIN.COM/wp-content/plugins/qtranslate-x/flags/nl.png); background-repeat: no-repeat;}\n", "text_field_filters": [], "term_name": [], "disable_client_cookies": false, "ignore_file_types": [ "gif", "jpg", "jpeg", "png", "svg", "pdf", "swf", "tif", "rar", "zip", "7z", "mpg", "divx", "mpeg", "avi", "css", "js", "mp3", "mp4", "apk" ], "url_info": { "cookie_lang_front": "de", "cookie_lang_admin": "de", "cookie_front_or_admin_found": true, "scheme": "https", "host": "www.DOMAIN.COM", "path": "/wp-admin/admin-ajax.php", "query": "action=admin_debug_info", "path-base": "", "wp-path": "/wp-admin/admin-ajax.php", "language_neutral_path": true, "http_referer": "https://www.DOMAIN.COM/wp-admin/options-general.php?page=qtranslate-xt", "referer_admin": true, "doing_front_end": false, "lang_cookie_admin": "de", "lang_admin": "de", "language": "de", "set_cookie": false, "page_referer": "options-general.php" }, "language": "de", "editor_mode": 0, "highlight_mode": 1, "auto_update_mo": true, "hide_lsb_copy_content": false, "lsb_style": "Simple_Buttons.css", "config_files": [ "./i18n-config.json" ], "custom_i18n_config": [], "custom_fields": [], "custom_field_classes": [], "post_type_excluded": [], "translator": {}, "qtrans_compatibility": false }
If there is more than one redirect coming from qTranslate-XT, it's a bug. Some info here: https://github.com/qtranslate/qtranslate-xt/wiki/Browser-redirection
There are some known limitations if you disable the cookies on the front-end #886, this is still not fixed.
Too many redirections might be due to specific configurations on the web server or problems of integration with other plugin in WordPress.
I have the same sporadic problem and it seems related to one user switching the language. After resaving the permalinks things get more or less back to normal. Do you use trasnsients?
Looking in the log files of my production server I have had bursts of errors of type "AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error" every hour. I suspect that some (many?) of these are triggered by robots. Yesterday I disabled the second language and only left the default language (fr) active. Since then: no errors in the log. My Qtranslate-settings:
- Do not detect browser language
- Pre-path
- Hide URL language info for default language
Yes, same over here. With 1 language it is ok.
I found why these come up sporatically.. The PHP FPM Workerthreads die down.. I have 100 of them.. so only after they are all crashed the site goes down for a couple of seconds.
You can also see that because the crash of one page.. you can call several other pages and they are also error 500. It is the server that goes down.
I have no idea which redirects are causing that.. the limit of redirects is no solution for sure.. I tried it and also discussed it with peers.
The problem needs to be better described technically. You should not have more than 1 redirect. If you have more than one, we must understand why.
Personally I think xtranslate is superior to any other plugin, and I have used many others. Please put work into the plugin especially with good integration of WP Bakery and Elementor this has more future than any of the others.
However with this problem I had to give up at some point and I am sorry that I cannot give you much information.
But I can summarize:
- Website consisting of 100 rather long pages made with WP Bakery.
- 2 Languages are 100% ok over many months before and after this problem.
- This is on an immensly strong server with almost no traffic 64 GB Ram 2x nvme and 18 cores meeting only 20 users per hour.
- From 3 languages the site had serious outages every few minutes.
Problem:
- 3 or more languages made FPM Workers crash and when all of them were crashed it needed to restart the server.
- Reason for crash was infinite redirects
- When the server restarted resulting in an error 500 that lasted for 10 seconds until restart the user would think the last click was the problem. But actually FPM workers were already dieing along the way.
One user writes: "After resaving the permalinks things get more or less back to normal. Do you use trasnsients?" The problem goes back to normal after FPM Workers/server are restarted. It does not have much todo with permalinks.
It is possible that 3 or more languages made the pages too long thinking that internally all languages get saved in the same field. However the pages also got delivered correctly and not incomplete before the crashing. And also an argument against this theory is the strength of this root server.
I would like to measure which redirects were made in the background but did not have a good technique to do that. There are other plugins but they have no problems with 2 languages.
Now I have a better trace for you as this is coming up again now:
`[perdir /home/users/USER/www/DOMAIN/] add path info postfix: /home/users/USER/www/DOMAIN/en -> /home/users/USER/www/DOMAIN/en/index.php, referer: https://www.DOMAIN.at/en/services/support/
[perdir /home/users/USER/www/DOMAIN/] strip per-dir prefix: /home/users/USER/www/DOMAIN/en/index.php -> en/index.php, referer: https://www.DOMAIN.at/en/services/support/
[perdir /home/users/USER/www/DOMAIN/] applying pattern '.*' to uri 'en/index.php', referer: https://www.DOMAIN.at/en/services/support/
[perdir /home/users/USER/www/DOMAIN/] add path info postfix: /home/users/USER/www/DOMAIN/en -> /home/users/USER/www/DOMAIN/en/index.php, referer: https://www.DOMAIN.at/en/services/support/
[perdir /home/users/USER/www/DOMAIN/] strip per-dir prefix: /home/users/USER/www/DOMAIN/en/index.php -> en/index.php, referer: https://www.DOMAIN.at/en/services/support/
[perdir /home/users/USER/www/DOMAIN/] applying pattern '^index\.php$' to uri 'en/index.php', referer: https://www.DOMAIN.at/en/services/support/
[perdir /home/users/USER/www/DOMAIN/] add path info postfix: /home/users/USER/www/DOMAIN/en -> /home/users/USER/www/DOMAIN/en/index.php, referer: https://www.DOMAIN.at/en/services/support/
[perdir /home/users/USER/www/DOMAIN/] strip per-dir prefix: /home/users/USER/www/DOMAIN/en/index.php -> en/index.php, referer: https://www.DOMAIN.at/en/services/support/
[perdir /home/users/USER/www/DOMAIN/] applying pattern '.' to uri 'en/index.php', referer: https://www.DOMAIN.at/en/services/support/
[perdir /home/users/USER/www/DOMAIN/] rewrite 'en/index.php' -> '/en/index.php', referer: https://www.DOMAIN.at/en/services/support/
[perdir /home/users/USER/www/DOMAIN/] trying to replace prefix /home/users/USER/www/DOMAIN/ with /en/, referer: https://www.DOMAIN.at/en/services/support/
[perdir /home/users/USER/www/DOMAIN/] trying to replace context docroot /home/users/USER/www/DOMAIN/ with context prefix , referer: https://www.DOMAIN.at/en/services/support/
[perdir /home/users/USER/www/DOMAIN/] internal redirect with /en/index.php [INTERNAL REDIRECT], referer: https://www.DOMAIN.at/en/services/support/
[perdir /home/users/USER/www/DOMAIN/] add path info postfix: /home/users/USER/www/DOMAIN/en -> /home/users/USER/www/DOMAIN/en/index.php, referer: https://www.DOMAIN.at/en/services/support/
[perdir /home/users/USER/www/DOMAIN/] strip per-dir prefix: /home/users/USER/www/DOMAIN/en/index.php -> en/index.php, referer: https://www.DOMAIN.at/en/services/support/
[perdir /home/users/USER/www/DOMAIN/] applying pattern '.*' to uri 'en/index.php', referer: https://www.DOMAIN.at/en/services/support/
[perdir /home/users/USER/www/DOMAIN/] add path info postfix: /home/users/USER/www/DOMAIN/en -> /home/users/USER/www/DOMAIN/en/index.php, referer: https://www.DOMAIN.at/en/services/support/
[perdir /home/users/USER/www/DOMAIN/] strip per-dir prefix: /home/users/USER/www/DOMAIN/en/index.php -> en/index.php, referer: https://www.DOMAIN.at/en/services/support/
[perdir /home/users/USER/www/DOMAIN/] applying pattern '^index\.php$' to uri 'en/index.php', referer: https://www.DOMAIN.at/en/services/support/
[perdir /home/users/USER/www/DOMAIN/] add path info postfix: /home/users/USER/www/DOMAIN/en -> /home/users/USER/www/DOMAIN/en/index.php, referer: https://www.DOMAIN.at/en/services/support/
[perdir /home/users/USER/www/DOMAIN/] strip per-dir prefix: /home/users/USER/www/DOMAIN/en/index.php -> en/index.php, referer: https://www.DOMAIN.at/en/services/support/
[perdir /home/users/USER/www/DOMAIN/] applying pattern '.' to uri 'en/index.php', referer: https://www.DOMAIN.at/en/services/support/
[perdir /home/users/USER/www/DOMAIN/] rewrite 'en/index.php' -> '/en/index.php', referer: https://www.DOMAIN.at/en/services/support/
[perdir /home/users/USER/www/DOMAIN/] trying to replace prefix /home/users/USER/www/DOMAIN/ with /en/, referer: https://www.DOMAIN.at/en/services/support/
[perdir /home/users/USER/www/DOMAIN/] trying to replace context docroot /home/users/USER/www/DOMAIN/ with context prefix , referer: https://www.DOMAIN.at/en/services/support/
[perdir /home/users/USER/www/DOMAIN/] internal redirect with /en/index.php [INTERNAL REDIRECT], referer: https://www.DOMAIN.at/en/services/support/
AH00124: Request exceeded the limit of 30 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace., referer: https://www.DOMAIN.at/en/services/support/`
The problem needs to be better described technically. You should not have more than 1 redirect. If you have more than one, we must understand why.
I can make tests on my machine for you now. If you have any time to look into this we can get to the root of it.
Hi
We experienced exactly the same issue here. We did get an infinite redirection loop when we activate another plugin who conflited with qtranslate-xt The plugin was : quote-for-woocommerce
Easy to reproduce : install both plugin in the same wordpress + woocommerce website and you'll get your infinite loop
Best Alex
Would be good if there's a way to detect too many redirections, then we could perhaps backtrack and understand the issue better.
I also get Error 500 regularly after some weeks and recently found out that it comes from my .htaccess being modified.
Somehow "RU" regularly gets added to RewriteBase (/RU/ instead of /) and RewriteRule (/ru/index.php instead of index.php). Also the introduction text of this automatically rewritten section in .htaccess gets changed to Russian while German is set as my main language in QTranslateXT.
# BEGIN WordPress
# Директивы (строки) между `BEGIN WordPress` и `END WordPress`
# созданы автоматически и подлежат изменению только через фильтры WordPress.
# Сделанные вручную изменения между этими маркерами будут перезаписаны.
I discovered this old WPML thread that describes a possible reason behind this problem:
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.
Could this be the same reason with QTranslateXT ?
Somehow "RU" regularly gets added to RewriteBase (/RU/ instead of /) and RewriteRule (/ru/index.php instead of index.php). Also the introduction text of this automatically rewritten section in .htaccess gets changed to Russian while German is set as my main language in QTranslateXT.
Today the error appeared again, this time after updating WooCommerce, Woocommerce Weight Based Shipping and Germanized for Woocommerce. And this time /ar/ got added to redirections and the intro text in .htaccess also changed to Arabic.
I couldn't reproduce the error by rolling back those three plugins to a back-uped version and updating them again. Instead, the intro text went back to German after those new updates.