First, when I try to use "outofstock" and "instock" in the filter, no products are found. When I use "1" and "0", products are found (see screenshot).
Second, even though the above works and finds products, if I bulk edit the product to change its status, the view does not show the product until I edit each product individually.
Yes, I am using "stock status".
Are you thinking that for some reason, something is preventing the stock status from being changed in the database unless it is single edited?
I tried a bulk edit where I change price, and that works ... bulk edit on stock status does not. That's why I thought it might be the filter, not some kind of conflict.
I see that Nigel is already familiar with the issue, and I am off the next 2 days due to my weekend, so I leave this ticket in Nigel's Queue.
Let me however give some short input first:
First, when I try to use "outofstock" and "instock" in the filter, no products are found. When I use "1" and "0", products are found (see screenshot).
It seems the field stores a boolean instead of a string. WooCommerce is BTW having this mix of values often. With mix I mean, that the DOC states something else than you see in the code. I am not familiar yet with the exact issue, but I think this is no problem and probably WooCommerce just changed the way to store the value (?)
Second, even though the above works and finds products, if I bulk edit the product to change its status, the view does not show the product until I edit each product individually.
That's the View's caching mechanism.
It will purge when you run a save_post on the Post Edit backend or in a CRED form or in a Field or similar.
It does not run on the bulk edit or quick edit, as those actions are not included in the cache cleaning mechanisms.
All you would need to do (that should work) is refresh the cache (for example just save one post in the backend, edit interface).
That should theoretically flush all the View's cache.
It's strange that you need to edit each product individually.
Are you sure the bulk edit stores the right values in the Database?
I have a clone of this website because I am currently developing a phase two of this project, so I was able to test Beda's theory about the cache clearing upon updating a single product. This did not work, it simply displays that one product on the shop page.
As to Beda's question, "Are you sure the bulk edit stores the right values in the Database?", this doesn't seem likely, as the products are displaying ... they're just not displaying until I update every single one of them individually. If there was wrong data in the database, I would think they wouldn't show up at all.
With 100+ products in the store, this is a tedious task indeed.
Also, just so you are aware, the shop page uses a WordPress Archive, not a View. I am, however, using Views on separate category archives for products.
Is there a way to manually clear the Views cache without saving a post, but actually pushing a "clear cache" button?
Okay ... I did a little digging and found something out.
First, bulk editing the products edits the "_stock_status" product meta.
You will see in my first screenshot that this line is marked "instock" so, I went and updated the individual product, and additional product meta entries were added to the database only after I updated the product individually:
View is added entries to the database, but only after the individual product is updated. Also, I checked Views, and the original WooCommerce table entry of "_stock_status" is not an option.
Please let me know if this is a glitch. The table entries don't exist on the product until it is updated, even though the "_stock_status" actually gets updated in the database, the Views entry is the one that the View is looking for, and it can't find it.
If the View filter is working off the Views custom field "views_woo_in_stock" you can update/generate those by going to Toolset > WooCommerce Views and at the bottom in the section "Static Product Fields for Parametric Searches" run the manual calculation now.
You can set up a cron batch job to run this periodically to keep these fields up-to-date.
