So took a lap through the referenced files, and while there may be something associated with the plugin itself regarding capturing/providing data, it looks to me like sanitization of the manufacturers data wasn't fully captured as one might expect. Ie. If you take a look at admin/includes/init_includes/init_sanitize.php you will see that things such as products_description, products_name and products_url are each provided through a sanitizer applicable to that data type of data to be captured/sanitized. But there is nothing related to manufacturer entered "text". Now, add to that this plugin (applicable download location with associated thread is: https://www.zen-cart.com/downloads.php?do=file&id=1966) uses additional fields to store information in the database, these too need to be sanitized "properly" instead of blanketly which might be why you are seeing raw HTML (as the default sanitization will "disable" html) instead of the expected/desired information.
I provide below a partial "patch" to the sanitization issue, but two things should happen. One the ZC code should be updated in the area of admin/includes/init_includes/init_sanitize.php to capture the fields in the applicable/desired standard sanitizer, and two the plugin should be updated to capture the sanitization applicable to the fields that are added in the admin side. Then, there is somewhat what you referred to regarding the admin side display of the information so that it is not all HTML-ly. :) (Nice word no?)
For immediate "gratification":
add this and any additional directions within the file to address other applicable fields
admin/includes/extra_datafiles/manufacturers_all_about_sanitize.php
Code:
if (class_exists('AdminRequestSanitizer')) {
$sanitizer = AdminRequestSanitizer::getInstance();
$group = array(
// BOF items that should be incorporated/addressed in base ZC code at admin/includes/init_includes/init_sanitize.php
'manufacturers_name' => array(
'sanitizerType' => 'PRODUCT_NAME_DEEP_REGEX',
'method' => 'post',
'pages' => array('manufacturers')
),
'manufacturers_image_manual' => array(
'sanitizerType' => 'FILE_DIR_REGEX',
'method' => 'post',
'pages' => array('manufacturers')
),
'manufacturers_url' => array(
'sanitizerType' => 'PRODUCT_URL_REGEX',
'method' => 'post',
'pages' => array('manufacturers')
),
// EOF items that should be incorporated/addressed in base ZC code at admin/includes/init_includes/init_sanitize.php
// BOF items to remain in this file even after the above are addressed, because these support the plugins new admin entries.
'manufacturers_status' => array(
'sanitizerType' => 'SIMPLE_ALPHANUM_PLUS',
'method' => 'post',
'pages' => array('manufacturers')
),
'manufacturers_sort_order' => array(
'sanitizerType' => 'SIMPLE_ALPHANUM_PLUS',
'method' => 'post',
'pages' => array('manufacturers')
),
'manufacturers_about' => array(
'sanitizerType' => 'PRODUCT_DESC_REGEX',
'method' => 'post',
'pages' => array('manufacturers')
)
// EOF items to remain in this file even after the above are addressed, because these support the plugins new admin entries.
);
$sanitizer->addComplexSanitization($group);
}
Now, I included a check for the AdminSanitizer class, though really all versions of 1.5.x ZC should have this class installed or get it installed. It may require "manual" installation at this point for older systems, but it really should be present for any system out there as advised in the forum. So, for those that wish to be alerted that there is a problem, remove the "if (class_exists..." line and the final closing right curly parenthesis. Then if there is an issue that the class does not exist, there will be errors generated in the logs directory.
So, the other "issue" that I think was being referenced is the "recreation" of the information in a way similar to what is done with products_description.
So this code in the modified admin/manufacturers.php file:
Code:
for ($i=0, $n=sizeof($languages); $i<$n; $i++) {
$manufacturer_inputs_string_about .= '<br />' . zen_image(DIR_WS_CATALOG_LANGUAGES . $languages[$i]['directory'] . '/images/' . $languages[$i]['image'], $languages[$i]['name']) . ' ' . zen_draw_textarea_field('manufacturers_about[' . $languages[$i]['id'] . ']', 'soft', '70', '10', zen_get_manufacturer_about($mInfo->manufacturers_id, $languages[$i]['id']));
}
Likely would be better if:
Code:
for ($i=0, $n=sizeof($languages); $i<$n; $i++) {
$manufacturer_inputs_string_about .= '<br />' . zen_image(DIR_WS_CATALOG_LANGUAGES . $languages[$i]['directory'] . '/images/' . $languages[$i]['image'], $languages[$i]['name']) . ' ' . zen_draw_textarea_field('manufacturers_about[' . $languages[$i]['id'] . ']', 'soft', '70', '10', htmlspecialchars( (isset($manufacturers_about[$languages[$i]['id']]) ? stripslashes($manufacturers_about[$languages[$i]['id']]): zen_get_manufacturer_about($mInfo->manufacturers_id, $languages[$i]['id']), ENT_COMPAT, CHARSET, TRUE));
}
And something similar would need to be done for manufacturers_name and at least manufacturers_url.
These few things together should support display of the information both on the admin and the store/catalog side. As far as I have looked, I believe no further catalog side modifications are necessary to regain "readable" text. It's that the data getting to the database and used on the admin side is not properly handling the information. I could be wrong, but this really should be an issue brought up in the applicable thread and potentially incorporated into both the plugin as well as the ZC code where applicable.
Bookmarks