Forum Replies Created

Viewing 6 replies - 1 through 6 (of 6 total)
  • This plugin’s version assumes that woocommerce plugin is active and is calling is_product_category() function which is woocommerce specific. Sites with woocommerce are not affected, all others should downgrade to 1.1.32 and disable autoupdate for this plugin (if enabled). I hope that this will be considered a bug and fixed sooner than later.

    Yes, there is a problem, because plugin config page asks for roles for which sanitization will be skipped (“Do not sanitize for these roles”), an in the plugin code relevant variable named sanitize_on_upload_roles is treated opposite. I’ve solved this issue for myself by changing plugin code in functions/attachment.php file from:

    if ( !empty($bodhi_svgs_options['sanitize_svg']) && $bodhi_svgs_options['sanitize_svg'] === 'on' && $bodhi_svgs_options['sanitize_on_upload_roles'][0] != "none" ) {

    to

    if ( !empty($bodhi_svgs_options['sanitize_svg']) && $bodhi_svgs_options['sanitize_svg'] === 'on') {

    and from

    if( empty($should_sanitize_svg) ) {

    to

    if( !empty($should_sanitize_svg) ) {

    and this works for me. Sanitization is skipped only for selected roles, and if exception field is empty then sanitization is enabled for everyone. Thus, it wont work correctly for a wordpress role named “none” (if one is created and used) because for an empty exception list, this plugin in another part of its code adds bogus “none” element to the variable which holds sanitization exception roles.

    Thread Starter krzyko

    (@krzyko)

    Hi,

    only 6g -> page is blocked
    only 5g -> page is blocked
    both 5g and 6g -> page is blocked

    I also was thinking that custom rules are the only way to solve the problem.
    The culprit it the “Request” part in the uri, am I correct?

    Regards,
    Krzysztof Kosz.

    Thread Starter krzyko

    (@krzyko)

    Oh, my fault. I’ve checked it thoroughly and now also I’m sure that this space is there for a reason 🙂

    Thread Starter krzyko

    (@krzyko)

    Many thanks. And one more thing. Extra space after added attribute probably can be omitted to make this part of html code beautiful 🙂
    $tag = preg_replace( '/(<[a-zA-Z]*)\s/', '$1 class="' . trim( $target_class ) . '"', $tag );

    Thread Starter krzyko

    (@krzyko)

    Corrected version should have < added in the replace pattern if it was omitted in search regexp:
    $tag = preg_replace( '/<([a-zA-Z]*)\s/', '<$1 class="' . trim( $target_class ) . '" ', $tag );
    This works fine, no side-effects noted.

    But instead, if background image is restricted only to “article|aside|body|div|footer|header|p|section|table” so maybe correct version should look like this (notice img added at the end of the list):
    $tag = preg_replace( '/(<(?:article|aside|body|div|footer|header|p|section|table|img))\s/', '$1 class="' . trim( $target_class ) . '" ', $tag );

    And then, tag list might be even configurable as a plugin option.

Viewing 6 replies - 1 through 6 (of 6 total)