Tag field display wrong format in ajax mode and not respecting local mode attribute in search

[rogercreagh]

Steps to reproduce the issue

This concerns display and ordering of tags in a tag form field select box in both ajax and nested modes. There are also separate, but related issues around the way search by typing in the box is working .

Create a number of tags including some in a hierarchical relationship

Display two fields of type tag in a form. Set one with the attribute mode="ajax" and the other with mode="nested"

compare the select display between the two fields when selecting and searching

Expected result

In ajax mode

• the tags should not display their hierarchy tree (or it should be an optional attribute to have it displayed),
• they should be ordered in an obvious way (currently it is very opaque, and with paths displayed it is confusing). This could be an additional option to chose between alphabetical by title, alphabetical by path, hierarchical (using lft value), or most used (by counting instances in #__contentitem_tag_map)

In nested mode

• tags should always be shown in a hierarchy
• searching could include the path - at present it doesn't because (aside from the bug below) the path isn't displayed
• the layout of the hierarchy could be improved by using corner and dash symbols instead of just hyphens
• when hierarchy is displayed (always in nested mode) tags should be presented in path order (they are, except for the following bug)
• nested display should always be nested (whether or not full path is shown for each tag) - currently if com_tags option tag_field_ajax_mode is on (ie set to ajax) then the mode=nested on the field xml is ignored for the purposes of loading a limited number (30) of tags and they are displayed in the same (odd) order as in ajax mode

Actual result

In ajax mode the hierarchy path is listed with the tag and included in the search, and also the display order is seemingly undefined - although hierarchy is displayed this is not used to order the display, nor is it alphabetical by title or path. When searching the path is included in the search - in ajax mode the user is probably focusing on the individual tag title wanted, so both the display of path and including it in the search is spurious.

nested mode is working correctly (apart from the bug in #43705 ) if you include the undoccumented attribute remote-search="false" in the field definition OR if you change the com_tags option tag_field_ajax_mode to off in which case ALL tag fields will default to nested - which may not be expected. Even if remote-search attribute was documented it seems silly to have to include two attributes (mode=nested and remote-search=false) to get the expected default nested behaviour. There may be a use case for enabling remote-search when in nested mode, but this would seem unusual and should not be the default behaviour.

System information (as much as possible/relevant)

Joomla 5.1.2 vanilla, php8.2, apache2.4.61, Ubuntu 22.04

Additional comments

Screen shots illustrating the problem: (padding has been reduced by overriding css in all these to show more choices on screen and the tag field has been hacked to reduce the remote-search $prefillLimit to 5 to show the effect on nested displays of not loading the full set of tags. Also the padding chars in nested mode have been improved)

1. nested mode, nothing selected Note that because the com_tabs option is set to default to ajax mode the remote-search is in play and the display is only showing ten tags and the order is screwed up (eg Grandchild1-1-1 is actually a child of Parent1-Child1-1) Because remote-search is in play the com_tags option minimum search chars is used which defaults to 3 and is less useful in proper nested mode which defaults to searching immediately the first char is entered (because it has the whle list to search on)

2. ajax mode; nothing selected Note hierarchy path is prefixed to titles - should be an option defaulting to no path (IMO) Note also the strange order - not alphabetical by title or path, not in heirarchy order - although better than in the incorrect nested mode above.

3.Nested mode with remote-search set to false Now we have a sensible layout, although the order could be improved by putting the top level tags in alphabetical order but you can achieve that by manually changing the order in the com_tags list. Also if you search it is only searching the tag name which means you immediately loose sight of the hierarchy once you start to type and you can no longer see what the parent of the search result tags is. Also note that when a tag is selected it appears in the main box with the hyphen prefix indicating level rather than the path name (as is displayed with the ajax mode)

In some cases it would make more sense to display the path with the nested mode and the title only in ajax mode - and vice versa in other cases. The solution to this is to have a new attribute for the tag field with 3 options - display path with tag, display level indicator with tag, display tag title only. This would apply to both nested and ajax modes.

[rogercreagh]

Steps to solve these problems:

1. in libraries\src\Form\Field\TagField.php in function isRemoteSearch() after the end of the first condition at about line 333 insert line if ((isset($this->element['mode']) && (string) $this->element['mode'] === 'nested')) return false; before the final return statement.

This will make ajax search mode (called remote-search for some reason) respect mode="nested" and is obviously a simple test that was missed in the original coding.

[rogercreagh]

Steps to an improvement: For the Tag Field form field type provide two new attributes:

1. item-display with three possible values : title, path+title, levels+title

   • level+title is only appropriate for nested mode and is the default for nested mode for backward compatibility
   • path+title is available for both modes and is the default for ajax mode for backward compatibility
   • title only is available for both modes as currently search would only operate on the displayed text

2. item-sort with three possible values: title, path, order

   • title sorts alphabetically by title irrespective of whether path is displayed. This is a stupid option if display is by level in a nested display as it will hide the parent-child relationships. If item-display is 'levels+title' then this should fallback to path
   • path sorts alphabetically by path. This will work for a hierarchical display but the order of items at each sub-level may be different.
   • order sorts by the ordering of items using the lft column of the tree, this is what is currently used for nested mode

The changes to implement this would all be within libraries\src\Form\Field\TagField.php in setting up the $option->text and in building the ordering clause for the query.

[rogercreagh]

The hierarchical display used by nested mode could be improved by using unicode em-space and box-corner and horitzontal chars.

in libraries\src\Form\Field\TagField.php in function prepareOptionsNested() replace the line $option->text = str_repeat('- ', $repeat) . $option->text; with

              $prefix = ($repeat>0) ? str_repeat("\u{2003}",$repeat)."\u{2514}\u{2500} " : '';             
               $option->text = $prefix.$option->text;

Also change the Choices.css to reduce the padding between lines by adding a style override in the layout file layouts/joomla/form/field/tag.php as the penultimate lines just above <joomla-field-fancy-select

<style  type="text/css" media="screen">
  .choices__item { padding: 3px 10px !important;}
</style>

Unless you can think of a better place to put it in /media/system/css/ and then have to load that file in the layout file

these providing a better appearance for nested lists thus:

rather than this: where the layout is not clear and there is far too much padding between the lines (20px)

[rdeutz]

@rogercreagh would you be able to make a PR to fix the issues you listed here?

[rogercreagh]

@rogercreagh would you be able to make a PR to fix the issues you listed here?

I'll try, but I've never successfully made a pull request before - I've tried but it always seems to go wrong. I find the system very confusing. Might take a while to try and work out how it is supposed to work.

[fgsw]

Might take a while to try and work out how it is supposed to work.

@rogercreagh Using the Github UI to Make Pull Requests