• Hi there,

    we found a reproducible JavaScript corruption issue with BerqWP 4.1.13 on a WordPress website proxied through Cloudflare.

    Environment:

    • BerqWP 4.1.13
    • WordPress 7.1
    • Divi 5.11.1
    • PHP 8.3
    • Cloudflare proxy enabled
    • Varnish and Redis object caching enabled

    Cloudflare injects the following valid loader inside an inline JavaScript string:

    a.src=’/cdn-cgi/challenge-platform/scripts/jsd/main.js’;

    After the page is processed by BerqWP, it becomes similar to:

    a. data-berqwpsrc=”https://example.com/cdn-cgi/challenge-platform/scripts/jsd/main.js”
    src=”data:image/gif;placeholder=…”;

    The resulting JavaScript is syntactically invalid and causes:

    Uncaught SyntaxError: Unexpected identifier ‘https’

    We reproduced the issue even after:

    1. Adding /cdn-cgi/challenge-platform/ to the JavaScript exclusions.
    2. Adding the same path to the CDN exclusions.
    3. Disabling “Defer Excluded JavaScript”.
    4. Disabling the BerqWP CDN.

    The error disappears when the affected pages are excluded completely from BerqWP page optimization and caching. The Cloudflare loader then remains valid and the browser reports no JavaScript errors.

    Could you please confirm:

    1. Whether this is a known issue in BerqWP 4.1.13.
    2. Whether a newer version contains a fix.
    3. How to prevent the HTML/lazy-loading optimizer from modifying JavaScript code contained inside inline script strings.
    4. Whether there is a filter or supported exclusion that can disable this transformation without disabling full-page optimization.

    For privacy reasons, we cannot provide the production domain publicly. We can provide additional sanitized HTML excerpts or reproduce the issue in a temporary protected staging environment if strictly necessary.

    Best,
    Paolo

Viewing 6 replies - 1 through 6 (of 6 total)
  • Thread Starter paolurso

    (@paolurso)

    Hi there,
    we completed additional debugging and confirmed that the issue occurs during BerqWP’s cached HTML optimization.

    Cloudflare normally injects this JavaScript assignment:

    a.src='/cdn-cgi/challenge-platform/scripts/jsd/main.js';

    In the BerqWP-optimized HTML, it was transformed into malformed JavaScript similar to:

    a. data-berqwpsrc="https://example.com/cdn-cgi/challenge-platform/scripts/jsd/main.js" src="data:image/…";

    This caused incomplete or incorrectly rendered content for anonymous visitors receiving the optimized cache, while logged-in or uncached visitors were not affected.

    As a temporary workaround, we added a late berqwp_cache_buffer filter that restores only this exact Cloudflare JavaScript Detection loader assignment. The filter is narrowly scoped, idempotent and does not modify ordinary lazy-loaded images, videos, iframes or unrelated scripts.

    After applying the workaround, we re-enabled BerqWP site-wide and verified:

    • cached pages return x-berqwp-cache: HIT;
    • the malformed assignment is no longer present;
    • the valid Cloudflare loader remains present;
    • anonymous cached pages render correctly;
    • no new PHP or web-server errors were generated.

    We also noticed occasional PHP slow-log entries involving:

    bwp_check_connection()
    wp_safe_remote_get()
    searchpro/inc/helper-functions.php

    Could you please confirm:

    1. whether the Cloudflare loader transformation is a known BerqWP 4.1.x issue;
    2. whether an official patch or recommended exclusion is available;
    3. whether our berqwp_cache_buffer workaround is safe to retain temporarily;
    4. whether the repeated bwp_check_connection() calls are expected or can be reduced.

    We can provide a minimal sanitized before/after HTML example if required, without sharing the affected website’s identity.

    Plugin Author Hamza Mairaj

    (@thevisionofhamza)

    Hey there,

    Excluding /cdn-cgi/challenge-platform/ should exclude the inline script tag. We’ll try to replicate this bug. The information you provided should be enough to reproduce it. I’ll get back to you with an update.

    Thread Starter paolurso

    (@paolurso)

    Hi there,
    Thanks for the update. We confirmed that /cdn-cgi/challenge-platform/ is already configured in both the CDN exclusions and JavaScript exclusions. Despite this, the optimized cached HTML can still rewrite the inline Cloudflare loader assignment.

    We currently have a narrowly scoped temporary compatibility fix that repairs only this exact transformed signature. Please let us know when an official fix is available so we can test it and remove the workaround.

    Plugin Author Hamza Mairaj

    (@thevisionofhamza)

    Hey there,

    We’re unable to reproduce this bug. Could you please share the exact Cloudflare script tag? If you can share the website that would be even better.

    Please send it to our support email at support@berqwp.com.

    Plugin Author Hamza Mairaj

    (@thevisionofhamza)

    I received your email. We were finally able to reproduce the bug and find its root cause.

    The root cause is a regex conflict caused by this comment inside an inline script tag added by Divi:

    // Divi / DB014 can inject the <img> after initial DOMContentLoaded.

    The <img> in the comment is being interpreted as a valid image tag which causes the bug.

    This requires an update on our cloud server. We’re working on a fix, I’ll keep you posted.

    Thread Starter paolurso

    (@paolurso)

    Hi Hamza,

    thank you for investigating this and for confirming the root cause. Your explanation is consistent with the malformed transformation we observed.

    We’ll keep our narrowly scoped compatibility filter active until the cloud-side fix is deployed and verified. Please let us know when the fix is live and whether existing optimized page caches must be purged and regenerated.

    Once available, we’ll test it on a single URL first by temporarily bypassing our workaround, then verify the generated HTML, anonymous rendering and browser console before removing the compatibility filter site-wide.

    Thanks again for the update.

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

You must be logged in to reply to this topic.