Home›Support›English Support›[Resolved] How to Dynamically Change the author_base URL Slug by Language in WordPress?
[Resolved] How to Dynamically Change the author_base URL Slug by Language in WordPress?
This thread is resolved. Here is a description of the problem and solution.
Problem: You are working on a multilingual WordPress site using WPML and trying to adjust the author_base URL slug based on the user's language. You want different slugs for each supported language (English, Spanish, German, Dutch). However, changing author_base requires flushing the rewrite rules, which sets it for all languages until it is saved again in another language.
Solution: We recommend using the wpml_current_language filter to dynamically fetch the current language. Implement this by replacing your current language detection with:
apply_filters('wpml_current_language', NULL);
Ensure to flush rewrite rules only when necessary to minimize performance impact. This can be done by checking if the current language setting has changed compared to the last saved setting in the WordPress options. If they match, there is no need to flush the rewrite rules. If they do not match, update the
author_base
, flush the rewrite rules, and update the saved option to reflect the new current language.
If this solution does not fully address your issue or seems outdated, we highly recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If further assistance is needed, please open a new support ticket.
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.
I am working on a multilingual WordPress site using WPML and I am trying to adjust the author_base URL slug based on the user's language. My goal is to have different slugs for each supported language (English, Spanish, German, Dutch), like 'author' for English, 'autor' for Spanish, etc.
Here is the current implementation in the theme:
function custom_author_base() {
global $wp_rewrite;
global $sitepress;
$current_language = '';
if (isset($sitepress)) {
$current_language = ICL_LANGUAGE_CODE;
}
Please do forgive me the messy code. I am simply testing this to find a solution.
The issue is changing author_base requires flushing the rewrite rules. However, if I do this in one language (e.g., Spanish), the author_base is set to 'autor' for all languages until it is saved again in another language (e.g., Dutch), which then sets it to 'auteur' for all languages.
Is there a way to dynamically change the author_base based on the frontend language without the negative impact of continually needing to flush the rewrite rules? I've looked through the WordPress Codex and WPML documentation but haven't found a solution yet. Any suggestions or insights are greatly appreciated.
before your ticket is assigned to one of my colleagues, please allow me to walk you through some initial debugging steps. This will help speed up the support process.
Using wpml_switch_language offers several benefits. It ensures that the author_base is updated whenever the language changes, maintaining correct URLs across different language contexts. The implementation also needs to flush rewrite rules when the language is switched. In your case, it may be sufficient to call it only when the language setting changes, rather than on every single page load with something like
...
if (array_key_exists($current_language, $author_slugs)) {
$wp_rewrite->author_base = $author_slugs[$current_language];
} else {
$wp_rewrite->author_base = 'author';
}
// It's crucial to flush rewrite rules, but we do it only when necessary
$wp_rewrite->flush_rules(false);
}
}
If you need further help, I recommend you contact one of our certified contractors, who can help you implement that custom solution. You can find them here: https://wpml.org/contractors/.
Thanks for your extensive response! You are of course completely right about me not using the right filter.
However, I still have issues with this approach. The biggest one is the fact that we are dealing with thousands of concurrent users. This would force my site to flush the rewrite rules every time someone enters the site, and every time someone uses the language switcher. That alone is a huge performance issue, but it will also cause conflicts between those users.
The original issue therefore still remains: Users get rewrite rules from another language than the one they are using at that moment.
Do I understand this right, or am I misunderstanding something?
This would force my site to flush the rewrite rules every time someone enters the site, and every time someone uses the language switcher.
WordPress provides an API for storing, retrieving, and updating options in its database. These options can be used for various settings within a WordPress site, ranging from simple theme settings to more complex plugin data management. The functions involved typically are:
get_option($option, $default): Retrieves an option value based on its name. If the option does not exist, it returns a default value.
update_option($option, $value): This function updates the value of an option. If the option does not exist, it will be created.
My basic idea was to prevent that when you adjust author_base according to the site's current language, you also save this setting (i.e., the current language) as an option in the WordPress database. This record tells you what the author_base was last set to. The next time a request comes in, before making any changes to the author_base and flushing the rewrite rules, the code first retrieves the LAST saved language setting from the WordPress options. It then compares this saved value with the current language setting.
If the current language matches the saved option value, there is no need to change the author_base or flush the rewrite rules because it indicates that there have been no changes since the last setup. If they do not match, it updates the author_base, flushes the rewrite rules to apply the change, and updates the saved option to reflect the new current language.
That way you avoid unnecessary flushes of write rules and minimize the impact on your site's performance, as that changes are only made when the configuration of the language setting changes in the backend, not merely when a user switches the language on the frontend of the website.
Best Regards
Marcel
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.