XF 2.1 Custom thread fields display incorrectly

[Zig]

Hi everyone,

My team is having some issues with the Custom Thread Fields functionality in XF2.1. The problem is specific to the single and multiple choice drop down selection types as far as we can tell. At the moment, when creating a new thread or viewing an existing thread with these fields, XF fails to output the "Text" field for that choice. The custom field block looks like this in a newly created For Sale/Trade thread:

Type: thread_field_choice.cfd_type_sale
Currency: thread_field_choice.cfd_currency_usd
Price: 1
Shipping Destinations: thread_field_choice.cfd_destinations_any
Or Best Offer: thread_field_choice.cfd_best_offer_1

If it were displaying the values in the Text field for these choices, it should appear as:

Type: Sale 
Currency: USD 
Price: 1 
Shipping Destinations: Any 
Or Best Offer : Yes

Am I missing something, or is this a bug?

 

[sbj]

This means the phrases for those fields are missing. If you re-create the phrases, the problem is solved.

But of course if this stuff happens for every new custom thread field dropdown you create in the ACP, then something is wrong with your setup. Maybe an addon interfering or sth like that.

 

[sbj]

Alternatively rebuild master data first, maybe that solves it (because the phrases aren't missing).

yourwebsitename.com/install

will forward you for rebuilding master data (no worry, nothing gets deleted or changed).

 

[Zig]

I took a look and the phrases are present and properly set. I double checked and it seems they're automatically generated when you set the "Text" field on the edit page for custom thread fields. Rebuilding master data also had no effect.

I've gotta say I'm at a loss on this one. I've verified the database entries for the custom_fields column of the xf_thread table, the matching entries in the xf_thread_field_value table, and made sure that the choices have appropriate display text in the JSON array for field_choices in the xf_thread_field table.

We run a heavily customized forum with many addon. Most of these are custom addons I've ported from XF1 in preparation for migrating to XF2 later this month. I'm certain that none of our in-house addons extend the classes involved with CustomFields, but hadn't thought to check for interference from the third party addons we use until you mentioned it. Unfortunately, upon inspection I found no such class extensions.

If it provides any context, the data at play here was imported from [TH] Custom Fields via an import script I wrote myself. Following import, we needed to run xf-rebuild:threads to get the data into the xf_thread table. That said, the example in my original post was a newly created thread meant to check if we had a problem with my import script or if there was some other underlying issue.

The truly frustrating part is that newly created custom fields don't seem to have this problem despite there being no noticeable difference in the database entries.

 

[sbj]

The truly frustrating part is that newly created custom fields don't seem to have this problem despite there being no noticeable difference in the database entries.

So it does work actually.
It just doesn't/didn't work for your older fields which you imported from TH Custom Fields, is this correct? So specifically for those fields only.

Again, it is not an issue of the field itself (and its values), as they are present (as you also checked the database). The problem lies within the phrases. It somehow doesn't register that it has phrases for those custom thread field values. So on frontend it displays the field value id.

I am not a developer myself, but I dealt a lot with custom thread fields. And I had the same issue like you did in the past.
In your custom script, are you also porting the phrases? Funny enough what I found out was that if the phrases have somehow a blank space character like at the end or something, then the phrase and the value name doesn't match.

Can you run this query and see if this works for you (for the value "Sale")? But try it on your local environment if possible.

INSERT INTO `xf_phrase`(`language_id`, `title`, `phrase_text`) VALUES (0, 'thread_field_choice.cfd_type', 'Sale');

Also maybe rebuilding the caches will help.

 

[Zig]

I think you hit the nail on the head about the possible trailing space (or similar). I was able to get things working by deleting the existing phrases, going through each field_choice and slightly altering the display text, saving the altered text to force the phrases to be regenerated, and then changing them back to the proper display text.

There must be a better way of doing this, but since we don't have very many custom fields it wasn't too terrible. Perhaps there's a way to rebuild the phrases for custom fields from the data in xf_thread_field table? I didn't see an option for this in the ACP, but I expect it would be possible to add one.

Thanks for pointing me toward the phrases. I'd been operating under the assumption that the display text was fetched from the xf_thread_field table and would not have thought to investigate the phrases without your advice! I'm a bit puzzled as to why the data is duplicated like this, since it leads to a discrepancy between the values shown on the custom field edit page and the values shown in actual threads, but I'm just happy to have it working!

 

[sbj]

No problem.

There must be a better way of doing this, but since we don't have very many custom fields it wasn't too terrible.

The alternative would have been to create the phrases via SQL command (like the example above) but your way is also a neat way.
I had to deal with the same problem for thousands of values, which is why altering the phrase names 1 by 1 would have been tiresome, so I used sql instead.
And I think rebuilding the master data triggers rebuilding all phrases of XF (but not sure).

Yeah, the trailing space issue cost me hours back then... When I finally figured it out, I was laughing and crying .

Good, that you got it sorted out now.