zen_output_string_protected calls on attribute values with inches character (")

[swguy]

On pages that use zen_output_string_protected() to display attribute values such as the admin orders page and the checkout confirmation page, values that contain the " sign are shown as "

One possible fix would be to do a replace in zen_output_string before calling htmlspecialchars in includes/functions/functions_general.php

  function zen_output_string($string, $translate = false, $protected = false) {
    if ($protected == true) {
      $string = str_replace(""", '"', $string);
      return htmlspecialchars($string, ENT_COMPAT, CHARSET, TRUE);
    } else {
    ...

Thoughts?

[lat9]

I've seen it too, as reported here: https://www.zen-cart.com/showthread....-inconsistency

I'm still not sure what the best solution is; hoping that DrByte will share his opinion!

[mc12345678]

Two years ago there was effort put in to align the two as can be seen here in github related to issue #270

I seem to recall somewhere either in code review or the discussion being told that a different path was being taken to resolve the issue of concern and that the changes would not be necessary. The admin side had been reworked to both align the protected functions and to eliminate a function that was being sought to be removed. From there expected to correct the issues here or there that are described above, but...

[swguy]

Perhaps we could start with the question: should this be fixed on the admin side where the data is entered, and captured as " or on the display side (both admin and catalog)? I have no strong feelings - open to proposals.

[swguy]

Easy repro strategy for anyone who wants to play along:

Using the demo dataset, modify option 13 to say '3.25 " disk'

admin/options_values_manager.php?action=update_option_value&value_id=13&value_page=7

then add a product 22 to your cart:
index.php?main_page=product_info&products_id=22

You will not see the issue on the shopping cart page, but you will see it on the checkout confirmation page, and if you complete the order, you'll see it in admin/orders/display that order.

[mc12345678]

Perhaps we could start with the question: should this be fixed on the admin side where the data is entered, and captured as " or on the display side (both admin and catalog)? I have no strong feelings - open to proposals.

From a "final" state perspective, I'd rather see both the catalog and admin sides use the same code as they are both accessing the same source and in general doing the same thing (displaying the data). A process was implemented to store the data in the database using sanitization and that sanitization was not dependent on the zen_output_string_protected function. It also was not necessarily developed with the zen_output_string_protected function results in mind. (making a little bit of a leap there as not privy to other core discussions.)

The issue I see though is that such a significant modification would also have an impact on other's code and compatibility. (those code counting on the existing function name would respond differently on one side or the other.) a possible solution to that is to either create two new functions or one that is shared between the two sides and make the modifications to support that function map. Something like that was done with the product information in ZC 1.5.5.

As to the affected characters, anything that is converted is at risk of being displayed as an html entity instead of looking like the desired text: <, >, &, and " all come to mind.

[royaldave]

From a "final" state perspective, I'd rather see both the catalog and admin sides use the same code as they are both accessing the same source and in general doing the same thing (displaying the data). A process was implemented to store the data in the database using sanitization and that sanitization was not dependent on the zen_output_string_protected function. It also was not necessarily developed with the zen_output_string_protected function results in mind. (making a little bit of a leap there as not privy to other core discussions.)

The issue I see though is that such a significant modification would also have an impact on other's code and compatibility. (those code counting on the existing function name would respond differently on one side or the other.) a possible solution to that is to either create two new functions or one that is shared between the two sides and make the modifications to support that function map. Something like that was done with the product information in ZC 1.5.5.

As to the affected characters, anything that is converted is at risk of being displayed as an html entity instead of looking like the desired text: <, >, &, and " all come to mind.

Apologies if there is another thread on this, but was this issue ever sorted?

My 156c installation is having issues with all 4 of these characters as described.

[mc12345678]

Apologies if there is another thread on this, but was this issue ever sorted?

My 156c installation is having issues with all 4 of these characters as described.

There is an open issue in github on this that is still up-for-grabs for solution: https://github.com/zencart/zencart/issues/2677

The issue centers around the use of zen_output_string_protected in the tpl_checkout_confirmation_default.php page which causes that change in display. When displaying the information on the shopping cart page, that function is not used and the code has been this way since at least 1.5.0...