[Resolved] Translating the Login Page on a custom slug
This thread is resolved. Here is a description of the problem and solution.
Problem: You are trying to translate a login page that uses a custom slug instead of the default wp-login.php. While the English version of the login page works correctly, the translated version under /es/[custom-slug] results in a 404 error. This issue arises when using the Defender Pro plugin to rename the login slug, which suggests that the problem is not with BuddyBoss itself but with how the login behavior is modified by the security plugin. Solution: First, verify if Defender Pro supports translating the custom login slug, as the necessary options for translation might not be present. We recommend installing BuddyPress and the security plugin in an isolated sandbox environment to explore possible code workarounds. You can access a sandbox here: sandbox environment. Additionally, consider contacting the authors of Defender Pro and encourage them to join our Go Global program, where we can assist them in making the necessary code adjustments.
If this solution does not resolve your issue or seems outdated, please check for related known issues at https://wpml.org/known-issues/, verify the version of the permanent fix, and confirm that you have installed the latest versions of themes and plugins. We highly recommend opening a new support ticket if the problem persists. You can do so here: WPML support forum.
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.
Background of the issue:
I am trying to translate the login page, which is under a custom slug, not wp-login.php. The English login page works fine, but I encounter a 404 error under /es/[custom-slug]. This is a BuddyBoss login page.
Symptoms:
I get a 404 error when trying to access the translated login page under /es/[custom-slug].
Questions:
How can I translate the login page with a custom slug?
Why am I getting a 404 error on the translated login page?
do you have a staging environment to run some tests? I would eventually also need to request temporary access (WP-Admin and FTP) to your site
– preferably to a test site where the problem has been replicated if possible –
in order to be of better help and check if some configurations might need to be changed
Your next answer will be private which means only you and I have access to it.
❌ Please backup your database and website ❌
✙ I would additionally need your permission to de-activate and re-activate Plugins and the Theme, and to change configurations on the site. This is also a reason the backup is really important.
✙ Please add the Links to the […] Edit Screen, the Page/Post where you insert the […] and the corresponding Front End Page/Screen
No - that's the logged out mobile version of the menu.
In any case, I need domain.com/access to be translated.
The Login button comes from the theme - Buddyboss.
And the Login page is also created by the theme - Buddyboss.
Have you not had people using Buddyboss have this issue?
The /access slug is not a default setting in BuddyBoss, as shown here: BuddyBoss Theme Documentation. Could you clarify where and how you defined this slug?
By default, BuddyBoss uses the standard wp-login.php for login. If you've changed this, we need to identify where the change was made to ensure the function exists. Modifying the default login slug may require a custom solution, as explained here: Customizing the Login URL for Different Languages in BuddyBoss.
Thanks! Actually it looks like their issue is somewhat reverse from ours.
We have a plugin that obfuscates the /wp-login slug and simply replaces it with /access.
So the Login button here: hidden link
Leads to hidden link
But the login button in the spanish version: hidden link
Leads to: hidden link
Which is a 404 - isn't a page.
We want the Spanish version Login button to lead to /access
And we want to translate that page - and so when people go from hidden link to the login page, they get the Spanish version of that login page (hidden link)
thanks for the clarification. So, you're renaming the login slug using Defender Pro. The key point here is that without Defender Pro—when using the default wp-login.php—everything works as expected, and it even includes the language switcher on the login page (which is not viewable when using Defender Pro).
This suggests the issue isn't with BuddyBoss itself, but rather with how the login behavior is being modified by the security plugin.
The main question now is whether Defender Pro supports translating the custom login slug. At the moment, I don’t see any relevant string in the options table that would allow for this kind of translation.
Please install BuddyPress and the security plugin on this isolated sandbox environment so we might can see if a suitable code workaround is possible: hidden link
However, I recommend reaching out to the Defender Pro authors and encouraging them to apply for our Go Global program. Through this program, we can help them find a suitable code change to address the issue.
No, technically the login page isn't a regular WordPress page, so it's not "translated" in the same way as posts, pages, or custom post types. Instead, WPML handles language switching through internal redirection and by setting the appropriate locale.
WordPress uses a single wp-login.php file for all languages. Since it's not part of the WordPress page system, it can't be duplicated or translated per language. WPML ensures the login form appears in the correct language by loading the appropriate translation files—either from WordPress core or from themes and plugins—based on the active locale.
OK, thanks. How can I then force that login url to be/access and not /es/access? Should I set a forwarder, or is there somewhere I can set that 'translation' string? I can't find it when filtering under all strings, either with login or access.
It looks like the security plugin isn’t using proper getText() functions, which means its strings can’t be translated unless they already appear in the translation table.
A forwarder rule could be a potential workaround, or you might need to explore a custom coding solution.
Thank you, we've switched from the directory option to parameters and has solved this issue
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.
