Thanks for the feedback Jamal.
As for others unexpected results of "Editing in secondary language, then saving the form" there is also the select field of the page to redirect to after submission that is empty when editing in a secondary language even if a page was set which is probably due to WPML query filtering.
Do not hesitate to tell me if you need anything else and have a nice day.
I must confess this was rather trivial to spot, but I somehow missed it. The forms have the "Répéter le mot de passe" string hardcoded. Check this screenshot hidden link
Once, I manually edited the form and used the English string, the issue did not appear, even if I saved the form while I am still on the secondary language. The string was registered as English, and it uses the existing French translation for the French page.
I suspect that this was generated automatically during form creation on the secondary language, so I tested on my test site and when the form creation wizard starts it makes sure that the current admin language is English.
At this stage, we can consider the label a minor issue, and I would like to check with you the redirection page. Can you please run some tests on both language and let me know if any issue appears on the frontend? What steps should I follow to reproduce it?
I forgot to mention the migrated site hidden link
Please log into it to check how the label issue is now fixed for the form on the /registration/ page.
Thanks for the feedback Jamal, I checked on the migrated site and confirm that the label is kept as long as I do not use the visual editor but it won't be ok for our customer to edit it this way so I hope it may be fixed for the visual editor two. The best would be to be able to define the label for the repeat password field in the password field setting the same way we can define all other labels but just having it saved in the correct language, which means always in default one, would also be ok for me.
As for the fact that it was registered during form creation, I can tell you it's not the case as the issue also occurs if the form is created using default language (label correct) and then edited in another language (label wrong) as well as it can be fixed by editing the form again in default language once it has been changed by mistake.
In fact, you're right to say that "when the form creation wizard starts it makes sure that the current admin language is English." but it's unfortunately not the case for the edit view and the string is not so hardcoded as it's replaced according to the language used each time the form is edited using visual editor. If the edit view was performing the same check as the creation wizard and would then switch to default language if needed, the problem would not even exist.
And finally, regarding the redirection page, the steps to reproduce are nearly the same :
- Create a form in default language, choose a page to redirect to and save
- Edit the form in a secondary language, the page set does not appear in the field and you can't select it again as the pages are filtered by WPML so it won't even appear.
- If you save the form without selecting a secondary language page (which you do not want to do as you are editing a default language form) the redirection does not work anymore.
Do not hesitate to tell me if you need anything else and have a nice day.
Hello and my apologies for the late reply. I understand your point of view, and I am discussing this case with our 2nd Tier. I'll get back to you about it.
In the meantime, I worked on a custom code solution that could help a little to make sure that the user is editing a user form on the default language. I tested it locally and it alerts the user about it and will not let him edit until the language is switched to the primary language. Add the following code in a Toolset custom code snippet and activate it for the WP Admin:
<?php
/**
* New custom code snippet (replace this with snippet description).
*/
toolset_snippet_security_check() or die( 'Direct access is not allowed' );
// Put the code of your snippet below this comment.
add_action( 'current_screen', 'ts_current_screen' );
function ts_current_screen( $screen ){
if ( in_array( $screen->post_type, array( 'cred-user-form' ) ) ){
add_action( 'admin_print_footer_scripts', 'ts_enqueue_custom_js_code', 1 );
}
}
function ts_enqueue_custom_js_code(){
?>
<script type='text/javascript'>
var tsGetCurrentLanguage = function(){
var pairs = document.cookie.split(";")
for (var i=0; i<pairs.length; i++){
var pair = pairs[i].split("=");
if ( /wp-wpml_current_admin_language/.test(pair[0]) ) {
return unescape(pair.slice(1).join('='));
}
}
}
var tsCheck = function(current, def){
if( current != def ){
alert('You are editing a form in a secondary language. Make sure to switch to default language before saving the form');
}
}
jQuery(document).ready(function($) {
var current_language = "<?php echo apply_filters('wpml_default_language', NULL ); ?>";
tsCheck(current_language, tsGetCurrentLanguage());
jQuery(window).focus(function(){
tsCheck(current_language, tsGetCurrentLanguage());
})
})
</script>
<?php
}
Let me know how it goes for you, and I'll get back to you as soon as we have something else to share.
Well could have been a good fix but :
- I loose one more field this way as the role to be created comes empty and the page to redirect to still is (see screenshot 1)
- I cannot switch language as no language switcher displays on the page or if it does it's under the message that I can't close
- As I can't close the message I can't leave the form other way than using back browser functionalities so not ideal
Based on this I also tried to switch language when entering the list view :
add_action( 'toolset_page_CRED_User_Forms', 'force_default_language' );
function force_default_language(){
do_action( 'wpml_switch_language', 'en' );
}
The language is correctly switched when entering the list view but once I edit the form it still displays in french.
Then I tried to do the same once in the edit view :
add_action( 'cred_ext_cred_user_form_settings', 'force_default_language' );
function force_default_language(){
do_action( 'wpml_switch_language', 'en' );
}
But the result is even stranger. As you will see in screenshot 2 the language switch seems to be running correctly but the form still displays in french as if language was switched back to French just before displaying the set of fields.
Any other idea ?
Well, I'll expect side effects with the way you are switching the language with. And I'll stick with my suggestion. In fact, my code is meant to lock that page until it is closed and language is correctly switched from somewhere else(another tab).
I can agree that this is not a perfect solution, but I believe it will guarantee that the edit is made on the primary language. We could improve the code by adding a redirect after the alert. For example, adding a Javascript redirection after the alert and redirecting to the admin dashboard in the default language, the user can then open the form again for edit. Does it make sense? I am testing it now on the migrated site hidden link
See lines 31-32 on this updated code:
<?php
/**
* New custom code snippet (replace this with snippet description).
*/
toolset_snippet_security_check() or die( 'Direct access is not allowed' );
// Put the code of your snippet below this comment.
add_action( 'current_screen', 'ts_current_screen' );
function ts_current_screen( $screen ){
if ( in_array( $screen->post_type, array( 'cred-user-form' ) ) ){
add_action( 'admin_print_footer_scripts', 'ts_enqueue_custom_js_code', 1 );
}
}
function ts_enqueue_custom_js_code(){
?>
<script type='text/javascript'>
var tsGetCurrentLanguage = function(){
var pairs = document.cookie.split(";")
for (var i=0; i<pairs.length; i++){
var pair = pairs[i].split("=");
if ( /wp-wpml_current_admin_language/.test(pair[0]) ) {
return unescape(pair.slice(1).join('='));
}
}
}
var tsCheck = function(current, def){
if( current != def ){
alert('You are editing a form in a secondary language. Make sure to switch to default language before saving the form');
var admin_url = "<?php echo admin_url( "index.php?lang=en&admin_bar=1" ); ?>";
window.location.assign(admin_url);
}
}
jQuery(document).ready(function($) {
var current_language = "<?php echo apply_filters('wpml_default_language', NULL ); ?>";
tsCheck(current_language, tsGetCurrentLanguage());
jQuery(window).focus(function(){
tsCheck(current_language, tsGetCurrentLanguage());
})
})
</script>
<?php
}
Well it could help but having the problem really fixed would be better as all these solutions are not really user friendly and the concerned users in my case are not advanced enough to go through such UI tricks without getting definitely lost as it's already difficult for them when everything is working perfectly.
If, at least, language switcher was available on the list view, I guess a simple notice would be enough but as long as that they have to go somewhere else to change language and come back, I can't really call it a correct solution as it's not better than doing the same manually once you see the page is not appearing in the field.
Anyway, do not waste more time on a workaround for that, I'll see what I can imagine on my own until it's eventually fixed, maybe I can get the language switcher to show up on these pages or simply avoid using redirection and care about the labels another way.
What about the third problem :
[wpv-login-form] does not display (all languages) if added to the message to be displayed after CRED form submission, this even if the form is edited in default language when adding the shortcode and then translated.
Is there a fix for that one ?
I understand your point of view, and it is escalated to our 2nd tier. I'll keep you updated about it as soon as possible.
Regarding the [wpv-login-form] issue, I am not sure to follow. We have already detected that it happens for websites with language in URL parameters, and we have escalated it to the developers. Is there something else I am missing?
The [wpv-login-form] issue we already discussed was the one with access post groups which was fixed by switching WPML settings to "Different languages in directories".
What I am talking about now is the fact the login form shortcode does not seem to work if added to the message to display after a user form submission (see attached screenshots). You can test it on hidden link.
Of course it's a minor issue as I can replace it by a button or link to take users to a login page or use a redirection after submission but I still would be interested in knowing the reason why it does not display there.
That does not seems to be supported. The views shortcodes are actually evaluated with the context of the current page. But, the wpv-login-form is not. It does not return anything.
I tried a couple of workaround, to no avail. One of them is to register a custom shortcode that calls the wp_login_form function. The login form is rendered, but it is the first thing to be rendered on the page, then comes anything else within the form's message. hidden link
In the meantime, our 2nd Tier is working on the "user form editing in the secondary language" case. I'll keep you updated.
Ok, Jamal, forget about the user form / login shortcode issue, I'll do with a simple button.
Have a nice day.
Good news for the user edit issue. Our 2nd Tier has shared a custom code that will make sure that editing a form(user or post) is done on the default language. I tested it on the migrated site, and on your sandbox and it works correctly:
add_action( 'current_screen', 'ts_enforce_form_language' );
function ts_enforce_form_language( $screen ){
if ( in_array( $screen->id, array( 'cred-form', 'cred-user-form' ) ) ){
$default = apply_filters( 'wpml_default_language', NULL );
$current = apply_filters( 'wpml_current_language', NULL );
if ( $default != $current ){
do_action( 'wpml_switch_language', $default );
}
}
}
However, regarding the customization of the "Repeat Password" label, please ask for it as a new feature here https://toolset.com/home/contact-us/suggest-a-new-feature-for-toolset/
It works like a charm and solves the last issue I had with user forms.
Thanks a lot for your help and have a nice day.
