fractaleater

More specifically, Sellkit is using an element ID like “#sellkit-billing_state”. But the payment gateway wants ID: “#billing_state”. Like it gets with “billing_country” or “billing_address_1”. Not sure why Sellkit adorns the ID, but they also have name attribute on the select element like “billing_state”.

Any chance the gateway can be adjusted to try the name attribute if the ID search fails?

I have a similar issue.

Seems to be a problem with Sellkit and new Woo Checkout experience.

If you enable legacy checkout WooCommerce > Settings > Payments > Stripe > Settings > Advanced settings > Enable the legacy checkout experience, it will allow the payment to proceed.

Apologies. redirect_to works as expected. The problem appeared due to stale cache.

Great. Thanks for the response. I look forward to a fix.

Concerning the plugin “Enable Media Replace”, it looks like it works by deleting the attachments, and adding a new attachment with same name and date, but in this case, the orphan problem is even more scary if the replacement image is a different size than the replaced image. Orphaned webp files from the replaced image will sit alongside replacement image webp files, and depending on the device viewport, different images will be served.. a ridiculously hard bug to track down.

Anyway, thanks for your time looking into this.

Follow up.. I tested a file that was not replaced with plugin Enable Media Replace. So this test was just a regular group of jpg files processed by QUIC.cloud, and returned to my server as webp. When I deleted the image from the Media Library using “Delete permanently”, all the webp files downloaded from QUIC.cloud remained, while all the group jpg files, the original size source jpg and WordPress sized jpg files, were deleted. The WordPress attachment page was also deleted, leaving behind orphans – an original size webp and WordPress sized webp files.

Is this behavior by design or is there a problem with my configuration? If by design, is there a recommendation for how to prevent orphan buildup? Do I need to hook “delete_attachment” and manually delete webp files downloaded from QUIC.cloud?

And this morning, my SCFM backend “mobile not detected..” error message vanished.

Sorry for the distraction.

And this morning, my SCFM backend “mobile not detected..” error message vanished. Bizarre.

I am talking about another site. My site. Not the OP’s site. The issue for my site is that the backend is reporting “mobile not detected…” condition when the frontend is behaving correctly. I am seeing the correct mobile version and the correct desktop version. I think it is odd that I am seeing the same W3TC time stamp for both mobile and desktop versions when many seconds have gone by between requests, and I mention it as a possible source problem for SCFM’s backend detection mechanism.

So, my problem is that SCFM backend detection mechanism is false positive since my cache does separate mobile from desktop.

Hi Jose,

So a week or so ago, I updated WordPress and W3TC and SCFM.

Not sure when exactly, but an Editor informed about the same “mobile not detected..” reported by the OP.

I have found that with the same cache timestamps, W3TC is serving different content.

So after W3TC clear all caches, load guest mode Chrome, dev tools sim iphone 12, load page, get correct mobile content, I even hard coded text “I AM MOBILE” in the page. In view source, got a W3TC served timestamp. Close Chrome, open guest mode, load site and get correct desktop version, the text box does not even appear on the desktop version. View source, has no “I AM MOBILE” and got identical W3TC served timestamp.

No other caching plugin. Not using CDN.

I do notice that in view source, object caching is different depending on which page, desktop or mobile, was opened after purging all caches.

Want to take a look?

Thank you for the prompt response.

I was able to disconnect the new draft from the original mobile version by showing custom fields of the new draft and deleting the eos_scfm_mobile_post_id field. I can also confirm the original mobile version had eos_scfm_desktop_post_id pointing to the original post.

Yoast Duplicate Post, under “WP Dashboard -> Settings -> Duplicate Post -> What to copy -> Do not copy these fields”, has an edit box that accepts a comma separated list of wild card fields to ignore. I entered “eos_scfm_*” in this field and saved. I then created a new draft from the original page and it did not copy the eos_scfm_ prefixed fields. The new draft was not connected to the original mobile version, and the new draft has the “Mobile version” button labeled “CREATE MOBILE VERSION”.

Using what you’ve said about the relationship of the eos_scfm fields, to duplicate a post *and* the mobile page, exclude “eos_scfm_*” as mentioned above, edit the original post and “Copy to a new draft” (note the resulting post id). From the original post, edit the mobile version and create a new mobile draft using “Copy to a new draft” (again, note the resulting post id).

To connect the two as desktop and mobile versions of the same page, from the new draft mobile version, add a custom field by selecting “eos_scfm_desktop_post_id” from the dropdown and entering the new draft post id. (note: I also added “eos_scfm_mobile_post_id” with the post id of the new draft mobile version as that was the observed setup of the original posts – but it is unclear why this might be required). From the new draft, add custom field “eos_scfm_mobile_post_id” with the post id of the new draft mobile version. After saving both draft versions, desktop and mobile should be connected.

Update.

So, completely forgot am using Popup Maker plugin.

I am now looking into what might be happening there.

Richard

Notification made to Cloudflare.

As a final attempt to enable Railgun, added “Cache-Control: no-store” for all pages in wp_header filter, but that was ineffective. It might be possible to control Railgun with special headers, but I found only “no-store”, which continued to result in 404 responses.

Ultimately, denial of authenticated access to password protected forms while using WPS Hide Login is related to cached 302 redirects for wp-login.php based forms by the Cloudflare Railgun product.

Richard

Enabled Cloudflare CDN for the domains, but disabled “Railgun” dynamic content accelerator. Plugin works properly. Verification completed and successful for logged in users/normal users/incognito.

Ok, definitely a caching problem.

Both plugins_loaded and wp_loaded now have expected values in $_GET/POST.

Site uses Cloudflare. Instead of enabling development mode to bypass cache, disabled cache for the domain, and password protected page now loads protected content. Verification completed and successful for logged in users/normal users/incognito.

Just realized that I misread a critical line in wp_loaded that completely invalidates wp_loaded as the source of the problem. wp_loaded is designed to ignore action=postpass. Although probably $_GET/POST should still be populated.

More peculiar is that the first test run (10 hours after last run), displayed the protected content. A confirmation run (30 seconds later) failed. Now seems more like a caching issue.