Developer forum

Hi Terri

In which context? Are we talking Ecommerce products?

Problem with + and & is that it is URL characters and using it in IDs will make it pretty difficult to also use the information in Querystrings etc. Which is why we have IDs.

We just made an update to what we support in Product IDs so it also works with (at least some) special characters.

BR Nicolai

Hi Nicolai,

The client uses the EcomProductCategoryFieldTranslation table. For items that the FieldTranslationFieldOptions value contains something like Level 1+ or Level 2+, the + gets replaced by a space. This causes what appears to be duplicates in the search options because 'Level 1' and 'Level 1 ' look the same in the frontend. They need to be able to retain at least +, -, and & in this field if possible.

This is a specific entry from this table for the FieldTranslationFieldID (Difficulty): <Option Name="Level 2+" Value="17" Default="False" />

Note the multiple entries for Level 1, Level 2, etc in this screenshot: http://screencast.com/t/sKUtcg5fc

So it is an indexing related question?

I need a bit more context - I still do not understand exactly where the issue is.

If it is index related you have to urlencode the value before adding it to the querystring in the facet search. That is implementation and not DW that does that. + is a space when in URLs so if you want it to be a seen as the + value, you need to use some encoding.

Hi Nicolai,

I'm not sure. Would it be index related if you see it in the backend on the product itself? Here is an example of what it looks like in the backend. Note that the '-' is retained but the '+' disappears. There are 2 Level 2 entries since the '+' is replaced by a space.

Hm, see no pluses or minuses in your screenshot.
I am totally confused...

If this is custom fields on a product that has + sign as part of the value and the products are searched using the index and facets, the problem is in implementation. Field need to be indexed non-analyzed (as that would remove the +) and the facet script should url encode the + sign so it will not be seen as a space in the URL. It has to look like this: %2B - i.e. "&Difficulty=Level%202%2B"

Hi Nicolai,

Allow me to cut in, as Terri showed me what the problem was. Here's a repro in 8.9.1

http://www.screencast.com/t/Y46PErrll

The feature request is for labels in multiselect for product categories to allow special characters. They are being set through data integration, but when the customer manually updates any option, we lose the special characters. The index will then index Level 1, Level 1+, Level 1++ as the same, hence the reference, but that's a consequence, not the problem.

Hope this makes sense.

Best Regards,

Nuno Aguiar

Hi Oleg,

Is there an update on when this will be fixed?

Thanks,
Terri

Hi Terri,

The fix is already available on DW8.9.1.7 and up.

BR, Oleg QA

Thanks Oleg. I didn't see the bug number in the list.

Hi Oleg,

Was this fix also included in the 8.8.1.x branch? If so, what release has the fix?

Hi Terri

8.9.1 only....

BR Nicolai

@Terri: are you thinking about downgrading the solution to 8.8 to work around the issue?

@Nicolai: we have a site that has products with a / in the ID like ABCD/12. Bad choice, in hindsight, but it has always worked until a recent upgrade to 8.9 where those products no longer generate a proper friendly URL. We're trying to find a way to solve this issue without downgrading and locking the customer on 8.8 forever. Any clever ideas?

Imar