All add-ons currently require PHP 7.4 or greater.
On July 4th 2024 PHP 8.2 will be the new minimum requirement for all add-ons. Expect any add-on released after that date to require 8.2 or greater. Some releases may not immediately take advantage of 8.x specific features in PHP, which means you might, be able to continue using new releases in PHP 7.4, however, if you experience an error the first thing you should do is update to PHP 8.2 then create a support ticket if the error persists.
Publisher does not support the Fluid field type. Please do not contact asking when support will be available.
If you purchased an add-on from expressionengine.com, be sure to visit boldminded.com/claim to add the license to your account here on boldminded.com.
Ticket: Redirect loop warning message and error on Android
| Status | Resolved |
| Add-on / Version | Publisher 2.10.1 |
| Severity | |
| EE Version | 4.3.6 |
AdriaanSnoeren.com
Nov 02, 2018As seen before we experience a redirect issue when changing language from a secondary to the primary language. For instance, if we manually change url from /en to / we get a warning in Chrome about too many redirects. See screenshot. It does redirect to the right page eventually. The problem also exists with the language switch.
We also access the website from an Android app and there the site isn’t loaded at all and shows: net::ERR_TOO_MANY_REDIRECTS
One of the app developer suspects the following having something to do with the issue:
< X-Publisher-Redirect: Url->redirect() called by BoldMinded\Publisher\Service\Session->changeLanguage on line 847
FYI: there is nog language switch active on the page yet. But we have /en and the Dutch site running on /
BoldMinded (Brian)
Is this a new install of Publisher or on an existing site? What has changed recently? Usually a too many redirects issue is b/c something else (not Publisher) is trying to perform redirects as well. It could be a {redirect=”“} tag in the template, another add-on, JavaScript, or a server side redirect (e.g. htaccess or Apache virtual host).
Did you check all of those things and try to reduce the template code involve, e.g. strip out everything that isn’t necessary to change languages?
What are the URLs that are involved in the redirect loop? What URL did you start on and what URL is it redirecting to?
What are your Publisher > Settings > URL Translations set to? Screenshot would help. Did you try changing any options, e.g. force the language prefix in all languages at all times?
Ignore Android in this case, if it happens on Android it happens anywhere, this is a server side issue, not client side (unless of course you have some JavaScript involved that could be issuing redirects).
BoldMinded (Brian)
Also, do you mind sharing the URL that the redirects happen on?
AdriaanSnoeren.com
Comment has been marked private.
AdriaanSnoeren.com
Comment has been marked private.
BoldMinded (Brian)
Adriaan, an issue like this is probably one of the hardest to debug, if not impossible, without server access so I can step through it. Even with that said, I’m still leaning toward this being an issue in your environment. Those URL Translation settings are pretty typical, so if there was a wide spread bug with redirections I would probably have other similar bug reports, but I don’t. You’ll probably need to do some debugging to figure this out. To help with that, in the addon.setup.php file in Publisher is a function called writeToFile that is commented out. Remove the comments so it is active:
https://d.pr/i/pFiLGO
Then around line 847 of the Session file, as indicated in that debugging message, call that function:
https://d.pr/i/v1kqv1
The load the page and let it do its redirects, then check the cache folder for the file you just created to see what it prints in it. It may help show why its redirecting.
If nothing helpful is logged to that file, go further up in the changeLanguage() method and add writeToFile calls there too, to see which part of that function is getting called or not getting called.
BoldMinded (Brian)
I’m going to https://www.abbi-insights.com/ and I don’t see any redirects happening. Please provide more detailed instructions on how to replicate the redirect issue. Is there a different URL I should be going to?
AdriaanSnoeren.com
Ok, I’ll try to debug this more on our side today with your input.
If you go directly to https://www.abbi-insights.com/ there is not an issue. It’s when you are on the English site on https://www.abbi-insights.com/en and then return to the Dutch site. There is no language picker active yet. Guess the Android issue occurs when the device/browser is set to English and they call the site from the webview.
AdriaanSnoeren.com
Comment has been marked private.
BoldMinded (Brian)
I can try to look into this if you provide FTP credentials, and double check that the files in the add-ons folder can be edited and saved. Since this appears to not be a wide spread issue, and only happening in your environment, I will have to mention the conflict resolution portion of my support terms https://boldminded.com/support-terms-conditions If I spend time debugging this, and it turns out it is not related to Publisher, and is due to a template, htaccess, or some other server config, then I can invoke the choice of charging for my time spent debugging the issue. Is that OK?
BoldMinded (Brian)
Also, before I dig into this, have you tried re-creating the issue in a new/clean EE environment? E.g. create only the necessary templates, template code, and entries needed to replicate it? I would prefer to debug the clean environment instead of digging around in your full site. If it can be re-created in a clean environment then it may lessen the chance that it is an environment issue and more of an add-on/Publisher issue.
BoldMinded (Brian)
FWIW, I don’t see redirect issues using Firefox. I can switch between EN and NL just fine.
BoldMinded (Brian)
Closing this out b/c of no response in nearly a month.
AdriaanSnoeren.com
Just want to give you an update as we picked this up this morning. The simple solution was changing the redirection type in the settings from 301 to 302. I’ve implemented it that way on multiple sites now and we don’t get the error in Chrome anymore. FYI, the same behaviour was visible on different servers. One Nginx the other not for instance. Both server settings do have a permanent 301 redirect from http to https. I see this as solved now but still believe something with the 301 redirect is not 100% working. Thanks again!