https://github.com/zencart/zencart/pull/799 has now been merged, which should address this.Quote:
Originally Posted by stellarweb
Printable View
https://github.com/zencart/zencart/pull/799 has now been merged, which should address this.Quote:
Originally Posted by stellarweb
Fixed .Quote:
Originally Posted by torvista
Works perfectly!!
Quote:
Originally Posted by DrByte
Hi Guys,
Not sure if it a bug or if it's the way the category editor, product editor and page editor is meant to behave in the new version but I thought I'd mention it. The eror happen with the text in the files or when adding your own content with HTML tags and as plain text with paragraphs.
Better safe then sorry huh? :)
This is a straight out of the zip installation and setup, with no edits, no mods, and no addons installed.
------------------------------------------------------------------
Formatting of text via the Define Pages Editor function
------------------------------------------------------------------
EG: Open the Shipping file vis the Define Pages Editor function in tools ... the text looks like normal.
<p><strong>Shipping Information</strong></p>
<p>We haven't updated this page yet. Please use the Contact Us form to let us know!</p>
When it is saved
All the HTML tags are converted and display on the shipping page:
<p><strong>Shipping Information</strong></p> <p>We haven't updated this page yet. Please use the Contact Us form to let us know!</p>
The tags have been converted to:
<p><strong>Shipping Information</strong></p>
<p>We haven't updated this page yet. Please use the Contact Us form to let us know!</p>
And when it is formatted in plain text with paragraphs like:
Shipping Information
We haven't updated this page yet. Please use the Contact Us form to let us know!
The page text looks like one long paragraph:
Conditions of Use Sample Text We haven't updated this page yet. Please use the Contact Us form to let us know!
Please feel free to contact if you need further clarification. :)
Kind Regards
Les :)
This should be fixed now. https://github.com/zencart/zencart/pull/825Quote:
Originally Posted by stellarweb
Les this is exactly the same problem I'm having. I cannot get HTML text to display like HTML, even if I copy, say, define_checkout_success.php from my running 1.5.4 site, they just come up exactly as you say.Quote:
Originally Posted by webmanstudios
I'm running zen-cart on Windows Server 2012 R2, MySQL 5.6 and PHP 5.6.17. I've deleted the database several times and tried different creation options but ended up with my preferred option of UTF8_general_ci but this problem still perists.
Anyone got any idea about what is happening here?
Thanks, Andy
hard coded text
Quote:
if (IS_ADMIN_FLAG === true && (MODULE_PAYMENT_MONEYORDER_PAYTO == 'the Store Owner/Website Name' || MODULE_PAYMENT_MONEYORDER_PAYTO == '')) $this->title .= '<span class="alert"> (not configured - needs pay-to)</span>';
It's a bug. We're working on a fix for our over-zealous input cleaner-upper :)Quote:
Originally Posted by webmanstudios
The fix for it is still in-progress, but initial code is at: https://github.com/zencart/zencart/pull/828 (and has been merged, but also followed-up with a few other commits subsequently).
I'm encountering a lot of difficulties in getting OzPost shipping module to work in v155.
Obvious signs of failure is the repeatable effect of wiping out checkbox options if they are changed, leading to an inability of the module to provide shipping estimates - in fact the options don't appear at all in the shopping cart or at checkout.
Before Update showing checked boxes
Attachment 16043
After Update showing all checkboxes have been cleared
Attachment 16042
Note that the radio button which was changed from No to Yes shows yes after updating as expected
Examination of the Configuration table shows that the checkboxes are represented in OzPost records as arrays and are set using this function, stored in the set function field for that record e.g.:
In v154 the Ozpost code works just fine but in v155 since at least January 13 it has been failing.Code:zen_cfg_select_multioption(array(
'Skippy Post Air',
'Skippy Post Air Insured',
'Skippy Post Air with Tracking',
'Skippy Post Air with Tracking and Insurance',
'Skippy Post Air +Proof of postage',
'Skippy Post Air Insured +Proof of postage',
'Skippy Post Air with Tracking +Proof of postage',
'Skippy Post Air with Tracking and Insurance +Proof of postage' ),
Logs created by an OzPost configuration update event show lots of entries like this:
The first line of the PHP Warning suggests that the sanitiser is being troubled by an array that it wasn't expecting.Code:[16-Feb-2016 00:14:08 Australia/Sydney] PHP Warning: htmlspecialchars() expects parameter 1 to be string, array given in /zc_154/nimrod/includes/classes/AdminRequestSanitizer.php on line 314
[16-Feb-2016 00:14:08 Australia/Sydney] PHP Stack trace:
[16-Feb-2016 00:14:08 Australia/Sydney] PHP 1. {main}() /zc_1545/nimrod/modules.php:0
[16-Feb-2016 00:14:08 Australia/Sydney] PHP 2. require() /zc_1545/nimrod/modules.php:10
[16-Feb-2016 00:14:08 Australia/Sydney] PHP 3. require() /zc_1545/nimrod/includes/application_top.php:171
[16-Feb-2016 00:14:08 Australia/Sydney] PHP 4. require() /zc_1545/includes/autoload_func.php:48
[16-Feb-2016 00:14:08 Australia/Sydney] PHP 5. AdminRequestSanitizer->runSanitizers() /zc_154/nimrod/includes/init_includes/init_sanitize.php:226
[16-Feb-2016 00:14:08 Australia/Sydney] PHP 6. AdminRequestSanitizer->processBuiltIn() /zc_154/nimrod/includes/classes/AdminRequestSanitizer.php:75
[16-Feb-2016 00:14:08 Australia/Sydney] PHP 7. call_user_func:{/zc_1545/nimrod/includes/classes/AdminRequestSanitizer.php:90}() /zc_154/nimrod/includes/classes/AdminRequestSanitizer.php:90
[16-Feb-2016 00:14:08 Australia/Sydney] PHP 8. AdminRequestSanitizer->filterStrictSanitizeValues() /zc_154/nimrod/includes/classes/AdminRequestSanitizer.php:90
[16-Feb-2016 00:14:08 Australia/Sydney] PHP 9. htmlspecialchars() /zc_1545/nimrod/includes/classes/AdminRequestSanitizer.php:314
[16-Feb-2016 00:14:08 Australia/Sydney] Request URI: /nimrod/modules.php?set=shipping&module=ozpost&action=save, IP address: fe80::226:8ff:fede:e711
#1 htmlspecialchars() called at [/zc_154/nimrod/includes/classes/AdminRequestSanitizer.php:314]
#2 AdminRequestSanitizer->filterStrictSanitizeValues()
#3 call_user_func() called at [/zc_154/nimrod/includes/classes/AdminRequestSanitizer.php:90]
#4 AdminRequestSanitizer->processBuiltIn() called at [/zc_1545/nimrod/includes/classes/AdminRequestSanitizer.php:75]
#5 AdminRequestSanitizer->runSanitizers() called at [/zc_1545/nimrod/includes/init_includes/init_sanitize.php:226]
#6 require(/zc_154/nimrod/includes/init_includes/init_sanitize.php) called at [/zc_154/includes/autoload_func.php:48]
#7 require(/zc_154/includes/autoload_func.php) called at [/zc_1545/nimrod/includes/application_top.php:171]
#8 require(/zc_154/nimrod/includes/application_top.php) called at [/zc_154/nimrod/modules.php:10]
Have I found the smoking gun?
I should add that this warning was generated by the v155 beta that contains the #828 fix.
All tests have been conducted on vanilla copies of v154 with only sample data and OzPost added, then upgrading to v155
Testing environment: MAMP Pro, PHP Version: 5.6.10 (Zend: 2.6.0), MySQL 5.5.42
Notes to devs.Quote:
Originally Posted by lucidlee
I've not been able to replicate this fault. It doesn't to exist in the v155 that I tested with at the end of December.
I've not tried it with any of the later updates, partly because I've only recently been informed of the problem, partly because I've been pretty busy working on updates for another system, but mainly because this aspect of the ozpost code hasn't had any changes for several years now (other than adding new carrier/methods and removing the obsolete ones.).
I suspect that it is due to the input cleaner upper (expecting strings only, and failing when confronted with an array). The array data isn't unique to ozpost though, and I've asked the OP to see if the same issue exists with any of the other shipping modules (awaiting a reply)
The Skippy post example provided by the OP is just one of many similar code snippets used by the ozpost module and apparently all are effected.
The text/numeric inputs are (apparently) saving just fine. The OP has identified the problem to relating to the radio button multi select. The ozpost config options also include single select dropdown menus. I am awaiting feedback from the OP to see if these are also affected (I suspect that they won't be).
If it weren't for the Dr's comment about "it's a bug due to an overzealous input cleaner upper", even though it was in regards to a different issue " I'd be downloading the latest code to do my own debugging, but I can't help thinking that the two are related, so on that basis I'm inclined to just sit back for a wee bit longer and hoping it'll all be ok (again) when v155 is officially released. In fact it is due to this kind of unexpected issue that I've been holding the next ozpost update for... Just in case I do need to tweak/change something for compatibility.
My questions at the moment are, am I just being wishful that the problem is with zen rather than ozpost? Is the input cleaner upper bug likely to affect the multi select options, or do I need to investigate this further myself?
Cheers
RodG