Bug: EWWW with WebP on Cloudflare with Buddypress

  • Resolved David

    (@fouriemc)


    8 years, 8 months ago

    Hi,

    Spent quite some time today trying to figure out why uploading a user profile photo (or particularly, cropping it) in Buddypress was not working. Turns out that when conversion to WebP is activated with Alternate WebP Rewriting (to make WebP rewriting work on Cloudflare), it breaks a script in the upload mechanism of Buddypress.

    Hope this can be addressed in a future version – I would like to start using WebP.

    Regards
    David

    https://www.ads-software.com/plugins/ewww-image-optimizer/

Viewing 8 replies - 1 through 8 (of 8 total)
  • Plugin Author nosilver4u

    (@nosilver4u)

    Please provide a link to a page where the buddypress script gets broken (it doesn’t need to be currently broken).

    Thread Starter David

    (@fouriemc)

    https://www.leeroberts.co.za/wp/members/davidtest/profile/change-avatar/

    Plugin Author nosilver4u

    (@nosilver4u)

    It says I need to login for that, so I registered, and it said I would get a confirmation email. It’s been about 30 minutes, and no email yet.
    Can you send me a login via https://ewww.io/contact-us/ please?

    Thread Starter David

    (@fouriemc)

    Don’t see a new user registration – have forwarded admin login.

    It seemed to break on
    do_action( 'bp_after_profile_avatar_upload_content' ); on line 92 of buddypress theme > members > single > profile > change-avatar.php

    Thanks
    David

    Plugin Author nosilver4u

    (@nosilver4u)

    Ok, thanks for the login, that got me exactly what I needed to see. It’s very similar to a recent issue we had with another photo uploading plugin: https://www.ads-software.com/support/topic/conflict-with-spcdm-plugin?replies=12

    Basically, the html specification states that the very first time the parser (usually a browser) sees a closing tag starting like ‘</’, it is supposed to recognize that as the end of the <script> element.

    The unfortunate fact is that no browsers actually follow that rule, which causes developers to think they are following the spec (when they aren’t). On the flip side, the PHP parser DOES follow that rule, and will insert a closing </script> tag when it isn’t needed.

    It isn’t something I can fix, but the buddypress devs should be able to fix it simply. They just need to escape the slashes in their ending tags when they are inside a <script> element.

    So instead of using </a> they would need to make that <\/a> and so on for each html element within the script elements.

    Thread Starter David

    (@fouriemc)

    Great, thank you. Will you report the issue on Buddypress, or should I?

    Do I presume correctly that using .htaccess will not cause the issue to re-appear? If so, I can live without Cloudflare once we go live.

    Thank you for the effort with this.

    Plugin Author nosilver4u

    (@nosilver4u)

    Go ahead and report it to the Buddypress folks, and reference this thread.

    And yes, the issue would not happen with the .htaccess solution, but make sure your webhost isn’t employing a proxy cache also, since that can have the same affect as Cloudflare.

    Thread Starter David

    (@fouriemc)

    Thanks, reported at https://buddypress.org/support/topic/buddypress-ewww-webp-cloudflare/ for anybody with a similar situation.

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘Bug: EWWW with WebP on Cloudflare with Buddypress’ is closed to new replies.