The list of downloadable files remains visible under the “Downloadable product permissions” section when you view the order the admin dashboard. When I manually revoke download permissions from an order, they’re removed from this section, so I think it’s confusing that they’re not removed from a refunded order. I’d provide a screenshot, but I’ve already deleted the order from the system.
Thanks for clarifying the behaviour. I think removing the product download links from a refunded order would make it clearer for store owners. In the meantime, I solved my particular issue by creating the order using a coupon code set to 100% of the value of the cart. This worked well.
Sorry, but this is not resolved at all. I just haven’t had time to deal with it in the last week or so (new book launch, you see). Since the site is hosted on a VPS that I manage, there’s no hosting company support to contact – just me. Digging into what little that cPanel or WHM give me access to has revealed nothing so far – same with the htaccess files. I’m hoping to take another look in the next day or so.
Thanks again. I’ve been having a look at the Apache logs, and find multiple instances of this:
“AH01630: client denied by server configuration”
Clearly this is a sign of the problem, as it’s associated with multiple Jetpack-related URLs. I still haven’t been able to locate the source of the issue, however. Htaccess files appear good, but I don’t seem to have access to the vhost httpd_conf file, so still working on that.
Thanks, @tamirat22. When I checked my Facebook Business Integrations, I saw this:
I instantly thought, “Aha!”. However, reconnecting from the Jetpack end made no difference, nor did removing the integration from the Facebook end and reconnecting. I’m still getting stale data, and still getting the same 403 error in the debugger.
Contacting Facebook support is about as useful trimming my toenails with a chainsaw, so it looks like I’m at a dead end.
Thanks again for your reply, @tamirat22. I disabled W3 Total Cache, but it made no difference. There’s nothing on the server that I’m aware of that might be affecting this, but since we’ve ruled out most other possibilities, I guess it’s worth another look.
Many thanks for your response, @tamirat22. I did as you suggested and disabled the site accelerator, but still get a 403 response from the Facebook debugger. It also still gives what looks like a Jetpack URL for the preview image:
Yes, I tried all this already, and I don’t use a robot.txt file.
Images are all larger than required, and fully public. The OG meta tags are set, but have a curious last parameter: “ssl=1”. I don’t know what this refers to, but looks suspiciously like it’s related to security certificates (I’m presuming it’s something different, however). Is this perhaps the problem? What does this parameter mean?
Previously, posting to Bluesky and Instagram were working flawlessly, but since yesterday, posts to Instagram are now failing too.
Krystian has been helping me with this via a support ticket, and we’ve concluded that for now, it’s best to stick to the Classic checkout, based on shortcodes. The newer, block-driven checkout page just doesn’t work on my site, for reasons that currently remain a mystery. For now, everything seems to be working, so I’ll mark this as resolved.
Ah, thanks for the explanation! You shouldn’t see anything related to ACP at all on the live site right now, as I’ve disabled the feature for the moment. I assume you’ll want it re-enabled for testing in order to follow up the support request?
Yes, the Checkout page is one I’m referring to that has the problem. To restate: the “Place Order” button on the Checkout page is currently non-functional after choosing the credit/debit card payment option. It merely creates a draft order, and for a new or not logged-in customer, all other details are blank.
I’ve disabled that option for now to limit the damage.
@inpsydekrystian I’m not sure what you mean by “hosted fields”. I’ll submit a support request as you suggest.
