aduwow

Hi again,

Just a quick update that might help with the investigation: I found a temporary workaround by creating a Gallery with only one image. In this case, the lightbox works perfectly.

This confirms that the plugin is working fine, but it currently only looks for gallery-specific containers or classes. It would be fantastic if the plugin could also support single images inserted via the standard “Add Media” button in the Classic Editor.

Thank you!

Hello,

Thank you very much for your quick and detailed response — I really appreciate the time and effort you took to look into this.

After rechecking the issue more carefully, I found that the problem only occurs under a specific combination of plugins and settings, not with Ocean Social Sharing alone.Updated findings

The issue happens when both of the following are enabled at the same time:

• LiteSpeed Cache → HTML Minify enabled
• Flying Scripts – Delay JavaScript to Improve Site Speed & Performance enabled
  (https://ww.wp.xz.cn/plugins/flying-scripts/)

If I disable Flying Scripts or turn off HTML Minify in LiteSpeed Cache, the SVG icons render correctly again and no <path> attribute d errors appear in the console.

This suggests the issue is likely related to how these optimization plugins interact during HTML/JS processing, rather than a direct problem with the SVG output from Ocean Social Sharing itself.Additional note

I completely understand that this behavior may be outside the direct scope of Ocean Social Sharing support, especially since it involves the interaction of multiple third-party optimization plugins. My intention was mainly to share my findings in case they are helpful or relevant for future reference.

Thanks again for the fast response and for maintaining the plugin.

Thanks for your reply.

How are you adding the cookie? I’d like to clarify a bit more:

• When I reload the same page, the cache hits correctly after the first visit.
• However, when I close the browser and then open it again to visit the same page, the cache misses again on the first load — even though the wcpbc_country cookie still exists and hasn’t changed.

Here are my current configurations:

• I have added wcpbc_country to the Vary Cookies list in LiteSpeed Cache settings.
• I noticed that this line was automatically added to the .htaccess file:

RewriteRule .? - [E="Cache-Vary:wcpbc_country"]

→ In this case, cache always misses on the first visit (even with the same cookie), then hits on reload.
→ The good thing is: I never get cache from the wrong country.

• If I manually add this rule to the .htaccess file:

<IfModule LiteSpeed>
    RewriteRule .* - [E=cache-vary:wcpbc_country]
</IfModule>

• → Then the first visit also misses (as expected), and re-opening the browser gives a cache hit, but occasionally, I still get cache from a different country.

To confirm, I also created a fresh test site with only:

• LiteSpeed Cache
• WooCommerce
  Then I tested using another plugin: CURCY – WooCommerce Multi Currency Premium,
  which has built-in cookies (wmc_current_currency, wmc_current_currency_old).
  Unfortunately, the behavior is the same — cache miss on the first visit after reopening the browser.

So it seems that even when the cookie exists, LiteSpeed/QUIC.cloud treats the first request after a new browser session as a MISS.

Do you have any recommendation on how to make this more consistent (e.g., persistent HIT when cookie exists)?

Thanks again for your continued help.

Thanks for the clarification earlier about using a cookie-based vary instead of headers.

I’ve checked the WooCommerce Price Based on Country plugin, and it doesn’t seem to set a country cookie by default.
So I created a custom cookie for it as follows:

add_action('init', function() {
    if (function_exists('wcpbc_get_woocommerce_country')) {
        $country = wcpbc_get_woocommerce_country();

        if (!empty($country)) {
            if (!isset($_COOKIE['wcpbc_country']) || $_COOKIE['wcpbc_country'] !== $country) {
                setcookie('wcpbc_country', $country, time() + 86400 * 7, '/');
                $_COOKIE['wcpbc_country'] = $country;
            }
        }
    }
}, 5);

I also added wcpbc_country in LiteSpeed Cache → Cache → Vary Cookies.
When testing, the cookie is correctly set per country and reflects the right currency.

However, I noticed the following behavior:

• On the first visit, cache is MISS (as expected, cookie just created).
• On subsequent visits from the same location and same browser (with cookie still valid), cache is still MISS, not HIT.
• This happens even when I reopen the browser and access the same page again (e.g., mysite.com/shop/ from the UK with wcpbc_country=UK).

I expected the cache to MISS once when the cookie is first set, then HIT afterward for the same cookie value.
But it keeps regenerating a new MISS each time, even though the cookie remains unchanged. My questions:

1. Is there something else I need to configure in LiteSpeed or QUIC.cloud to ensure the cache HITs for subsequent requests with the same cookie?
2. Does the setcookie() placement (currently on the init hook) affect cache generation timing?
3. Is there a known limitation with QUIC.cloud CDN when varying by custom cookie values?
4. Alternatively, could you suggest a WooCommerce geo-pricing plugin that’s known to work seamlessly with LiteSpeed Cache + QUIC.cloud CDN (using cookie vary)?

Thank you very much for your time and guidance!

Thank you for your reply.

Yes, I am on a shared hosting environment. My hosting provider has confirmed that my site is actually associated with two different IP addresses:

• One IP is the origin IP where my domain resolves.
• Another IP is the server’s main outbound IP that may be used for outgoing requests.

It seems that QUIC.cloud may only be auto-whitelisting the origin IP, while the server’s main outbound IP is not included. Could you please confirm if QUIC.cloud needs both IPs to be whitelisted in such cases?
If so, I can provide the exact IP addresses.

Thank you very much for your assistance.

Hi Ali,
Thank you for following up. On my test site, I am only using the following plugins:

Mega Forms (version 1.6.3)
WP Debugging (version 2.12.2)
Query Monitor (version 3.19.0)

I am also using the default Twenty Twenty-Three theme to rule out theme-related conflicts. I set up a clean test site at https://unevencellar.s6-tastewp.com/wp-admin, and the _load_textdomain_just_in_time warning for the megaforms domain still appears in the debug.log and via Query Monitor. You can access the site to investigate directly using the following credentials:

Username: admin
Password: L0_ghklCSSE

Please note that the test site will automatically expire in 1 day, 23 hours, and 41 minutes from now (August 31, 2025, 6:08 PM +07). Given that I’m using a minimal setup with no additional plugins or custom themes, I don’t believe this is caused by a conflict with other plugins. The error persists in this isolated environment.
Here’s the error from debug.log for reference:

[31-Aug-2025 10:59:47 UTC] PHP Notice:  Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the megaforms domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /s6-unevencellar/wordpress/wp-includes/functions.php on line 6121

If you need any additional information, please let me know.

Thank you so much for quickly resolving the issue on iPhone! I really appreciate your prompt support and effort in addressing the problem.