• Resolved cognoquest

    (@cognoquest)


    I think I found a problem where the validation errors are not showing on version: 1.6.2.7.1

    I believe the problem is in PDb_FormValidation.class.php the function: get_validation_errors() the faulty code is:

    $error_messages[] = $error == 'nonmatching' ? sprintf( $this->error_messages[$error], $field_atts->title, Participants_Db::column_title( $field_atts->validation ) ) : sprintf( $this->error_messages[$error], $field_atts->title );

    I believe it should be: ... $error != 'nonmatching' ...

    Why I am not sure, is the code for that function has been significantly changed between this version and beta and I am not quite certain what the ‘nonmatching’ means?

    https://www.ads-software.com/plugins/participants-database/

Viewing 15 replies - 1 through 15 (of 16 total)
  • Plugin Author xnau webdesign

    (@xnau)

    The code is correct, it simply chooses a different formatting for the error message if the error is for a “match” validation.

    Are you not seeing any validation error messages at all? Take a look at your template and make sure <?php $this->print_errors(); ?> is where it should be in the template.

    If that isn’t it, supply some more detail of what you’re seeing and we’ll try to fix the problem.

    Thread Starter cognoquest

    (@cognoquest)

    Hello, wow you are fast at responding!!, thks for the help

    The <?php $this->print_errors(); ?> works because the messages appears if I reverse the operator.

    Here is what I get with the == operator:

    <style type=”text/css”>[class*=”pdb-“] [name=”first_name”],
    [class*=”pdb-“] [name=”city”],
    [class*=”pdb-“] [name=”yp_reg_date_of_birth”],
    [class*=”pdb-“] [name=”yp_reg_captcha_verif[]”]{ border: 1px solid red; }</style><div class=”pdb-error”><p></p><p></p><p></p><p></p></div>

    If I dump, Participants_Db::$validation_errors->get_error_fields() & $this->error_messages at the start of the function this is what I get:

    <!-- hello world 1 array(4) {
      ["first_name"]=>
      string(5) "empty"
      ["city"]=>
      string(5) "empty"
      ["yp_reg_date_of_birth"]=>
      string(5) "empty"
      ["yp_reg_captcha_verif"]=>
      string(7) "captcha"
    }
    array(15) {
      [0]=>
      string(7) "invalid"
      [1]=>
      string(5) "empty"
      [2]=>
      string(11) "nonmatching"
      [3]=>
      string(9) "duplicate"
      [4]=>
      string(7) "captcha"
      [5]=>
      string(10) "identifier"
      ["invalid"]=>
      string(85) "The '%s' field appears to be incorrect."
      ["empty"]=>
      string(65) "The '%s' field is required."
      ["nonmatching"]=>
      string(100) "The '%s' field must match the '%s' field."
      ["duplicate"]=>
      string(138) "A record with that %s already exists. Please choose another."
      ["captcha"]=>
      string(91) "Please try the '%s' question again."
      ["identifier"]=>
      string(115) "A record matching that %s cannot be found."
      ["yp_session_req"]=>
      string(46) "At least one Sailing Session must be selected."
      ["participant_age"]=>
      string(73) "Participant age must be between 9 and 20 to be eligible for the programs."
      ["reg_accepted"]=>
      string(37) "A record with that %s already exists."
    }
    -->

    Let me know if you need anything more?

    Plugin Author xnau webdesign

    (@xnau)

    I don’t see a problem…have you checked your PHP error log?

    Thread Starter cognoquest

    (@cognoquest)

    I too am baffled by this problem and after a second look at the code, I agree the code is not the issue here.

    I kept an eye on the Apache Logger and that was not showing any problems. I am new to the PHP/WP world so good on you to remind me about that logging facility.

    I knew something weird was going on here, my code and logger set to display on the web page:

    $error_messages[] = $error == 'nonmatching' ? sprintf( $this->error_messages[$error], $field_atts->title, Participants_Db::column_title( $field_atts->validation ) ) : sprintf( $this->error_messages[$error], $field_atts->title );
    
    echo '<!-- hello world 2 ';
    var_dump( $error );
    var_dump( $this->error_messages[$error] );
    var_dump( $field_atts->title );
    var_dump( $error_messages );
    echo '-->';

    The result:

    Warning: sprintf(): Too few arguments in /var/clearos/wordpress/webroot/live/wp-content/plugins/participants-database-beta/classes/PDb_FormValidation.class.php on line 285
    <!– hello world 2
    string(5) “empty”
    string(65) “The ‘%s’ field is required.”
    string(30) “First Name”
    array(1) {
    [0]=>
    bool(false)
    }
    –>
    Warning: sprintf(): Too few arguments in /var/clearos/wordpress/webroot/live/wp-content/plugins/participants-database-beta/classes/PDb_FormValidation.class.php on line 285
    <!– hello world 2
    string(5) “empty”
    string(65) “The ‘%s’ field is required.”
    string(22) “City”
    array(2) {
    [0]=>
    bool(false)
    [1]=>
    bool(false)
    }
    –>
    Warning: sprintf(): Too few arguments in /var/clearos/wordpress/webroot/live/wp-content/plugins/participants-database-beta/classes/PDb_FormValidation.class.php on line 285
    <!– hello world 2
    string(5) “empty”
    string(65) “The ‘%s’ field is required.”
    string(43) “Date of Birth”
    array(3) {
    [0]=>
    bool(false)
    [1]=>
    bool(false)
    [2]=>
    bool(false)
    }
    –>
    Warning: sprintf(): Too few arguments in /var/clearos/wordpress/webroot/live/wp-content/plugins/participants-database-beta/classes/PDb_FormValidation.class.php on line 285
    <!– hello world 2
    string(7) “invalid”
    string(85) “The ‘%s’ field appears to be incorrect.”
    string(38) “Verification”
    array(4) {
    [0]=>
    bool(false)
    [1]=>
    bool(false)
    [2]=>
    bool(false)
    [3]=>
    bool(false)
    }
    –>

    Hmm interesting problem … it seems like sprintf believes that there is more that one specifier in the variable value for: $this->error_messages[$error]?

    I temporarily reinitialized the variables at the beginning of the function to see if that is indeed the problem by adding:

    $this->error_messages['empty'] = "The '%s' field is required";
    $this->error_messages['invalid'] = "The '%s' field appears to be incorrect.";

    And voila the result:

    <!– hello world 2
    string(5) “empty”
    string(26) “The ‘%s’ field is required”
    string(30) “First Name”
    array(1) {
    [0]=>
    string(54) “The ‘First Name’ field is required”
    }
    –><!– hello world 2
    string(5) “empty”
    string(26) “The ‘%s’ field is required”
    string(22) “City”
    array(2) {
    [0]=>
    string(54) “The ‘First Name’ field is required”
    [1]=>
    string(46) “The ‘City’ field is required”
    }
    –><!– hello world 2
    string(5) “empty”
    string(26) “The ‘%s’ field is required”
    string(43) “Date of Birth”
    array(3) {
    [0]=>
    string(54) “The ‘First Name’ field is required”
    [1]=>
    string(46) “The ‘City’ field is required”
    [2]=>
    string(67) “The ‘Date of Birth’ field is required”
    }
    –><!– hello world 2
    string(7) “invalid”
    string(39) “The ‘%s’ field appears to be incorrect.”
    string(38) “Verification”
    array(4) {
    [0]=>
    string(54) “The ‘First Name’ field is required”
    [1]=>
    string(46) “The ‘City’ field is required”
    [2]=>
    string(67) “The ‘Date of Birth’ field is required”
    [3]=>
    string(75) “The ‘Verification’ field appears to be incorrect.”
    }
    –>

    I think some strange code value that we can not see got introduced in the messages? Unless you have other idea, I think I need to find those messages in the DB?

    Thread Starter cognoquest

    (@cognoquest)

    I think some strange code value that we can not see got introduced in the messages? Unless you have other idea, I think I need to find those messages in the DB?

    Oops I stand corrected it appears to come from the language binary bundle. I am going to attempt to override those messages?

    Thread Starter cognoquest

    (@cognoquest)

    Creating my own language .mo files may not be in the long run the best approach to all this? So I tried the following code:
    $error_messages[] = $error == 'nonmatching' ? sprintf( esc_html( $this->error_messages[$error] ), $field_atts->title, Participants_Db::column_title( $field_atts->validation ) ) : sprintf( esc_html( $this->error_messages[$error] ), $field_atts->title );

    The esc_html() function seem to have resolved my problem. Now you might want to consider resolving this at the source of the problem with: https://codex.www.ads-software.com/Function_Reference/esc_html_2

    If you wish me to try the above solution where the messages are being retrieve let me know?

    Plugin Author xnau webdesign

    (@xnau)

    That’s a good point, but I’m not applying gettext to those error messages because they come from user settings. Gettext can’t work that way because it’s looking for a specific key string, so gettext will not find the translation if the user changes the default settings.

    esc_html() is always a good idea, and it seems to be eliminating the extra placeholder that is somehow getting into the error message strings. I’m adding this to my bug list.

    If you’re running a multilingual site, it works to use an embedded translation in the error message settings, like this:

    [en:]The %s field is required.[de:]Die %s ist erforderlich.[:]

    and so forth. That is the format used by qtranslate, other multilingual plugins may use a different syntax.

    When you’re adding your custom error messages, you should format the different languages like that.

    Does this mean you’ve solved your problem?

    Thread Starter cognoquest

    (@cognoquest)

    You are right the esc_html( $text ) solution will escape all messages and could potentially remove html blocks from custom messages.

    I guess I could go back to my original solution and create a .mo file with the pdb messages that are giving me grief until your next release.

    I also attempted to fix the message source i.e PDb_Settings.class.php but not very successfully at that solution, are these messages being cached after extraction?

    Interesting that you mention qtranslate I really liked the implementation until the volunteer organisation that I am doing this work for decided to not use the plugin. What a mess that made with my application. “c’est la vie” I am still working out the details on how I am going to be using I18N.

    Thread Starter cognoquest

    (@cognoquest)

    I know you have asked me if the problem is resolved?

    There is something not right in all of this. Assuming that it is a gettext() issue. We know from the above tests that it is occurring with two type of messages: empty and invalid. I tried with a different Locale and I am having the same issue. That means we have 4 occurrences of the same type of corruption. The odds are a little off on this one?

    It might be between the PDb_Settings.class.php gettext() and PDb_FormValidation.class.php get_validation_errors() that the corruption is happening. This means an esc_html__( ) at the source would not resolve this problem.

    I am going to research this a little further. But later I have been working on this problem for two days and I am a little burned out.

    Let me know if you have any thoughts on my analysis of the situation?

    Thread Starter cognoquest

    (@cognoquest)

    I am also having the same problem with:

    $this->field->help_text = sprintf(Participants_Db::$plugin_options['id_field_prompt'], $this->field->title);

    in template: pdb-retrieve-default.php this is the help_text not being displayed but same issue:

    Warning: sprintf(): Too few arguments in /var/clearos/wordpress/webroot/live/wp-content/themes/sparkling-child/templates/pdb-retrieve-yp-reg-link.php on line 30

    Plugin Author xnau webdesign

    (@xnau)

    The thing to do in each of these is to see what the raw string going into the sprintf is. That error indicates there is an extra placeholder. If we could see what’s going into the function it might make sense.

    Thread Starter cognoquest

    (@cognoquest)

    The first occurrence I did? I agree I should have done the same on the second occurrence.

    Here is the template code:

    <?php if ($this->field->name == Participants_Db::$plugin_options[‘retrieve_link_identifier’]) {
    $this->field->help_text = sprintf(Participants_Db::$plugin_options[‘id_field_prompt’], $this->field->title);
    echo ‘<!– Hello world 3’;
    echo var_dump( get_locale() );
    echo var_dump( Participants_Db::$plugin_options[‘id_field_prompt’] );
    echo var_dump( $this->field->title );
    echo var_dump( $this->field->help_text );
    echo ‘–>’;
    } ?>

    Here are the results:

    Warning: sprintf(): Too few arguments in /var/clearos/wordpress/webroot/live/wp-content/themes/sparkling-child/templates/pdb-retrieve-yp-reg-link.php on line 30
    <!– Hello world 3
    string(5) “en_US”
    string(130) “Type in your %s, your private link will be emailed to you.”
    string(26) “Email”
    bool(false)
    –>

    Similar issue to the original problem sprintf believes there is an additional specifier in the $format string?

    Plugin Author xnau webdesign

    (@xnau)

    OK, well my guess is translation strings are not getting filtered out…take a look:

    string(130) “Type in your %s, your private link will be emailed to you.”

    That is not a 130-character string, so there is something we’re not seeing.

    Are you using a multilingual plugin?

    What is the setting you have for “ID Field Help Text”?

    Thread Starter cognoquest

    (@cognoquest)

    You are absolutely correct about the string not getting filtered.

    The Lost Private Link ID Field:

    [:en]Type in your %s, your private link will be emailed to you.[:fr]Tapez votre %s, votre lien privé sera envoyé par courriel[:]

    I am using a translation plugin called: qTranslate-X. I have learned that this plugin and possibly more wp translation plugin intercept the buffer stream from many output functions within wp such as: echo …, var_dump( … ), etc… to filter the proper language text. This is why I was confused by the output of these functions.

    Above variable value for Participants_Db::$plugin_options[‘id_field_prompt’] is:

    [:en]Type in your %s, your private link will be emailed to you.[:fr]Tapez votre %s, votre lien privé sera envoyé par courriel[:]

    and variable: $this->field->title is:

    [:en]Email[:fr]Courriel[:]

    Both the echo and the var_dump were showing me the string filtered out by the locale requested:

    ‘Type in your %s, your private link will be emailed to you.’ and ‘Email’.

    I found this out by traversing the variables one character at a time, code example:

    for( $i=0; $i<strlen(Participants_Db::$plugin_options['id_field_prompt']); $i++ ) {
      echo Participants_Db::$plugin_options['id_field_prompt'][$i] . ' Hex: ' .  bin2hex(Participants_Db::$plugin_options['id_field_prompt'][$i]) . PHP_EOL;
    }

    The sprintf(Participants_Db::$plugin_options['id_field_prompt'], $this->field->title); fails because the sprintf sees the complete string untouched by the translation plugin. My immediate though was to replace both %s with %1$s but that does not work. The result after the sprintf conversion would be the following:

    [:en]Type in your [:en]Email[:fr]Courriel[:], your private link will be emailed to you.[:fr]Tapez votre [:en]Email[:fr]Courriel[:], votre lien privé sera envoyé par courriel[:]

    The translation plugin would not know how to resolve the above information. The best solution that I could find is to run the above variables through the pdb translate filter: pdb-translate_string and initiating in that filter, or the generic wp translation apply_filter hook for translation, or a specific translate text function from your translation plugin.

    The template changes is replace the sprintf function by:
    $this->field->help_text = sprintf(Participants_Db::set_filter( 'translate_string', Participants_Db::$plugin_options['id_field_prompt'] ), Participants_Db::set_filter( 'translate_string', $this->field->title ));

    The above validation errors in PDb_FormValidation.class.php. The esc_html() is a good idea but incorrect html tags are not the problem. This function may have fixed the symptoms of the problem but not the source. This is a similar problem to the Lost Private Link ID Field. One example of the problem:
    $this->error_messages[$error], the output from the var_dump( … ) is:

    The ‘%s’ field is required. The the variable value is: [:en]The ‘%s’ field required.[:fr]Le ‘%s’ champ est requis.[:].

    And $field_atts->title. The output from var_dump( … ) is: First Name. The the variable value is:

    [:en] First Name[:fr]Prénom[:]

    The required modifications are similar to the solution found for the Lost Private Link ID Field. Filter the translation the values prior to running the sprintf. By allowing the users of pdb to run the translation plugin function that parses the string, filter the appropriate language text first before the sprintf is applied this will fix the errors that I was having.

    $error_messages[] = $error == 'nonmatching' ? sprintf( Participants_Db::set_filter( 'translate_string', $this->error_messages[$error] ), Participants_Db::set_filter( 'translate_string', $field_atts->title ), Participants_Db::set_filter( 'translate_string', Participants_Db::column_title( $field_atts->validation ) ) ) : sprintf( Participants_Db::set_filter( 'translate_string', $this->error_messages[$error] ), Participants_Db::set_filter( 'translate_string', $field_atts->title ) );

    Roland, Thank you so much for your help.

    Plugin Author xnau webdesign

    (@xnau)

    Thanks for going into so much detail there. I’m working on a more general solution, I probably need to process some or all of the settings through the translation filter at an earlier point so it doesn’t have to be filtered after you’ve gotten the value.

    I’ve worked with q-translateX before and it’s a great plugin…it was easy to add their filtering to my plugin.

Viewing 15 replies - 1 through 15 (of 16 total)
  • The topic ‘Validation Errors are not showing’ is closed to new replies.