indirectelex
Forum Replies Created
-
Hello @ancavictoria,
I performed some additional testing after updating both websites to TranslatePress Free 3.2.3.
I found what appears to be the cause of the issue. Redirect behavior
Before updating (3.2.1):
https://echodata.ca/→ 301https://echodata.ca/fr/After updating (3.2.3):
https://echodata.ca/→ 301http://echodata.ca/fr/→ 301https://echodata.ca/fr/This was confirmed using:
curl -IL https://echodata.ca/The first redirect is now generated as HTTP instead of HTTPS. Inner pages
The problem appears to affect only the homepage/language-root redirect.
For example:
curl -IL https://echodata.ca/fr/contactreturns:
https://echodata.ca/fr/contact→ https://echodata.ca/fr/contact/→ 200 OKSo inner pages preserve HTTPS correctly. Mobile behavior
Another important observation is that after updating to 3.2.3, my desktop browser can sometimes still access the site, but my phone can no longer load any page, including inner pages such as:
https://echodata.ca/fr/contactThis behavior disappears when I roll back to TranslatePress 3.2.1. Environment
- WordPress
- TranslatePress Free
- Astra Pro
- WP Rocket
- Cloudflare (Full Strict SSL)
- Apache
- Valid Let’s Encrypt certificate
- Nginx Proxy Manager (reverse proxy)
The affected site is served publicly over HTTPS, but Nginx Proxy Manager forwards requests internally to WordPress over HTTP (port 80). This configuration works correctly with TranslatePress 3.2.1, but not with 3.2.2 or 3.2.3.
I hope this additional information helps identify the regression. If you need me to perform any additional tests, I’d be happy to help.
To clarify my setup: both
echodata.caandsignal.echodata.caare behind Nginx Proxy Manager on the same VM/IP.echodata.cais proxied internally tohttp://my-ip:80, whilesignal.echodata.cais proxied internally tohttps://my-ip:443.
The affected site isechodata.ca. Publicly it is accessed over HTTPS through Cloudflare/NPM, but internally NPM forwards it to WordPress over HTTP. This worked correctly with TranslatePress 3.2.1, but the homepage/language-root HTTPS warning appears after 3.2.2/3.2.3.Additional information: Both websites are currently running TranslatePress Free 3.2.1. I plan to update both installations to 3.2.3 to verify whether having both websites on the same TranslatePress version affects this issue. I’ll report back with the results.
I think there is a situation where landing on the front page make that issue. echodata.ca/fr/fr will actually lead to a 404 error page from wordpress, but echodata.ca/, echodata.ca/en or echodata.ca/fr will have the https error. echodata.ca/en/entreprises or any other pages will work…
The new update is installed and the exact problem persist.
- This reply was modified 1 month, 4 weeks ago by indirectelex.
Ok, I will test this version now. Thanks.
The issue is no longer occurring because I rolled back to the previous TranslatePress version.
After updating to the latest version, the HTTPS/security warning appeared again. Once I restored/rolled back to the previous version, the warning disappeared.
My environment:
- WordPress behind Cloudflare (SSL mode: Full (Strict))
- WordPress URLs use https://
- Apache + MariaDB
- WP Rocket enabled
- Brave browser (although the problem also appeared when accessing the site directly)
During troubleshooting I verified that:
- The database credentials were correct.
WP_HOMEandWP_SITEURLwere set tohttps://echodata.ca.- Cloudflare SSL configuration was unchanged.
- The issue disappeared immediately after restoring the previous VM snapshot / previous TranslatePress version.
While the issue was present, I observed:
https://echodata.caredirected unexpectedly./fr/returned incorrect behavior (404/redirects depending on the attempted fix).- WordPress sometimes generated HTTP URLs instead of HTTPS URLs for translated pages.
Since restoring the previous version, the site works normally again without changing the server or Cloudflare configuration.
This makes me believe the issue is related to the latest TranslatePress update rather than my server configuration.
Here are the screenshots from when the problem occurred:
https://snipboard.io/6ToRhH.jpg https://snipboard.io/F73iQX.jpgThe problem occur when I update from Version 3.2.1 to Version 3.2.2
