nm001
Forum Replies Created
-
That’s really helpful. Presumably the filter belongs in functions.php
We’re using a CDN so consistently two URLs but cron only runs on the origin server.Now the cache doesn’t get totally purged
But when a new story is posted, there’s no partial purge either.I found a solution, although it requires an edit on each plugin update.
The Cloudfront dual site url issue was the cause.in cache/class-wpo-page-cache.php
there is a section that detects site changes
I commented out these lines:if ($is_the_site_url_or_folder_changed) { $is_cache_purged = $this->purge(); if ($is_cache_purged) $this->file_log("Full Cache Purge triggered by: ". __METHOD__); } if (!$this->write_advanced_cache()) { add_action('admin_notices', array($this, 'notice_advanced_cache_autoupdate_error')); } else { $this->update_cache_config(); }Just to clarify
1. just logging into the website wp-admin triggers a purge. Definitely has been working cos there were 5000+ posts purged. Any navigation in admin whatsoever triggers purge.
I looked at this page on your site, and I was not doing any of these activities to purge.
2. the cache is for the public cloudfront site, so has the ‘public’ url. The name of the wpo-cache directory where it stores it is the ‘public’ url. The admin installation uses an ‘origin’ url. This Cloudfront detail might be entirely irrelevant.Tested and works. Many thanks!
Thanks for looking into this.
The Settings others screenshot and subs plan. I have tested with other subs plans and same issue.
I also tried it on another site and had same issue.Hi @alexandrubodea
Here’s the gateway screenshot and the plugin screenshot.
This is the test card used: 4000002760003184
The following page uses pms-register
URL: https://research.ledgerinsight.com/register/Thanks.
- This reply was modified 10 months ago by nm001. Reason: fixed screenshot url
Just adding the error messages FYI (identifying data redacted):
[Sat Jul 19 15:23:29.877038 2025] [php:error] [pid 580249] [client ip.address:62248] PHP Fatal error: Uncaught Stripe\Exception\InvalidArgumentException: The resource ID cannot be null or whitespace. in /wp-content/plugins/paid-member-subscriptions/assets/libs/stripe/lib/Service/AbstractService.php:105\nStack trace:\n#0 /wp-content/plugins/paid-member-subscriptions/assets/libs/stripe/lib/Service/PaymentMethodService.php(139): Stripe\Service\AbstractService->buildPath()\n#1 /wp-content/plugins/paid-member-subscriptions/includes/gateways/stripe/class-payment-gateway-stripe-connect.php(496): Stripe\Service\PaymentMethodService->update()\n#2 /wp-content/plugins/paid-member-subscriptions/includes/class-ajax-checkout.php(149): PMS_Payment_Gateway_Stripe_Connect->process_payment()\n#3 /wp-includes/class-wp-hook.php(324): PMS_AJAX_Checkout_Handler->process_payment()\n#4 /wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters()\n#5 /wp-includes/plugin.php(517): WP_Hook->do_action()\n#6 /wp-admin/admin-ajax.php(207): do_action()\n#7 {main}\n thrown in /wp-content/plugins/paid-member-subscriptions/assets/libs/stripe/lib/Service/AbstractService.php on line 105, referer: https:/mysite.com/register/I have no idea if this is related.
But we’re also having issues with WP & cloudfront after upgrading to 6.3
We use Supercache not W3TC
We’re not using S3 – using cloudfront for entire website.
New posts are on the cloudfront website, but the Home page and all category pages are stale. And invalidating them is not refreshing them.
The origin works perfectly.
So either AWS is having some kind of issue
Or 6.3 is causing issues but weird that’s it’s only showing for cloudfront.