View values in TV listbox-multiple then it manually entered

[Alexij2]

What does it do?

• Displays values manually entered by the manager in the admin panel. For MODX 2.x

Why is it needed?

• It is necessary to fix the display problem. User-entered data in a TV with a Listbox (Multi-Select) type is not displayed in the resource form #15136 (it for MODX 3.x, but for 2.x acutally too)

How to test

• Created TV listbox-multiple add to template
• Open resource and type in this TV manually some words. -> press Enter -> Save Document.
• Reload page (F5), Open TV and see changes.
  Describe how to test the changes you made.

Related issue(s)/PR(s)

#15136

[Jako]

Thanks for helping to make MODX better. This fix should check, wether the TV option forceSelection is deactivated and not add the unsupported values then. Otherwise the patch looks ok.

What happens if an unsupported value is in the TV and the TV is saved?

[smg6511]

I just put up a PR to fix this in 3.x. Take a look (see #16242), as it may inform how you approach this. I believe the un-patched file is virtually the same for 2.x and 3.x, so you may be able to use what I've done if you like. The one thing I see (that would need fixing) is that you probably end up duplicating selected values in the list when they are among the pre-defined input options values.

[Alexij2]

What happens if an unsupported value is in the TV and the TV is saved?

It is stored normally. It is not duplicated in the Database. Also, there is no duplication of the value, JS does not allow this to be done in the admin panel. And even if it is possible to write the value, then after saving and when updating the page (F5), the data is displayed correctly.

The one thing I see (that would need fixing) is that you probably end up duplicating selected values in the list when they are among the pre-defined input options values.

Duplication of the value does not occur. Js does not allow this to be done in the admin panel. I also thought that it would be duplicated, but as practice has shown, this does not happen, because unique values come to be recorded in the field DB.

[smg6511]

Small change to treat the custom input values the same as the pre-defined ones (htmlspecialchars). Also, I encourage the modernization of any passage of code you add or edit (here, use the short array declaration using only brackets).

Suggested change

	$orderedItems[] = array(
	'text' => $val,
	'value' => $val,
	'selected' => 1,
	);
	$val = htmlspecialchars($val, ENT_COMPAT, 'UTF-8');
	$orderedItems[] = [
	'text' => $val,
	'value' => $val,
	'selected' => 1
	];

[smg6511]

I tested this solution and it does fix the issue. The solution I created for 3.x could also just be dropped in, as the class definitions are exactly the same (comparing the original 3.x one before my merged changes and the 2.x one being changed here). Honestly, it's been too long for me to fully remember the motive for my 3.x approach although I do remember finding the original code somewhat hard to follow and wanted to make the process more immediately readable.

My first choice would be to drop in the 3.x solution, but I'd also approve this one with the more minor change I specified above.