I am running a site with Toolset, WPML, and BuddyPress. I recently completed a fair amount of string translation for BuddyPress. I am seeing a bug where, GIVEN that the WPML String Translation plugin is active, I get an unexpected 404 error when I: 1) browse to a BP page (in Irish), and 2) attempt to browse from the BP page back to a CPT archives page configured using Toolset. Once I clear the page cache from the Performance menu, the 404 page goes away and the desired page reappears. But, if I repeat the above two steps, it always comes back.
If I deactivate the WPML String Translation plugin, I do not get the 404 page.
Is there any documentation that you are following? N/A
Is there a similar example that we can see?
I have identified the reproduction steps for the bug.
Thank you, Alejandro. To test, I downloaded the plugin WP Downgrade on my staging site and set the core version for WordPress to 6.2.2. When I reactivate String Translations, I see the same error.
I've down a fair amount of testing on my staging site. There appear to be multiple factors at play. For instance:
* If I have the GamiPress plugin active, the frequency of 404 errors is much higher. When I deactivate GamiPress, it helps limit the scope of the error, but doesn't eliminate it entirely unless I also deactivate String Translations.
* Curiously, if String Translations is inactive, I can reactivate GamiPress and it runs fine (with the exception, of course, that certain strings across the site aren't translated.)
* If GamiPress is inactive and String Translations is active, there are specific, reproducible steps to demonstrate the error. When browsing the translated site, if I navigate to a BuddyPress page and then try to navigate back to a CPT archive page, I get the 404 error. I can dismiss the error by clearing the page cache using W3 Total Cache.
Let me take over here. Glad to see you are making progress with GaelQuest.
I take it I need to be logged in so that I can navigate to a relevant BuddyPress page before I try to navigate back to an archive page, so can I get credentials from you to be able to do that?
Also, am I to understand that if caching is disabled, the problem doesn't occur at all?
I've set a private reply to get credentials from you.
I disabled caching, and redirection and custom 404 plugins to eliminate those, and I see the problem you describe, and what is particularly odd is that you get the same 404s even if you paste the correct URL into a new browser tab to navigate there directly (even into an Incognito tab).
The only way to "fix" the issue appears to be to log out and back in again.
The role of String Translation here relates to it being used to translate the CPT slug, and that is why it works when ST is disabled.
I've sent this up to my colleagues in second tier to see what insights they may have.
Thanks, Nigel. I'm glad it's not just me. I've really racked my brain trying to troubleshoot this. With W3 Total Cache enabled, I can at least clear the page cache using the Performance menu so that we don't have to log out. But, that doesn't work for my end users.
It occurred to me that the translated CPT slugs could be related. As you talk to your colleagues and think about solutions, I'll share that I'm open to not translating the slugs if there's no other option. It's not my preference, but if simplifying the configuration allows me to put this one to bed quickly and get back to actual content creation, it's a worthy trade-off.
Thanks, Nigel. That's good news! I confirmed that the error is gone when I browse back to the "Taiscéal" page (Step 6 in my private message above.) However, I can still reproduce the error when browsing to the "Teagasc" (Learn) and "Glac Páirt" links, which also correspond to CPT archives. I suspect there are duplicate entries for "learn" and "play" as well.
If you can describe the steps to find and eliminate the duplicates, I'm happy to apply the fix myself.
Also, can you take a look at the possibly related issue I described above:
There's one other curious detail I want to point out. If you browse to your profile page in BuddyPress (hidden link), you'll notice that the page title also reads 'What the devil?" which comes from the custom 404 page. Not sure why that's showing up or whether it's related to the main bug. It happens for both English and Irish.
If it's not related, I can submit a separate issue (if you prefer.)
For the other problem slugs you can go to WPML > String Translation and search for the slug (the screenshot shows searching for "learn").
Where there are two entries, one from Types ("wpcf" domain), one from WordPress, delete the Types entry.
As for the other issue, I've done some testing of different combinations of plugins, and it appears to relate to some interaction between WPML itself and the custom 404 plugin (probably because BuddyPress is "displaying" a post with ID = 0 at that point), but to properly debug it I'd need to take a copy of your site so that I can work on it locally.
Nigel: Based on your description of the interaction between the custom 404 plugin and the profile page in BuddyPress, it occurs to me that this issue is probably not related to WPML. If this is a compatibility issue between those two plugins, it's probably not reasonable to expect your team to troubleshoot it for me.
If you agree let me know and we can close this issue. I found the dupe strings on prod, deleted them, and everything is now working as expected. Thanks!
I took a look at the custom 404 page plugin code, and I see that they already include a WPML compatibility layer (along with compatibility code for other plugins) perhaps it would be best if you could contact them for support.
In this particular context—the BuddyPress profile page while WPML is active—that plugin is wrongly identifying the page as a 404 and replacing the standard 404 template with its own.
Thank you, Nigel! Really appreciate your help here. Beir bua!
Manage Cookie Consent
We use cookies to optimize our website and services. Your consent allows us to process data such as browsing behavior. Not consenting may affect some features.
Functional
Always active
Required for our website to operate and communicate correctly.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
We use these to analyze the statistics of our site. Collected information is completely anonymous.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
These cookies track your browsing to provide ads relevant to you.
