[Resolved] Incorrect notification being sent when site used in German
This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.
No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.
OK, good news—of sorts—is that I have managed to recreate the problem on a clean test site.
I have a similar set-up as on your own site, with just the bare minimum details required to reproduce the same workflows, and I get the same problem when sending the form in German, the wrong notification is sent.
It means I have something concrete to work with, so hopefully I'll be able to identify the cause and propose a solution.
Great news that the issue has been identified and passed to 2nd level already.
Quick question: I just updated to the latest versions of the Toolset Forms plugin as advised by Dario in preparation for WordPress 6.4. If I install your temporary plugin version, will there be conflicts with WordPress 6.4 due out today?
We are experiencing some problems with the new releases, and I expect changes to be made to those very soon (later today or tomorrow).
I would avoid updating plugins and WordPress just yet to avoid potential unrelated problems, and first confirm if the fix I created works as expected.
Once the dust has settled I will make the same adjustments to the new version of Forms and you can use that. (I will create an erratum about this issue and include a link to the patched plugin.)
in particular, or most importantly, to points:
3c - Is "Post Form" the same as "Toolset Form"? Perhaps have this renamed consistently throughout the plugins?
3e - How to delete the invisible form "TEST" safely and completely?
3f - [wpml-string] strings not being offered for translation using "new" translation method
4a - is the "old" translation always gonna remain supported?
4b - How to delete the unused German versions of the forms safely and completely?
I patched the current Toolset Forms version (2.6.19) with the same workaround, which—for now—you can download from here: hidden link
The problems we had with the initial releases yesterday have been resolved so you should be good to update all Toolset plugins.
Back to your questions:
3c: I can't see your translation queue (I'm not the translator), but my understanding is that "Toolset Form" refers to any form created with Toolset (post or user), while "Post Form" would refer specifically to a form to publish posts (as distinct from a form to register users).
3e: I'm not sure what you are referring to. I searched in the database directly and I cannot find a form entry with a title containing "test".
3f: This appears related to the changes in how forms are translated. In my screenshot you can see a simple form (expert mode), where the form labels are wrapped not in wpml-string shortcodes but cred-i18n shortcodes. So I added some static text using both shortcodes and then sent the form for translation, and found that the text within the cred-i18n shortcodes was offered for translation, but not the text within the wpml-string shortcodes. It would still be possible to go to WPML > String Translation and locate that text for translation, which should then work when rendering the form. But a better alternative might be to update your forms to use the cred-i18n shortcode for static texts to be translated.
4a: There is no reason to think it will not work in the future, I don't envisage any changes in Toolset that would affect this, and from WPML's perspective Toolset Forms are just another post type that is translatable or not, with embedded strings translated via String Translation.
4b: You would want to go to WPML > Settings and make Toolset Forms translatable. That way when you go to Toolset > Post Forms you should have the language switcher available in the toolbar to switch to the list of German forms. You can delete them from there. Afterwards revert the Toolset Forms post type to not translatable.
Thanks for the modified plugin on the latest version! 🙂
Regarding your responses to the points:
3c) When I go to WPML > Translations (see screenshot) and filter on Type = Post Form - I only see the 14 Post Forms, if I filter on Type = Toolset Form, I only see the "new" form "Post Form - Create Job Ad".
3e) When I go to WPML > Translation Management (see screenshot) and:
- filter on Post Forms, I see all 15 post forms, the 14 "old" ones and the one "new" one.
- filter on User Forms, I see our 3 user forms
- filter on Toolset Forms, I see the 14 old Post Forms, 1 new Post Form, 3 User Forms and another form called TEST.
3f) I'm unsure which screenshot you are referring to. However what I'm understanding is that the [cred_i18n] shortcode has replaced [wpml-string] shortcodes when creating forms, right? I thought perhaps that [cred_i18n] was reserved for the title of the fields. I replaced those two instances of [wpml-string]s with [cred_i18n]s and sent it for translation and now they're showing up. Now under String Translation I see toolset-forms-26883 (58), which was previously 56. Still one out compared to the old form toolset-forms-929 (59), possibly a title or something?
Your last sentence:
"It is no longer necessary to use wpml-string shortcodes to make text available in WPML String Translation."
- Can you please confirm this is limited to Forms only and not Views as well?
- Additionally it might be nice to include this here: https://toolset.com/documentation/programmer-reference/forms/cred-shortcodes/
4a) OK, great! Sounds like it will remain supported.
4b) Even with Post Forms set to Translatable under WPML > Settings, I don't see the language flag when I go to Toolset > Post Forms, so it's impossible to delete the German versions via the GUI safely.
Sorry, I expected the language switcher to be available, but it appears that the changes which were made to the form translation workflow has disabled that entirely, including when post forms are set as translatable.
The easiest way to delete the German forms in that case is to temporarily de-activate WPML. Then when you go to Toolset > Post Forms you will see all forms, regardless of language. You can delete them from there, and it will delete the posts and associated meta data. When complete you can re-activate WPML.
After that it would be a good idea to go to WPML > Support > Troubleshooting and run the "Remove ghost entries..." clean up operation.
I'm suggesting this as a possibility because you are working on the staging version of your site. If it is not an option I could draft a PHP code snippet to do it for you instead. Let me know.
3f) Yes, it relates to Forms only, not to Views, where you would still be expected to use the wpml-string shortcode.
I have created a ticket for our documentation team to update the page of Forms Shortcodes to include details of the cred_i18n shortcode.
3c and 3e) What appears on the Translation Management page appears correct, with Toolset Forms referring to both post forms and user forms. What appears on the translation queue according to your description (I can't see it as I'm not the translator) does seem confusing, but because of the changes to the workflows it's not something I can even test. You created translations of the forms themselves (rather than just the form texts) with older versions, which is no longer possible. In the context of the new workflows I'm not sure we need to do anything here.
That code appears to have done the trick! Comparing our dev site with our www site where I haven't run that code, and applying the same filtering in WPML > Translation Management screens I can see the difference, the German versions all appear to have gone.
Looking at that code, it looks fairly generic (ie site independent). It would be safe to just copy to www and run there, once I have finished cleaning up/updating/translating/testing the forms on dev, right?
I suspect I might have the same issue with obsolete German versions of Views and View Templates.
Comparing a brand new sandbox installation the post types "view" and "view-template" are set as in the screenshot. In our dev and www, I think they are both on Not Translatable.
1) I attempted to modify your code to remove German versions of post types "view" and "view-template". Does it look OK to you, and would it be safe to handle in the similar fashion?
// switch language to German
do_action( 'wpml_switch_language', 'de' );
// get view && view-template posts
$views = get_posts([
'post_type' => array( 'view', 'view-template' ),
'numberposts' => -1,
'post_status' => 'any',
'suppress_filters' => false,
'fields' => 'ids'
]);
// delete them (and their related data)
foreach ($views as $view) {
wp_delete_post( $view, true );
}
2) The "correct", new way to translate would be then to send these items to the queue for translation, right?
3) Any particular reason why View Templates are set on a virgin installation to Translatable "use translation if available or fallback to default language" instead of Not Translatable?
Views are different: you translate the page where you inserted the View block to create the View.
But! This reflects the modern workflow for creating Views, i.e. inserting a View block into a page and designing the View there.
I don't think the same applies to legacy Views, I think they still need to be translated the legacy way, which is to say you don't translate the View itself, you use String Translation to translate the texts contained in the View, wrapped in wpml-string shortcodes.
So I wouldn't expect you to have translated View posts, even with the legacy editor.
Similarly with legacy Content Templates, you could translate the texts within the template using String Translation. The only time you would translate the Content Template post itself would be if you wanted to do more than translate the corresponding text, e.g. if you wanted a different layout altogether for different languages, rather than the same layout but the text translated.
So, your edits to the code would do what you expect, but I'm not sure that's the right thing to do based on what I describe above.
Thanks for the explanation. That makes sense with Views/Pages.
I think you hit the nail on the head in the penultimate paragraph: that would be one good reason why one might want to allow Content Templates to be translatable but to use the fallback in original language should the layout differ for a different language.
The reason why I suspected I might have obsolete German views knocking around on the database is due to my screenshot here: there you can see an identical number of "Not Used" Views. I seem to remember having problems with translations years ago and trying to solve it by unlocking the Views and trying to translate them. Then some plugin update blocked the WPML flag switching in Toolset > Views and I was left a bit stumped ...
simonM-5 confirmed that the issue was resolved on 2024-02-14 10:26:26.
This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.
