shadowq

Mate, you’re totally missing the point. Like, you’re not even reading what I’m writing.

You sent me over to https://woocommerce.com/feature-requests/square/, to lodge a feature request for your Square plugin, right? Go ahead and click on the link, what do you see? You see a list of all feature requests for your Square plugin, right? (Image below to make sure you’re still following).

Now, click on one of those feature requests. Any of them. At all. Why might someone want to do this? Well, first of all, there’s only a snippet of the description showing. Secondly, you may want to join the many comments that have already taken place. Now once you click one of those feature requests, where do you end up? (If you’re not redirected back to https://woocommerce.com/feature-request/ then try this in an incognito window).

I’m not even sure why I’m even bothering explaining this to you, I was literally trying to help point out a glitch with the woocommerce feature request page at the moment. Doesn’t benefit me in the slightest.

Do something with this. Don’t do something with this. I don’t care. Up to you.

Nah, I was trying to look at some of the other feature requests (eg- https://woocommerce.com/feature-request/square-sync-options/). All of them redirect back to https://woocommerce.com/feature-request, which serves a 404.

Thanks Shameem.

FYI- all of the current feature requests redirect back to a 404 page (https://woocommerce.com/feature-request/).

Cheers for the quick reply. Can I ask why not? The weight is fetched via the catalog API, is there a particular reason as to why it’s not utilised within Woocommerce?

Thanks!
Jarrod.

FYI – this is mentioned as a bug report for GiveWP

https://feedback.givewp.com/bug-reports/p/givewp-should-display-errors-if-the-donation-is-missing-required-fields-when-usi

Just wanted to add that this bug is pretty annoying, and poor UI for donors. I’ve added my upvote to the bug report.

Thanks for the reply. This is the only order it’s happened on. It looks like the plugin has called the API again 8 days later to see if anything had happened with that payment intent. In my opinion, 8 days is 7 days too long. At the latest, you’d expect a check again 24 hours later. Thoughts?

Thank you for your reply.

Double checked the capture later feature, and it’s definitely not enabled (all other orders, before and after, have been fine.

I’m wondering if it was a webhook failure, however, Stripe only seems to keep webhook logs for 15 days, and unfortunately it’s been 16 days since the payment was captured!

Order notes – https://snipboard.io/Rr6MGP.jpg
Stripe Log for the given order – https://snipboard.io/DusbqB.jpg
System report – https://pastebin.com/BgSe09TS

Ps- thanks for the link to snipboard.io, that’s super useful! Will definitely be using that one in the future.

TIA.

I should specify- the reason this is a huge issue, is that the delivery date was set when the payment intent was created. However, by the time the payment was captured, the delivery date had passed and the system didn’t book an automatic delivery using the weekly manifests and the order was missed.

@natebald @aurpo

As @georgyvk mentioned, there is indeed a bug. If you’re not keen on hard-coding changes, there are also filters set up that you can hook into. I wanted all users to be able to change their password, and due to the bug mentioned above, added the following filter to my child theme’s functions.php (allowing for changes to stick if plugin updates)

function editor_change_username($allowed){
        //could add role or capability checks here
        return true;
}
add_filter('username_changer_can_change_own_username', 'editor_change_username');

• This reply was modified 3 years, 8 months ago by shadowq.

https://github.com/woocommerce/woocommerce/issues/29129

Hi there, thanks for the replies. Missed the notifications, sorry.

https://github.com/woocommerce/woocommerce/issues/28939

Thanks! Sorry for not posting in the correct forum. Appreciate the quick reply ??

Thanks! Email sent.

I’ve fixed this, in case this helps someone else.
My MP3 URLs being filtered with relative, not absolute (didn’t include the domain). If lines 89-90 in map_download.php weren’t commented out, the error would have been easier to spot (“File doesn’t exist”).

I just added a check to see if the URL requested was relative, if so- then add the relevant prefix.

After line 29:
if(substr($file_url,0,1) == “/”) $file_url = (($_SERVER[‘HTTPS’] == ‘on’ || $_SERVER[‘HTTPS’] == 1) || isset($_SERVER[‘HTTP_X_FORWARDED_PROTO’]) && $_SERVER[‘HTTP_X_FORWARDED_PROTO’] == ‘https’ ? “https://” : “https://”) . $_SERVER[‘HTTP_HOST’] . ” . $file_url;