[Resolved] Incorrect notification being sent when site used in German

[Author]

Posts

[Nigel]

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.

Please bear with me.

[Nigel]

OK, I identified the problem and have passed all of the details on to the developers.

In the meantime, I made some minor changes to the plugin file which you can use for now.

Remove your current installation of Toolset Forms and replace it with the one you can download from here:

hidden link

Please test and confirm that it works.

[simonM-5]

Hi Nigel

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?

Kind regards
Simon

[Nigel]

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.)

[simonM-5]

Hi Nigel

I tested your modified plugin on dev, still on WordPress 6.3.2. It is now sending out the correct notification!

So that just leaves my open questions from my reply:
https://toolset.com/forums/topic/incorrect-notification-being-sent-when-site-used-in-german/#post-2660165

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?

Thanks and best regards
Simon

[Nigel]

I'm glad that worked!

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.

[simonM-5]

Hi Nigel

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?

I see you answered a previous customer the following:
https://toolset.com/forums/topic/is-there-any-documentation-for-new-shortcode-cred_i18n/#post-1841845

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.

Thanks and kind regards
Simon

[Nigel]

4b)

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.

[simonM-5]

HI Nigel

4b) Even after de-activating WPML I'm still only seeing 15 forms, not 28 or 29 under Toolset > Post Forms.

3f) OK, great!

3c/3e) Hard to say, until I get can rid of the obsolete German metadata somehow...

Thanks and regards
Simon

[Nigel]

OK, let's try the code route.

I have added the below snippet to Toolset > Settings > Custom Code in a snippet called delete-form-translations.

The code only needs to be run once, and I have not run it.

Can you please take a backup, and then when you are ready try running the code once.

That should remove the translated form posts (both Post forms and User forms).

// switch language to German
do_action( 'wpml_switch_language', 'de' );

// get cred-form && cred-user-form posts
$forms = get_posts([
    'post_type' => array( 'cred-form', 'cred-user-form' ),
    'numberposts' => -1,
    'post_status' => 'any',
    'suppress_filters' => false,
    'fields' => 'ids'
]);

// delete them (and their related data)
foreach ($forms as $form) {
    wp_delete_post( $form, true );
}

If anything goes wrong you will have the backup to revert to.

[simonM-5]

Hi Nigel

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?

Thanks and best regards
Simon

[Nigel]

Yes, the code is very simple, it should work fine in the production environment, too.

Again, take a backup before you run the code, just in case.

[simonM-5]

Hi Nigel

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?

Thanks and best regards
Simon

[Nigel]

To be honest the default settings for the post types for templates and Views look a little odd to me, but I assume there are reasons.

With respect to 2) first, the correct way to translate most Toolset items is now via Translation Management, as described here: https://toolset.com/course-lesson/translating-views-content-templates-archives-and-forms/

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.

[simonM-5]

Hi Nigel

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 ...

Thanks and kind regards
Simon