Multi-Select Checkbox Options recording true values in db

[railer]

I’ve run into a perplexing issue on a Joomla 3.8.8 site with Fabrik 3.8.1.

We have a series of multi-select checkbox questions which are displaying the word “true” in lieu of the actual checkbox label. I've confirmed that instead of the assigned values for each checkbox option, the word "true" is being stored in the db.

I could use some input or feedback regarding why this is happening and how I might fix it?

FYI — This is a long 3 page form comprised of… surprise… 3 tabbed sections.

The first section — is a Contact Info section which is prefilled by the user’s contact info submitted in a separate form which also registers them in Joomla.

The second section — has straightforward questions and answers.

The third section — which pertains to this issue — has questions, many of which have custom calc elements which turn the labels text from questions into statements text in the Detail View. It also has code in it which hides the questions which the user did not answer. In essence the calc element is calling a function stored in the /includes directory. The statements are just rewording, basically. In the third section, there are 9 groups, each of which has one of these custom calc elements.

When we view any record’s Detail View on the front-end, in the third tab (section), the multi-select checkbox options are displaying the value “true”.

When we view any record’s Detail View in the backend via Lists/mylist/Edit, the multi-select checkbox options labels do display under the element Label and then are followed by the various “true” values.

I’m hoping you can tell me where these “true” values are coming from and why they are being stored in the database instead of the checkbox option labels?

I've uploaded a couple of files which show you how the detail view displays in the frontend (without checkbox labels), and in the backend (with checkbox labels). Note how the "true" values in the backend display under the actual checkbox values. To me it looks like they are just flowing into the space under their parent element since we didn't code them to be there.

Hope this explanation makes sense.

Thanks!

 

[cheesegrits]

Without seeing your custom code, I have no idea.

I’m hoping you can tell me where these “true” values are coming from and why they are being stored in the database instead of the checkbox option labels?

We never store the labels in the database, only the values. When rendering the checkbox, we then match the value to the appropriate label, and display that as the checkbox text.

-- hugh

 

[railer]

Thanks for your reply Hugh. I misspoke, I meant "values" not "labels". So somewhere in the process, instead of the values we've provided for each checkbox option, the word "true" is being stored in the db upon form submission. I'm wondering if it could be somewhere in the component code that these "true" values are substituting themselves for the ones we assigned? I'm attaching a screenshot of the db table as an example — for what it's worth.

Here are some snippets of the code in a custom calc element's "More" tab. It may be incomplete but maybe this could help you to help us. The purpose of the calc element is to allow us to customize the display of the records Detail view. The client wanted to make it look like bulleted statements instead of the standard Questions and Answers format. So we created this method. They also wanted to hide any unanswered questions. This specific issue has to do with the checkbox elements only, which would list the main label and then the selected options labels below. So I've only included what I believe is code related to a single checkbox element which is having the problem as described.

Declarations at top of calc element code:

require_once JPATH_SITE . '/includes/bbt/bbt.php';
$gs1 ='';
$count = '0';
$gs1 .='<ul style="list-style-type: none;" class="list-striped">';
$link ='{fabrik_institutes_higher_education___ihe_gs_gs1_course_catalog_link_}';
$catalog = BlueBull::catalogLink($link);
$gs1 .= $catalog[0];
$count+=$catalog[1];

Call to the function for this single checkbox element:

$input ='{fabrik_institutes_higher_education___ihe_gs_gs1_coursesinclude}';
$courses = BlueBull::checkboxBhai($input, 'Courses include introduction to these professional guidelines and standards');
$gs1 .= $courses[0];
$count += $courses[1];
$proghigh += $courses[1];

Specific function in the bbt.php file included in the declarations above:

public static function checkboxBhai($field="", $lbl="")
{
$field = str_replace('[', '', $field);
$field = str_replace(']', '', $field);
$field = str_replace('&quot;', '', $field);
$charr = explode(',', $field);
$pg = '';
while (list($key, $value) = each($charr)) {
$pk = preg_replace('["]', '', $value);
$pk = stripslashes($pk);
if ($pk=='Not Required') {$t == FALSE;}
else {
if (!empty($pk)) { $t = TRUE; $pg .= '<li>'; $pg .= $pk; $pg .= '</li>'; }
elseif($pk!='No') {$t = FALSE;}
else {$t=FALSE;}
}
}
if ($t == TRUE) {
$retv = '<li><label>'.$lbl.':&nbsp;</label><br/><ul class="list-simple">';
$retv .= $pg;
$retv .='</ul></li>';
$count =1;
}
else {
$retv='';
$count='0';
}
return array($retv,$count);
}

 

[cheesegrits]

I've never seen that happen. We should save the value(s) for the selected checkbox(es).

Does it still happen if you disable your calc stuff and submit a form?

-- hugh

 

[railer]

I've never seen that happen. We should save the value(s) for the selected checkbox(es).

Does it still happen if you disable your calc stuff and submit a form?

-- hugh

Good question! I don't know. I'll wait for your comments on the above before testing to see if unpublishing the calc element has an affect.

 

[troester]

What are your checkbox element settings, do you have any "Advanced/eval populate" stuff ?Maybe setting the expected option label (displayed to the user) but a wrong option value (the value is the part which is stored in the DB)?

I've confirmed that instead of the assigned values for each checkbox option, the word "true" is being stored in the db.

If so, then the calc element is displaying what it gets.

BTW:
checkbox is storing a JSON string like ["s1","s2"], you can do a json_decode() to get the array and then a foreach to loop

 

[railer]

No Advanced/eval populate code. In this case, Default value and label is 0 (zero). (Conferring with my developer about the Json stuff.)

 

[troester]

Does it still happen if you disable your calc stuff and submit a form?

Does the checkbox element display correctly in new forms (with and without calc enabled)?

 

[railer]

Does the checkbox element display correctly in new forms (with and without calc enabled)?

Yes Troester, a new test form with checkbox elements does store the correct assigned values created as options in the element, in the database. Any idea what might be causing the behavior which adds "true" to the database?

 

[troester]

Do you have a link to the form?

 

[railer]

Unfortunately, I can't give you a link to the blank form because you would have to create a new registration account first after which you can login and access the form. This is a live site and all registrations will go to the client, unless I modify the Fabrik plugins. I can send you a link where you can edit a test profile. Hopefully that will work. Same form. I'll send it in a private "conversation".

 

[troester]

So you have "Save part-edited records" enabled in form processing settings?
Maybe this is related, can you try to disable it?
It seems to me it's adding one "true" checkbox for every originally checked option?

 

[cheesegrits]

I don't see anything immediately obvious in that calc code.

But I'm relatively certain there's something in your custom coding which is causing this. I've never seen this happen before.

The only way I could really move forward with this would be to do it as some billable work - probably about an hour, to get an Akeeba copy of the site from you, install it here, set up a PHP Storm project on it, and xdebug it.

-- hugh

 

[railer]

Thanks Hugh -- Need to discuss some of the suggestions in this thread with my developer. Troester made an interesting suggestion about the form being set to save partially-edited records. I'm going to create a couple of tests of that. One as is to see if that is what causes it — when a user doesn't complete the entire multipart form (there are 3 sections with a total of about 165 questions). You can see why we might want to be able to save what they've completed. Any idea of a possible workaround? I'll get back to you about the paid work shortly. Thanks

 

[railer]

Quick update: I tried several different test scenarios, e.g., stopping the form at different points midway, and logging out. Then back in and finishing it. But I wasn't able to replicate the issue. Contacting the user to see if they can shed more light on what they did.

 

[railer]

Hi Hugh and Troester,

We just had a form submission from a different form which has no custom programming and the checkbox elements in this form are also giving the “true” values, instead of the value configured in the element.

So I am hypothesizing that the problem may be a basic configuration error and not related to our custom programming in the other form.

Perhaps you can look over the following settings I have configured and let me know if anything is set incorrectly?

Details:

Label : Donation Types (check all which apply):
Name: donation_types
Plugin: checkbox
ID: 467
Group: Donation Types Group

Options: Value: Label:
Online Online
Mail In Mail In
In Person In Person
Group Group
GGID GGID
Other Other

Options per row: 1

Defaults: (Fields empty)

Front end select: (All set to “No)

Advanced: (All fields empty)

Access: Form (add), Form (edit), Details View, and List view all set to “Public”.
Engrypt Data: No
Save to Datebase: Yes
Default on Copy: No

——————

List View Settings:

Show in List: No
Link to details: No
Allow ordering: No
Heading Label: (empty)
Custom Link: (empty)
Link Target: Default
Custom link in details: Yes
Use as row class: No
Include in list query: Yes
Always render: No
Filters/Filter type: None
Exact match: Yes
Length: 20
Filter Access: Public
Full Word Match: No
Required: No
Filter data: Use global
Order by: Label
Include in advanced search: Yes
Filter class: input-medium
Class: Visible
———————

Validations:
Action: notempty
Status: Published
In: Frontend
On: Both
Validate hidden: No
Must Validate: Yes
Show validation icon: Yes
Error message: This is a required field.
———————————
No Javascript.

=================

When I view the when view the record in Edit mode, the programmed values display first in the element, followed by the "true" values underneath.

Could it be that some of our checkbox "values" text contain letterspaces in them, i.e., Mail In, In Person?

 

[cheesegrits]

As I said ...

The only way I could really move forward with this would be to do it as some billable work - probably about an hour, to get an Akeeba copy of the site from you, install it here, set up a PHP Storm project on it, and xdebug it.

If I do find that it's down to a bug in Fabrik, I'd split the time 50/50.

-- hugh

 

[railer]

Hi Hugh,

I was hoping to get your opinion on that last thing... the checkbox values with letterspaces in them? Could that be the cause of this strange behavior? Note that if I edit a record by viewing a List and then clicking the Edit button, both sets of values display, i.e., programmed values and "true" values. If I check the actual values and uncheck the "true" values, the problem is fixed.

As for an Akeeba backup that would not be possible. This site is one of two slaves sites running on the JMS Multisite extension/platform. In addition to there being two slaves and a master (in which Fabrik is installed), the sites also share users, so there is a third site in which the users are managed. Plus the structure of JMS requires the sites to be in a non-standard directory path. For instance, in cPanel, it would be /home/account/domains/domain.com/public_html.

 

[troester]

I think it's your Joomla template.

If I call the form (ihe-edit-profile) with your Joomla template and check a checkbox (e.g. DAP) some JS is changing the <input ...value="DAP"> to <input ...value="true">
With this new value the behaviour you see is to expect: this (wrong) value is stored in the DB, on display Fabrik doesn't find a label for this value, so adding a new (checked) option with value and label = "true"
If I append ?template=protostar to the form the input value is not touched, so I assume it would save correctly to the DB (I didn't try because it's a live site).

 

[cheesegrits]

If someone wants to give me the link to the site, I can take a look.

-- hugh