cognoquest

Yes, indeed it would be nice if I could make the fields read-only but these fields are part of a three step signup.

The first step is the signup(multi-page), where the participants are requested to fill the information.

The second step is the confirmation/agreement page, accessed via email. The confirmation displays some of the fields from the first step registration, this time in read-only.

It may seem that the read-only fields are little overkill but this allows the registration to flow nicely in the third step which is the payment. Though I am still working on this step, until now the find job you have done with the pdb, (fingers crossed) the payment integration is well on its way. F.Y.I. I am using the PayPal PHP REST api to proceed with the payment portion.

Again you have my gratitude.

Thanks You

Thanks again – wouldn’t have got this far without you, cognoquest.

Your welcome, for your last challenge, I am not sure but if your are good at css maybe you can hide the buttons on the edit form?

Something that resembles to this:

.admin_page_participants-database-edit_participant input.button-primary {

  visibility: hidden;

}

So basically all we can do, by the looks of things, is customise what the plugin’s “Edit” and “Admin” roles allow – we cannot add a third.

Yes and no. Indeed pdb has two roles pre-configured in its settings for different purposes.

In your particular case the pdb developer uses WP add_submenu_page() to determine whether or not a page is included in the menu and it is the capability given to that function that determines the access. The second example that I provided made use of the pdb setting for your default configuration.

The first example would also have worked if you wish to completely bypass the pdb settings but you will be required to program all the user access permutations for record_edit_capability/context: main admin menu, list participants, edit participant, add participant.

Do not forget the WP capabilities is an access grid of capabilities vs roles. In other words you can return any capability for the above function add_submenu_page() to interpret.

Your welcome.

it’s hard to find every little string and make sure they get internationalized.

I completely understand and you have my gratitude.

Sorry I have to rethink this because pdb comes in with two access capabilities that are pre-configures in the settings i.e. Record Edit Access Level & Admin Access Level. You can not use the filter unless you are using the access configured in the pdb settings.
If you are going to create your own role capability you will have to set it in pdb as the Record Edit Access Level and code the following for your filter hook.

function rms_read_only_db_access($cap, $context) {

  if ($cap === Participants_Db::plugin_setting('record_edit_capability')  && ($context === 'edit participant' || $context === 'add participant')) {
    return 'read'; // Hopefully this removes the edit link inside the list and the add participant access ??
  } 

  return $cap;
}

Your welcome Tim. Yes you can put the code in the function (Note it is not recommended)

add_filter('pdb-access_capability', 'rms_read_only_db_access', 10, 2);

I think you are on the right track. I do see as an issue with your code is that edit participant is accessed via a link in the participant list

What I would do:

function rms_read_only_db_access($cap, $context) {
  if ($context === 'edit participant' || $context === 'add participant') {
    return; // Hopefully this removes the edit link inside the list and the add participant??
  }
  if (current_user_can('view_members') && $context === 'list participants') {
    return Participants_Db::plugin_setting('record_edit_capability'); // Returns to pdb the Record Edit Access Level from your Settings
  }

  return $cap;
}

You may want to exclude the admin (Plugin Admin Access Level settings) from the above process and I would add the following code at the top of the above function:

if ($cap === Participants_Db::plugin_setting('plugin_admin_capability') return $cap;

Again this is all untested code and I am not the pdb developer

Tim since I am looking at a permission scheme for my application. I wipped up some quick code for you. This might not be exactly what you want but should give you a better idea of how Roland uses the wp roles with pdb

add_filter('pdb-access_capability', array(__CLASS__, 'rms_read_only_db_access'), 10, 2);
function rms_read_only_db_access($cap, $context) {
  if ($context === 'edit participant' || $context === 'add participant') {
     // ** Tim you need to change the myUserCanWrite **
     if (wp_get_current_user() === 'myUserCanWrite') {
       return 'edit_others_posts'; // Users with write capabilities see: https://codex.www.ads-software.com/Roles_and_Capabilities
     } else {
       return 'read';
     }
  }

  return $cap;
}

You are welcome. Indeed executing the translation filter at an earlier stage did cross my mind and a better solution. I hesitated because of the pdb-validation_error_messages filter. You are going to have to make a design decision if the translation filter will be executed prior or after that execution.

I also like the implementation of qtranslate-x that uses wp WP_Translator interface and hooks making its use very easy: qtranslate-x Interface WP_Translator

You have also done a great job with your plugin. Regards …

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.

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?

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

I think I now have the theme that I am using more or less under control. I should provide some feedback from my learning experiences.

The theme that I am working with is called Sparkling and made by Colorlib. The below configuration is specifically tuned for the following pdb templates:

• pdb-signup-default.php
• pdb-record-default.php
• pdb-retrieve-default.php

The above templates where copied/renamed into the child theme that I created and slightly adjusted for my needs. The pdb-retrieve-default.php template was modified to make use of a set of composite fields to do its retrieval, hence similar table format to the signup and record templates.

The top <div> tag of the templates was adjusted to include a unique identifier: ‘myapp-signup’ The purpose of the unique identifier is to allow the use of pdb for a specific web application context, at the same time prepares the use of pdb form elements for different context. I suggest that you rename ‘myapp-signup’ to a name of your choice.

Templates:

<div class=”wrap <?php echo $this->wrap_class ?> myapp-signup”>

The Custom css was added to pdb Custom Plugin Stylesheet in Participants Database Settings.

.myapp-signup tr.checkbox, .myapp-signup tr.radio {
/* Table cell alignment */
display: table-row;
}

.myapp-signup tr.checkbox input[type=checkbox], .myapp-signup tr.checkbox-inline input[type=checkbox], .myapp-signup tr.radio input[type=radio], .myapp-signup tr.radio-inline input[type=radio] {
/* Vertical alignment */
position:static;
}

.myapp-signup .selectother label, .myapp-signup .multicheckbox label, .myapp-signup .file-delete label, .myapp-signup .csv-export label, .myapp-signup .radio-group label, .myapp-signup .myapp-signup .radio-subgroup label, .myapp-signup .othercontrol {
/* Remove bold from all the above form elements */
font-weight: normal;
}

.myapp-signup tr.checkbox th, td {
/* Provides some space inside within the boxes */
padding: 5px;
/* Grey */
border: 1px solid #D3D3D3;
}
.myapp-signup tr.checkbox:hover td {
/* Highlight table rows on mouse over */
background-color: #f5f5f5;
}
.myapp-signup tr.date th, td {
/* Provides some space inside within the boxes */
padding: 5px;
/* Grey */
border: 1px solid #D3D3D3;
}
.myapp-signup tr.date:hover td {
/* Highlight table rows on mouse over */
background-color: #f5f5f5;
}
.myapp-signup tr.dropdown th, td {
/* Provides some space inside within the boxes */
padding: 5px;
/* Grey */
border: 1px solid #D3D3D3;
}
.myapp-signup tr.dropdown:hover td {
/* Highlight table rows on mouse over */
background-color: #f5f5f5;
}
.myapp-signup tr.dropdown-other th, td {
/* Provides some space inside within the boxes */
padding: 5px;
/* Grey */
border: 1px solid #D3D3D3;
}
.myapp-signup tr.dropdown-other:hover td {
/* Highlight table rows on mouse over */
background-color: #f5f5f5;
}
.myapp-signup tr.multi-checkbox th, td {
/* Provides some space inside within the boxes */
padding: 5px;
/* Grey */
border: 1px solid #D3D3D3;
}
.myapp-signup tr.multi-checkbox:hover td {
/* Highlight table rows on mouse over */
background-color: #f5f5f5;
}
.myapp-signup tr.multi-dropdown th, td {
/* Provides some space inside within the boxes */
padding: 5px;
/* Grey */
border: 1px solid #D3D3D3;
}
.myapp-signup tr.multi-dropdown:hover td {
/* Highlight table rows on mouse over */
background-color: #f5f5f5;
}
.myapp-signup tr.multi-select-other th, td {
/* Provides some space inside within the boxes */
padding: 5px;
/* Grey */
border: 1px solid #D3D3D3;
}
.myapp-signup tr.multi-select-other:hover td {
/* Highlight table rows on mouse over */
background-color: #f5f5f5;
}
.myapp-signup tr.radio th, td {
/* Provides some space inside within the boxes */
padding: 5px;
/* Grey */
border: 1px solid #D3D3D3;
}
.myapp-signup tr.radio:hover td {
/* Highlight table rows on mouse over */
background-color: #f5f5f5;
}
.myapp-signup tr.select-other th, td {
/* Provides some space inside within the boxes */
padding: 5px;
/* Grey */
border: 1px solid #D3D3D3;
}
.myapp-signup tr.select-other:hover td {
/* Highlight table rows on mouse over */
background-color: #f5f5f5;
}
.myapp-signup tr.text-line th, td {
/* Provides some space inside within the boxes */
padding: 5px;
/* Grey */
border: 1px solid #D3D3D3;
}
.myapp-signup tr.text-line:hover td {
/* Highlight table rows on mouse over */
background-color: #f5f5f5;
}
.myapp-signup tr.text-area th, td {
/* Provides some space inside within the boxes */
padding: 5px;
/* Grey */
border: 1px solid #D3D3D3;
}
.myapp-signup tr.text-area:hover td {
/* Highlight table rows on mouse over */
background-color: #f5f5f5;
}
.myapp-signup tr.captcha th, td {
/* Provides some space inside within the boxes */
padding: 5px;
/* Grey */
border: 1px solid #D3D3D3;
}
.myapp-signup tr.captcha:hover td {
/* Highlight table rows on mouse over */
background-color: #f5f5f5;
}

.myapp-signup p.reqd-footer {
margin-top: 15px;
}

/* Note: this is the same color as the hover */
/* If the above hover color is changed you will have to add a hover background-color of: #f5f5f5 to the readonly elements */
.myapp-signup tr.readonly-element td, .myapp-signup tr.readonly-element input {
/* Light Grey */
background-color: #f5f5f5;
}

/* The Captha class is a read-only element? I have to undo the above tr.readonly-element changes */
.myapp-signup tr.captcha td, .myapp-signup tr.captcha input {
/* White */
background-color: white;
}

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?

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.