This is the technical support forum for WPML - the multilingual WordPress plugin.
Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.
Tagged: Exception
This topic contains 10 replies, has 1 voice.
Last updated by Garrett McGilvray 3 days, 4 hours ago.
Assisted by: Bobby.
Author | Posts |
---|---|
June 13, 2025 at 9:54 pm #17134795 | |
Garrett McGilvray |
Background of the issue: Symptoms: Questions: |
June 13, 2025 at 9:58 pm #17134819 | |
Garrett McGilvray |
By the way, I find the reporting processes confusing. I was not aware that my report was going to be rewritten by AI. Since I had copied what I wrote in the "Instead I found" section, I am able to paste it back into this thread. Unfortunately I did not copy the other portions, so I feel like a lot of time of trying to give a careful and thorough report of my steps is partially lost. ----------- From the "Instead I found" field -------- After logging into one domain and then navigating via frontend to the other language, I find that I am not logged in on that domain, as evidenced by no WP user bar. Additionally, I am not able to go to a backend URL of the other domain directly without logging in to that domain. TESTING PROCEDURE WHAT I TRIED Since this is a fresh installation of WordPress with the default theme and no additional plugins except three WPML plugins that I use on my other sites, I conclude this is likely a WPML bug. I created this test environment on a live server so that I may share the credentials with you for you to investigate. Tell me how to privately provide login credentials, and I will. The ultimate reason that brought me here is that we are adding a new language to one of our sites, and while that language is configured as hidden, we are unable to view the pages even when logged in as an admin user configured to show hidden languages. When I try to view such a page, it returns me back to the home page of the primary domain. I suspect that this issue I reported is related, because I am not signed in on the other domain, and I have no way to sign in on the other domain of a hidden language, because even when I try to sign in to the direct address for the new site for the hidden language, it just sends me back to the home page of the primary domain. |
June 17, 2025 at 7:35 pm #17143930 | |
Bobby WPML Supporter since 04/2015
Languages: English (English ) Timezone: America/Los_Angeles (GMT-07:00) |
Hi there, Thank you for sharing this information with us! With WPML temporarily deactivated are you able to access both URLs OK? hidden link hidden link Both URLs should be accessed OK even with WPML deactivated in order for this to work OK. If they do not there is a chance the configuration was done properly This test is also recommended in our documentation here: |
June 17, 2025 at 8:33 pm #17144074 | |
Garrett McGilvray |
Thank you for your response. I have performed your test: 1. I logged in to that site and deactivated all WPML plugins (which, in this test case, means that no plugins are active). 2. In a new private browser window (logged out), I clicked each of your links to test each domain exactly as you typed them. The result was that both domains were accessible. They both went to the same home page, although they both were in French, the primary language, which would be expected with WPML deactivated. I also read the article you linked, and it said that they should all show “the same site without a redirection.” They are not set up to redirect: each is a unique domain that points to the same server directory. Just to make sure, I visited each domain to confirm a 200 response code. So the issue still remains. Let me know if you have other suggestions. I am also happy to provide login credentials for this test site: it was set up explicitly for this test, including the possibility that you may need to log in. After trying your test, I have now reactived WPML. |
June 18, 2025 at 7:33 pm #17148095 | |
Bobby WPML Supporter since 04/2015
Languages: English (English ) Timezone: America/Los_Angeles (GMT-07:00) |
I would like to request temporary access (wp-admin and FTP) to your site to test the issue. **Before we proceed It is necessary to take FULL BACKUP of your database and your website. Providing us with access, you agree that a backup has been taken ** I often use the Duplicator plugin for this purpose: http://wordpress.org/plugins/duplicator/ NOTE: If access to the live site is not possible and the staging site does not exist please provide me with a duplicator package created with the duplicator plugin. Thank you, |
June 24, 2025 at 7:32 pm #17166575 | |
Garrett McGilvray |
I have heard back from my host. The FTP access details I gave you are correct. Just note that FTP over TLS is required, such as the option "Use explicit FTP over TLS if available" |
June 25, 2025 at 9:27 pm #17170921 | |
Bobby WPML Supporter since 04/2015
Languages: English (English ) Timezone: America/Los_Angeles (GMT-07:00) |
Thank you for providing the access details. I’ve tested the feature, and it’s working as expected. I was able to sign in on one domain and remain logged in across both domains simultaneously. Signing out from one domain also successfully signed me out from both. It looks like the issue does not reproduce in this staging environment, can you please confirm? |
June 26, 2025 at 4:58 pm #17174818 | |
Garrett McGilvray |
I can confirm that I am reproducing the issue on the testing site that we have been looking at. I have recorded a screencast to demonstrate, available at this link (or please let me know if you have an alternate way you wish to access it): hidden link After I first tried to start fresh with a different browser, plugins disabled, and cache cleared for the relevant sites, these are the steps I followed in the first part of the video to demonstrate the issue. 1. Logged in to wpmltest.editionsceb.com admin. Is this expected? Thus far it is sufficient to demonstrate the problem, but in the video I also tried a couple other things to further investigate the problem. |
June 27, 2025 at 7:03 am #17175940 | |
Bobby WPML Supporter since 04/2015
Languages: English (English ) Timezone: America/Los_Angeles (GMT-07:00) |
I can clearly see the issue in your screencast, however, my experience as you can see in the following video is different as I can't reproduce the behavior. hidden link Update: Are you testing in an incognito window? I was able to reproduce the issue when testing in an incognito window only. |
June 27, 2025 at 9:56 pm #17178766 | |
Garrett McGilvray |
Thank you for working through this. Regarding your question, no, I was not using a private or incognito window in my video. However, your observation that you were able to reproduce the issue only when in Chrome’s incognito mode is an excellent clue. For one thing, it means you have a recipe to reproduce the issue I am having. But secondly, it is the clue that leads us to identify the problem. I have done some digging, and I have discovered it has to do with the growing trend among browsers to block third-party (cross-site) cookies. I have narrowed it down to the “Prevent cross-site tracking” setting in Safari and the “Block third-party cookies” setting in Brave. Toggling these settings on and off in my testing has shown that the problem can be reproduced or avoided depending on what these are set to. As I understand it, you should be able to confirm that you can reproduce the problem in Chrome even when not in Incognito mode if you go to the “Privacy and Security” and set “Third-Party Cookies” to “Block all third-party cookies.” There does not seem to be any way to work around this other than to change the browser settings. In Safari, it is a global setting, so I am not interested in making that change. In Brave, the setting is per-domain, so I can allow it on my own sites, since I know what cookies are being used for there. Going forward, this feature may need to be revisited by the WPML development team. It seems all of the major browsers allow third-party cookies to be disabled, and Safari, Brave, and Firefox now do so by default. In 2023, Google officially stated, “If your site uses third-party cookies, it’s time to take action as we approach their deprecation” (hidden link). However, I read on another site that this year they reversed that policy for their own browser; they have different priorities than the more privacy-focused browsers. In Google, it is on by default only in Incognito mode, as you discovered. Their help documentation stills says that it is also blocked by default for a test group of 1% of users. If no change in how this feature is implemented is intended, then I would at least recommend some documentation that cross-site cookies must be allowed for the feature to work. Thank you for passing this limitation on to the team. I assume that my testing site is no longer needed. Please confirm, because if you do not need it any more, I will delete it. |
June 30, 2025 at 9:34 pm #17186097 | |
Bobby WPML Supporter since 04/2015
Languages: English (English ) Timezone: America/Los_Angeles (GMT-07:00) |
Thank you for updating me! You are absolutely correct, I also did an internal search and can confirm that we do have an active internal discussion with our dev team regarding this behavior and you can also find a relative answer regarding this in the following thread: For the staging site, please feel free to remove. Thank you! |
July 2, 2025 at 9:27 pm #17194886 | |
Garrett McGilvray |
Thank you for your help. This is too bad, but I understand this will not be an easy issue to overcome, if it is even reasonable to do so at all. Fortunately for our sites, it is mostly only an annoyance to me. I only recommend adding some documentation for now, probably in the little info tip where the setting may be activated. That could save the next person from a lot of troubleshooting. |