While I would say that less than a day's time doesn't jive with the below:
I did come across two different "quick fixes" (not sure of the overall impact, but seems to address this issue for the store until a proper solution is developed). Ie. This really is a patch or a hack.
One was to use the admin sanitizer for alt_url to go through the PRODUCT_DESC_REGEX. Reason considered was that a product description may have a url in it and likely be handled "properly" and because sending it through PRODUCT_URL_REGEX didn't improve the situation.
New file:
admin/includes/extra_datafiles/ez_pages_url_sanitize.php
Code:
$sanitizer = AdminRequestSanitizer::getInstance();
$group = array(
'alt_url' => array(
'sanitizerType' => 'PRODUCT_DESC_REGEX',
'method' => 'post',
'pages' => array('ezpages')
)
);
$sanitizer->addComplexSanitization($group);
The other was in includes/function/functions_ezpages.php after $ez_pages_alturl was assigned to use:
Code:
$ez_pages_alturl = strsub('&', '&', $ez_pages_alturl);
It doesn't fix zen_href_link by any means, but it provides to that function a url that doesn't already have the ampersand 'sanitized'.
Btw, either of the above fixed the "immediate" issue, but doesn't require both. There may be other sanitizer types that would work, but those were the ones that seemed logical to attempt. I think I tried one other like WORDS_AND_SYMBOLS_REGEX, or maybe just thought about it.
Bookmarks