mystyleplatform

HPOS is now fully supported.

Actually I was able to solve it thanks to this article Fix for Instagram Store Products Out of Stock After WooCommerce Sync (Facebook for WooCommerce Plugin)

Basically Facebook for WooCommerce is using this “Available for Sale” quantity number that overrides everything else and defaults to 0, and WooCommerce does not set this value, allowing it to stay default to 0. FB for Woo should just be setting that value to something rather than nothing when a product is in-stock, like just default to 99999999, and this entire issue would be fixed.

Either that or on the Facebook store side, they need to use “In Stock” to supersede this other field they created “Available for Purchase” and not just default it to 0.

One of our clients has this exact same issue.

I’ve checked the other threads and I can verify we have:

1. a theme with no conflicts
2. no other plugin conflicts
3. a catalog originally created for on-website checkout, before they switched over to requiring FB checkout
4. Other products that are NOT from Printful showing in-stock OK
5. No per-product stock overrides
6. Hide out of stock products enabled in settings
7. Manual Sync attempted, no difference

Any solutions?

This error is a live error on every production site that has paypal:

2024-06-06T00:08:12+00:00 Critical Uncaught InvalidArgumentException: PayPal order ID not found in meta.

… is looking for order meta ID on orders that are not yours (facepalm) and then breaking without error catching (facepalm), causing tons of stuff downstream (shipstation etc) to break (triple facepalm!).

For us, this caused us to send 17,000+ fng emails to customers OVER AND OVER again because shipstation couldn’t get a proper confirmation of notification – and that’s just on ONE website that only makes a few orders a day. 17 thousand freakin emails! Practically got us blacklisted from our email provider.

You programmed this as if only PayPal can be the order processor and nothing else without thinking about whether or not this could break stuff, which is like, the main job of a good programmer.

PLEASE don’t hook every order – ever – stick to your own orders, please!

UPDATE 6/11/24: Paypal release 2.8.0 with the fix for this issue.

• This reply was modified 5 months, 2 weeks ago by mystyleplatform. Reason: update

Example URL:

https://www.***.com/calendar/?full=1&long_events=1&ajaxCalendar=1&mo=10&yr=2023&id=118675383

Warning in search console:

Page indexing > Alternate page with proper canonical tag

Hi, sorry to hear that. It’s working in all of our tests on 10+ different websites.

I’d like to help you figure it out if possible.

Can you verify the SHIPPING address is in Florida for all of those orders and that those orders are not refunded or in some unusual status?

Also note International orders are not currently showing in the sales by state report.

Your screenshot seems to be gone now

I will add the feature request for a transaction count / over $100,000 flag.

Unlike most plugins that means it will probably get added.

WooCommerce / jetpack / woocommerce automatic tax rates docs say they do not support multiple state nexus and will only charge Sales tax in the state the store is in. How are you getting tax rates for multiple states? Are you getting them automatically for free with a plugin or something?

I will update here again once it’s updated / released.

Thanks for the feedback

Hi – is it possible the transactions are out-of-country, and thus don’t show up in the sales-by-state report?

I don’t think we have tested it with Subscriptions yet but we will

Wow I wasted a lot of time going in circles on this just to find out it doesn’t work with Advanced accounts (multi sub accounts under a parent account).

Is there any workaround or advice how to get this working? We have to use our multi-sub-accounts setup parent account…

Still waiting for some feature to address this issue.

Adding 1 more star for now since Wade has been helpful in running the check manually to verify if any PoPs cannot reach origin server.

Hi Wade,

Yes thanks for responding, you’re the same person that responded to my most recent support thread on the slack channel.

You’re right that it’s an issue caused by the hosting company’s firewall, but it’s a 2 part issue, one part is them detecting and blocking bots, and the other part is your servers hitting their servers to crawl and cache files, seeming like a bot and thus getting blocked in one location.

Since your service is offered as something that works with third party hosting companies, and those companies represent literally millions of potential customers, this is part of the nature of your service to need to be able to mitigate issues with hosting companies and their firewalls when they occur.

When this occurs, I can contact my hosting support with the IP address of the regional Quic Cloud CDN server that is not able to reach the origin host, and I can resolve it myself without needing your support staff to step in.

The only problem is that only your support staff and your systems know when a regional server cannot reach an origin website. We go weeks or months with a huge chunk of the country not able to reach our website and we just simply don’t know.

So, even if I do open a ticket on Slack or thru Support tickets, this is a delayed response days, weeks, or months too late. If an alert notification is sent to me when it occurs, I can respond with my hosting company and resolve the issue within minutes or hours.

So, for now we just need to know when it’s happening and what server / IP it’s happening on.

I think the easiest way to do this for now would be email notifications or SMS notifications (or both since they’re almost the same thing) as an option in every Quic cloud account settings. Then customers can handle it from there and it wouldn’t cost too much resources to send out the notification email.

That said, if the server system was updated to catch 520 errors and in addition to sending a notification to the account holder it would also then ping the next closest CDN server to see if that one is hitting the website OK, then it could proxy through a nearby regional server and continue to reach the origin server that way, then downtime could be avoided all together, but the customer could still be notified that a regional server was having issues and cannot reach the website etc and can take it upon themselves to resolve it, while the broken node continues to proxy thru an alternate node to keep the site alive in the meantime.

Notifications could be queued and limited to once an hour, or even once per day, to throttle it to something reasonable.

I tell you if you can make this happen then your service will be flawless for me and I will bring all of my WP sites and enterprise client’s sites onto it.

Now that I look at it closer, it’s only Events showing up in the list of posts along with featured-work posts, not regular posts.

It just started working suddenly at some point, not sure why.

This does work to remove it from pages that don’t need it:

wp_dequeue_script( 'pw-gift-cards' );

I assume the only pages that need it are Cart / Checkout / WooCommerce pages…

Update: I tried this via add_action and some additional conditions for the right pages and it works. Please let me know if I missed any known pages that are a security risk without recpatcha, but I think I got the main ones at least.

Not fully optimized or minified code yet, but here’s an example that works for me if anyone else needs it:

function no_wf_recaptcha(){
	return false;
}

add_action( 'wp_enqueue_scripts', 'filter_recaptcha', 1 );
function filter_recaptcha(){
	
// check for register / login
    $isRegisterOrLogin = function_exists('login_header') || ($GLOBALS['pagenow'] == 'wp-login.php' && isset($_REQUEST['action']) && $_REQUEST['action'] == 'register');

// check for common no-recaptcha pages
    $noReCaptchaNeeded = is_user_logged_in() || is_front_page() || is_home();

// login and register needs recaptcha.  common no-recaptcha pages dont.
    $needsReCaptcha = !$needsReCaptcha && ($isRegisterOrLogin || is_account_page() || is_checkout() || is_cart() || is_wc_endpoint_url( 'lost-password' ));

// dont use recaptcha if its not needed.
    if($noReCaptchaNeeded && !$needsReCaptcha) {
        add_filter( 'wordfence_ls_require_captcha', 'no_wf_recaptcha' );
    }
}