Daniele Muscetta

As a side note, what I was doing was the suggested approch even just 8 months ago https://www.ads-software.com/support/topic/can-sepa-direct-debit-be-limited-to-subscriptions/ @mrclayton

Hi @carolm29 – do you know if the additional plugin (for another 109$…) allows to filter out just stripe SEPA vs credit cards?

I had custom code that was doing this manipulating the $available_gateways array and it has been running for years without a glitch with the old gateway experience; but, with the new checkout experience, it appears that “everything stripe” ended up in one big gateway and SEPA is no longer considered an option that can be turned off or on independently based on criteria/conditions…

Hi, at this stage I am just reaching out to all plugin owners (for the plugins relateed to woocommerce that we use) as we wait for full HPOS support from woocommerce.

In your case, I guess the piece that collects the information (the ‘child’) on remote sites will be fine – it’s the receiving part (the ‘parent’) where you just need to make sure that you are playing by the recommendations of woocommerce itself (see article I already linked) in how you call certain api. You might already do (I have not studied your code yet), or maybe it’s the extended API which deals with orders etc so ‘at your layer’ you might not need to do anything, hopefully…

I just want to make sure that when woocommerce is ready to fully enable the feature (their new high perf order storage), this upcoming year, we can switch it on without having any addon that doesn’t support it… just trying to anticipate potential blockers down the road ??

Consider it a ‘heads up’ this is something that eventually every woocommerce-related plugin will have to deal with.

With best regards,

Of course, this is not a migration I am going to do over christmas ??

Just update the thread when we know more. I think other people will ask this, too, so I suppose it’s a good question to have in the forum.

At the moment I am just surveying the situation and pinging all the various owners/support for the plugins that currently result incompatible – hence blockers – so that we can be ready as soon as woocommerce and all the relevant pieces are ready and don’t have last minute surprises. Other big blocker at the moment is WooCommerce Subscriptions, but I suspect/imagine/hope that both Stripe and Subscriptions are on the critical path for you guys too, with Stripe being very popular and with subscriptions we have tons of renewal orders and we are really looking forward to the performance improvements/gains.

Best regards,

Thank you very much. We are actually using the premium version – only on the production site where I am seeing some weirdness in these compatibility checks…. so I am not 100% sure anymore if this is actually flagged or not. More context in this related thread about another plugin: https://www.ads-software.com/support/topic/high-performance-order-storage-compatibility-7/

No rush from this side – at least for us this is a preliminary investigation to make sure we’ll be ready to flip the switch down the road when HPOS/COT will be fully supported (we have to wait for woocommerce subscriptions too to be declared compatible, too, first)…. so right now I just started surveying the plugins that we use to get a full picture and certainly this is not some migration we would do over the christmas holidays ?? Take your time and thank you for all of your work.

I would not be surprised if it’s a quirk in their check or just on my system… as I refresh that page with the ‘incompatible list’ today, sometimes it returns an actual list and sometimes it doesn’t. Very weird. It might be related to some caching layer so I’d have to investigate more, too… of course it only happens on the production system and I can’t reproduce this behaviour on test environments…

Thank you again. Apologies if this was a randomization.

That’s good to hear, thank you. very much.

Where did I get the idea that it’s not compatible? From woocommerce itself… if I go to woocommerce -> settings -> advanced -> features , HPOS/COT cannot yet be enabled because of ‘incompatible plugins’… and this one appears in the list, so I am just looking thru that list I get on a certain production system and checking those plugins reaching out to each and every one of them to find out the truth ??

.i.e. <mysite>/wp-admin/plugins.php?plugin_status=incompatible_with_feature&feature_id=custom_order_tables

Maybe there is something busted with the compatibility check/declaration, then, either on the way you declared compatibility or in the way woocommerce itself checks it?

• This reply was modified 2 years, 3 months ago by Daniele Muscetta.

FYI, keep in mind that if you need access to such an environment (because I understand the subscription module is a paid one and you might not have it handy) in order to see/verify/debug/improve this, I will be glad to let you use our company’s staging/pre-production environment.

• This reply was modified 2 years, 12 months ago by Daniele Muscetta.

Nevermind, I found that it basically uses the message you change / write in the settings… basically the localized strings are a joke.
But I found a way to change them.

Thanks, yes you are right, I will look into the standard WP api for that… altough it might require keeping sync of wp user ID’s in the ‘other'(main) account database, not just their emails.

I am glad to hear you are working on it, though… I see the plugin has been temporarily taken down, I figure you are about to ship a new release?

Hi, thanks, you are very kind but don’t worry too much, it was a question asked probably too early in my investigation… now I have a better understanding.
I have solved on my site’s end – the site that holds the ‘master’ accounts: I first call the create api which works the very first time and – worst case – it fails telling me the user already exists… and then I proceed with the login/redirect passing the token, regardless of whether the user was just created or if it was pre-existing. Of course, as you say, I use the email as the field to associate users on both ends. It has been working fine for a few days… I think I can live with it, it seems reliable.

One more useful feature I haven’t figured out how to set up – and this one is probably more important as time goes by, would be a way/api to UPDATE existing users – i.e. I pass first_name, last_name and other fields during the creation…. but then if the user updates his/her data on our ‘main’ site, due to the approach above (=user already exists), they remain old/out of sync in WP.

If you want I can open a separate thread – to help other folks finding it?

Thanks much,

Daniele

I try to answer myself: since I saw now that the ‘register’ api returns “user already exists” I should probably just try to create it regardless and then login… is this the recommended approach?
Thanks,

Is it safe to upgrade to 3.9? Has this been seen/addressed? Thanks,