Problem with dropdown display in list after Delta upgrade

[johnonorvic]

I have just done an upgrade to J4.3.3/F4Delta from J4.2.9/F4Gamma3. Although most things work as expected, I have one problem. In each of two lists, a dropdown element now displays its value instead of its text. The elements display correctly in the associated forms. In each case the list data is created by Eval populate code. As Delta has been out for a while, it seems likely someone would have noticed a problem, but am I the first?

 

[troester]

What is you Eval populate code?

 

[johnonorvic]

How much of it do you need?

All the code is in a common file. In each Eval populate there is just a function call. Each function calls a common function that fetches the required data from the database (and does so for a lot of other elements). That has all been working for some time. The expected text is shown by the elements in the forms, so I think the Eval populates must be working. It is just in the lists that the elements show value instead of text; before I did the update the lists showed text. Is there something that controls whether a list shows value (_raw) or text?

 

[johnonorvic]

I have been doing some more investigation. Although I am sure this was working before the Delta upgrade, I have no hard evidence. While I could install my backup, that would take a while and this feature was working back under Fabrik3. I still have that version and it works (after downgrading its copy of PHP). In that, dropdowns display correctly in lists and, using JDump, I see a call to the Eval populate function when refreshing the list and the list shows text data. With the current Delta version I see (using enqueueMessage) that the form Eval populate function does run when the list is refreshed, but the list shows value data.

 

[johnonorvic]

After sorting out various other problems, I have now found time for another look at this. I spent some time working my way through Fabrik code, finding an anomaly where getLabelForValue() is called from addLabels(); it failed to find the value supplied and returned instead (as a failure default) the value itself rather than the related text. This was because the list values were integers, whereas the value supplied was a string. getLabelForValue() made the comparison using an array_search call, supplying true as the $strict parameter. When I checked in addLabels(), the value it supplied in the call to getLabelForValue() was an integer; how it arrived as a string, I have no idea. As a test, I modified getLabelForValue() to convert the value back to an integer. This allowed getLabelForValue() to return the required text, but caused problems elsewhere.

I then made some comparisons with the J3/F3 system from which the J4/F4 system had been converted. (Incidentally, I found that there is now a version of JDump that works with J4, which was helpful.) The only changes that had been made to my code were those required for the upgrade. I found that the function I had written to generate options lists from database tables, created an array where the value column was an integer in the F4/J4 system, but a string in J3/F3. Most of the code was identical; the one difference was that the statement that generated each option had been changed from:

$sm_options[] = JHTML::_('select.option', $sm_row->ID, $sm_row->$sm_fieldName);​

to:

$sm_options[] = JHtmlSelect:: option($sm_row->ID, $sm_row->$sm_fieldName);​

This change was required as the original caused an error and I think it was made by guesswork; the Joomla website is almost devoid of any mention of this feature for J4 - I certainly cannot find any. I had found documentation for the API17 version of the JhtmlSelect:: option (it states that the $value parameter is of type string), but none for J4. Searching Fabrik files, I found, in F4:

a function option() in class Select in namespace Joomla\CMS\HTML\Helpers in libraries/src/HTML/Helpers/Select.php, which includes the comment:

“* @ param string $value The value of the option”.​

and, in F3:

a function option() in class JHtmlSelect in libraries/cms/html/select.php, which also includes the comment:

“* @ param string $value The value of the option”.​

These seem to be the functions called. The code in the two versions appears to be similar if not identical. It seems that, in J3, it converts the parameter to string if it is supplied as an int, whereas, in J4, it uses whatever is supplied unchanged. I do not know what causes the difference in behaviour - may be the different PHP versions or may be not.

I changed my line of code above to:

$sm_options[] = JHtmlSelect:: option(strval($sm_row->ID), $sm_row->$sm_fieldName);​

which solved the problem and has not so far caused any other problem.

At this point, I wondered where I got my original code from. I found it obviously came from the Wiki Dropdown element which includes very similar code under Sample Eval Populate. This has a note with it “NOTE: Fabrik assumes the select IDs to be strings. Notice the first select option has the zero in quotes. Failing to do this will break the proper display of the value in a list view.” which I must have missed. The sample code actually produces an options list with integer IDs (apart from 'Please select'), but that works anyway in Fabrik 3. Might it be worth modifying the Wiki to include a revised version for Fabrik 4?

$options[] = JHtmlSelect::option('0', 'Please select' );
$db = FabrikWorker::getDbo();
$db->setQuery("SELECT id, text FROM #__tablename");
$rows = $db -> loadObjectList();
foreach ($rows as $row) {
    $options[] = JHtmlSelect::option(strval($row->id), $row->text);
}
return $options;

Oh well; at least I now know a bit more about how Fabrik works!