troussel

Hello, thanks for the answer. So the web hook work when the admin is connected. This mean that PayPal will never call the website alone from his server ? Because, in this case, it will be blocked from the SSO at Apache level.

Thanks.

think the probleme come from both, because when uam is on, woocommerce doesn’t count the stock good. The red messges is a woocomerce message, not a uam message. So th eprobleme is in the two appli when they work together.
But, know thee is an answer for all who have this probleme. Desactivate UAM on the product level.

wll write this on all other forum who people search for years.

so to have the same , with the product i have exported, you must install uam and protect for the logged person the product.

So i have found where is the probleme, the probleme is with User Access Manager, when it is activated, the bug komm, and when it is deactivated, the bug come not.

But how i can solve this, i don’t know. Because we need UAM, just peaple who have paid to be granted must see the page with the shop, and other pages.

hello, we have php 7.4.
our version of mariadb is 10.0.38, it is actuel the most that yum have to install on centos7.

ok i will try with wp staging, but it will take some time. I don(t have much time now.

do you have a mysql or a Mariadb ?

hello,

https://mensa-france.net/wc-product-export-21-3-2022-1647874122068.csv

Thanks

i think that after the paiement, the programm make something wrong, perhaps a null for a zero in database, or something in the art, and if we go to the backend, and we do only update without any changibg, it make the réal value, and it is ok after that.

Hello,

so it is the same.

And this time it was with bank transfert on “on hold” so nothing to do with stripe too.

The probleme comme when there is 4 attributes on the virtual product with 2 or 3 values each, and the stock is not the same for every variations, and the price is différente for every variations.
And it’s appear when the command is “on hold”, “completed” or processing.

I think that if someone by woocommerce test this with 29 variations of 4 attributes on virtual product(set in each variation) he will have the same bug, when the payment is awaiting, so he must go thru the payment, before, it is ok, after the payement egual if the statut is completed or on hold, there is the bug.

i can say a little bit more, because the shop manager has let the products on “sold out” :
– on the main page of the shop, under the catégorie image, it is saying that there is 3 products available, but on the categorie page, there is only 2 product image, the one who was booking has deasepear, if i go to the pruduct page with his url, it is saying that he is not im stock, but on the bach end, it is saying “in stock”.

So the count of the sold is ok on backend and categorie list page, but not on categorie page and product page.

Cache is empty.

I have try to clear transient, recount term, etc, all what we can do on the tools, from woocommerce, it does nothing.

the log of the event that make the product goes soldout.

https://snipboard.io/I8Jlr7.jpg

so we have found that it is when the paiement comme back, to be completed.

So the step is to make a product with 4 attibutes, and on evry attribut 3 or 4 value, then to generate the variation, and make some away, so not all the variations are possible.
We have 29 variation on 4 attribute.
We use Stripe, and not paypal (to expensive).
All the variations are with stock, and prices. So the stock management is on the variations level.
It is all products without sending, in our case, it is bedroopms in a hotel during an event, so virtual products.
If you reserve and not paye, it make nothing, but if you go true all the process and pay, than the product will be sold out.
We have tshirts with variations, and there is no problem.

So it seems that it is only on virtuals products. We have not the problem with tshirt or bucket but there is no manage stock on it.

And there is no compression or cache in apache.

Cache is deasdabled in wp-config, and it is empty.
We are our own host, so there is no cache. i have look on the serber, the directory is empty.

Hello,

so i have make the update from php 7.4 this night, and just now, after one cammand from a product with many variation, he is on sold out on the product page.
but, on the categorie page, he is on the choice, so the bug seems to be only on the product page.
Normaly is he is sold out, he wouldn’t come one the categorie page, but he comes, so on the categorie page, the programm is good, but on the product page, where there is the choice of variation, there is just a message that the product is out of stock.
In backend, it is “in stock”.

So the probleme stay with frontstore, without any plugins. with php 7.4, etc.
If we just edit the product, change nothing and save it again, than he is OK after this manipulation. After someone by only one , he goes out of stock , and all the variation have stock.