[Resolved] Languages switcher shortcode changed in translations
This thread is resolved. Here is a description of the problem and solution.
Problem: The client is using the shortcode [wpml_disabled_selector_widget] to display the language switcher on their site. However, when the translator, who has the subscriber role, translates content using the classic translation editor, the translated content shows the shortcode as [wpml_disabled_selector_widget] with an error message "You're not allowed to use this shortcode." in the front end. Solution: We investigated whether this issue was specific to the client's website or a general bug. We suggested testing with only the Divi parent theme and WPML plugins enabled to isolate the issue. Additionally, we identified that the problem stems from the 'unfiltered_html' permission in WordPress, which is not granted to users with the subscriber role for security reasons. This permission prevents certain users from using advanced HTML or scripts in posts. We recommended using the Advanced Translation Editor (ATE), which does not have this limitation, and ensuring all translations are re-sent and re-translated using ATE.
If this solution does not resolve your issue, or if it seems outdated or irrelevant to your case, 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 problems persist, please open a new support ticket at WPML support forum for further assistance.
0% of people find this useful.
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 use the shortcode [wpml_disabled_selector_widget] to display the language switcher on my site hidden link. The translator, who has the WP user role subscriber, translates with the classic translation editor.
Symptoms:
When I receive the translated content, the shortcode in the translations is [wpml_disabled_selector_widget], which shows "You're not allowed to use this shortcode." in the front end.
Questions:
Why does the translation get a different shortcode?
thanks for getting back and sharing video, that is very helpfully.
Now we need to confirm if it is an bug or issue specify to your website.
1) If possible, can you test if issue happens when using Divi parent theme and only WPML plugins enabled, all other disabled?
2) For same reason a created test site with Divi, and tried to translate, but I do not get same issue, maybe there is specific Divi widget that needs to be used?
Can you please check and try to reproduce it there? That way I can quickly escalate it further.
1. Have a look as the demo user: there is one page, translations are correct
2. Send that page to the 'translator' user
3. Login as the 'translator' user, pw: rdD$wewRvakKUVhQ%sRkVBbw
4. Take the translations, make sure the shortcode in the source and target is the same and complete the translations
5. Have a look at the translated page, it shows "You're not allowed to use this shortcode."
6. Go back to the translations and you'll see the shortcode is incorrectly saved.
It doesn't make sense to me. There is a perfectly working shortcode in the source, so that same shortcode goes in the translation for a good reason. There is absolutely no reason for WPML damaging/changing it's own shortcode (or any other shortcode for that matter).
Third party translators should only translate and do nothing else. Therefore they get the lowest WP role possible, which is a 'subscriber'. The next lowest role is a 'contributor' but they can also write posts. A translator shouldn't be doing that.
Of course I can add that constant as a workaround, but why should I even be doing that if all I want is that a translator does the only thing WPML is meant to be doing? Nothing else.
Update to the previous, I have checked this further, and 'intentional' setting means that a translator needs to be a WP editor or admin to be able to use the same shortcode in the translations as is added to the source. This basically gives the translators the right to also edit all content and create/publish anything they like.
That's not very well thought out. A translator should only translate and shortcodes in their translations should remain the same as in the source. WPML shouldn't damage them. And a translation manager or site admin shouldn't be required to a constant to disable this silly behaviour and make sure WPML does what it is supposed to do.
it is due the user role and unfiltered_html permission. This is more related Worpdress roles and capabilities then only WPML, but of course we respect it for security reasons.
The unfiltered_html permission is a security feature in WordPress that prevents users from using iframes and code snippets in WordPress posts, plus also more advanced code such as Javascript. This unfiltered_html permission could be very dangerous in the wrong hands, so WordPress has disabled this permission for most users.
By default, the unfiltered_html permission is only given to Super Admins, Administrators and Editors.
It does not happen for ATE editor and works fine if you use ATE translation editor.
As for constant not working, please make sure to re-send and re-translate. I have tested it before sharing it with you, and it works just fine on our side. I can share a video if needed.
It doesn't work for me. See this video: hidden link
I know what the permission is for, but it absolutely makes no sense that WPML replaces it's own shortcode with something else. As if it doesn't trust itself. It cripples it's own functionality.
You also see @0:33 in the video referenced above that the third party shortcode [ masterslider id="17" ] is kept as is in the translation.
A translator, regardless what user role, should be able to use the same shortcodes that are also located in the source.
So, it's only WPML's own shortcode that is being replaced. If that's not a bug, I don't know what else to call it.
thanks for getting back, I understand your point of way, but I am afraid as I have explained above and there is working workaround / constant , our 2nd tier does not consider this a bug and the esclated ticket is closed from our side.
If you disagree I can bring this up again and ask for second opinion.
As for issue, please try to make a small change to default language page, save and then re-translate. If issue still happens please wp-admin access and FTP to your website, preferably staging site and I will check it out.
