Fixed No control over the trailing comma

[sbj]

Affected version

2.1

For multiple-choice drop down custom fields, the system enters a comma after each value for the output display.



This is expected I guess.

Now when we use the value display html as allowed like this to have the output display as a list



then we get this:



So there is a trailing comma. The html break is applied after the value but before the comma. I believe this is a bug.

If the system enters a comma, it should treat it as a part of the value, so the used html is applied to it. Right now we have no control over the trailing comma.

If this is as "designed", can we get an instruction on how to manipulate this behaviour to our liking, please? Thanks.

 

[frm]

This also applies to checkbox fields as well, and, it's quite annoying. I didn't think this would be a bug report and have been asking about this in the Q&A support forum.

It seems more logical now that it's a bug if not apart of the value itself, as you put.

Either way, I would like it removed.

Another option could be it phrased with something other than comma_separator and added to the $value so that we can stylize the fields much more with display value HTML (remove ourselves by phrasing out the new comma_separator or leave it there and have the comma follow $value where it's directly after Singer but doesn't trail Doctor in your example).

 

[Chris D]

We have no immediate plans to make changes here. It is difficult to do so because of how we apply the comma which is actually done after the value is formatted for display. In other words you add a line break after each value, and then we add a comma after each one when we turn all of the values into a single printable string.

There may be an approach around this but it would require larger changes than we'd be comfortable with at this stage.

We'll mark this as "Future fix" for now and we will attempt to make changes for 2.2 if we find the time to.

 

[sbj]

Thanks for confirming it. This problem not only affects custom thread fields, it affects every addon which uses the XF fields system. So, nothing we can do about it then yet.

 

[Joe Link]

We have no immediate plans to make changes here. It is difficult to do so because of how we apply the comma which is actually done after the value is formatted for display. In other words you add a line break after each value, and then we add a comma after each one when we turn all of the values into a single printable string.

There may be an approach around this but it would require larger changes than we'd be comfortable with at this stage.

We'll mark this as "Future fix" for now and we will attempt to make changes for 2.2 if we find the time to.

Do you know of any sort of workaround we could do to get past this, maybe with CSS or something?

 

[Kevin]

Do you know of any sort of workaround we could do to get past this, maybe with CSS or something?

For the example given above, just reverse the value & BR.... <br />{$value}

 

[Joe Link]

That's better! Any way to hide the comma?

 

[frm]

Do you know of any sort of workaround we could do to get past this, maybe with CSS or something?

Only if you edit the core file and change comma separator in implode() to " ". Then, you can have CSS to make two columns or lists.

However, for shorter lists such as "Red, green, blue", you might want the comma and then this would be impossible without extra code to check what type of list you want to create.

It would require custom development (which I'm still seeking) to check if any key values contain <i> HTML in order to make the separator " " (a space) so that FontAwesome lists can be two-column and if there's no <i>, then revert back to the comma separator being a comma. This will throw an error in a file health check if you edit the core file without extending it though.

File: src/XF/CustomField/Definition.php
Find:

        if (is_array($value))
        {
            $value = implode(\XF::language()->comma_separator, $value);
        }

To:

        if (is_array($value))
        {
            $value = implode(" ", $value);
        }

Then in the display value HTML of any field of any add on you can add some div's and then CSS in your LESS. That will stack them in two columns, or however you want to design them.

Problem is 1) health check (but you know you edited it) and 2) if you want a short list like:
Favorite Colors: Red, Green, Blue
It will display as:
Favorite Colors: Red, Green Blue, <- a trailing comma after the last selection
with editing the display HTML to have a comma.
Or without the display HTML
Favorite Colors: Red Green Blue <- then it's confusing to somewhat understand without some type of separation

There should be an option to make checkboxes, multi-select lists display in unordered, ordered, or just regular lists in columns (1, 2 or 3) for a better design than something like:
Favorite Colors: Red, Green, Blue, Brown, Purple, Pink, Yellow, Magenta, Black, White, Gold, Silver
As after a while, it gets unreadable on mobile and should display more like (poor and quick mockup):

Favorite Colors:	Red Green Blue Brown Purple Pink Yellow Magenta Black White Gold Silver

 

[Joe Link]

Wow, thank you!

 

[sbj]

For the example given above, just reverse the value & BR.... <br />{$value}

View attachment 220712

That gives an empty space for the first line though.

 

[Joe Link]

That gives an empty space for the first line though.

You can use CSS to hide the first <br />

 

[frm]

That gives an empty space for the first line though.

The only way about it is with custom development or hope that 2.1.9 has the future fix for a better user experience.

Hopefully, this doesn't come in 2.2.1+ as something as simple as extending this shouldn't cost $50+. That's ridiculous and minor tweaks like this to deliver a better UX are required for larger sites to display better on mobile. Each minor tweak that seemingly looks easy to implement costs us more and more to maintain with XF upgrades, nickel and diming small forums to be thousands of dollars.

So, I hope this is a future fix, like, sooner than later.

For now, I'm probably just going to edit the core file and ignore the error because this looks horrible (imagine a few more in there and nobody is going to be able to focus on which is what)


But a comma for a shorter list is fine:


So for me, it's editing core now cause $50+ to put that into 2 column is much easier to focus and easier on the eyes to read and follow:

 

[Mike]

Worth mentioning that we have changed the output format for choice-based custom fields in 2.2. The output is now an HTML list which uses CSS for comma delimiting, so it looks no different by default. However, you can now target specific fields using custom CSS to change their output (treat each as a block element, bullet separation, etc)

 

[frm]

Worth mentioning that we have changed the output format for choice-based custom fields in 2.2. The output is now an HTML list which uses CSS for comma delimiting, so it looks no different by default. However, you can now target specific fields using custom CSS to change their output (treat each as a block element, bullet separation, etc)

I don't quite think this is fixed, otherwise it would be per line with the HTML chosen without a comma, unless I'm missing something here and it requires more code to rid it of the comma.

1.


2.


3.

 

[Chris D]

Rather than adjusting the HTML you'd mostly leave the HTML as it is, and instead change the CSS.

.listInline--customField
{
   > li
   {
      display: list-item;
   }

   > li:after
   {
      content: "" !important;
   }
}

 

[frm]

Spoke too soon. I believe I understand it now, I just need to tweak the CSS/HTML to get two columns (too late to play with it). But, this is awesome... thank you!!

// Create Two Columns
.itemBody-fields.itemBody-fields--after dd
{
    display: flex;
    flex-wrap: wrap;
    .dual-column
    {
    flex: 1 1 50%;
    padding: 2px 5px;
    }
}