Unable to remove parent product multi variant entry once child product deleted

[colmagoo]

I am using the latest Joomla 3.7.4 and Virtuemart 3.2.2. I have created a product with 4 children as multivariants. However when I delete one of the children directly from the main product list (NOT from insider the product) when I go to the Parent product's Custom Fields tab there is an empty multi variant entry for the child product which has been removed. Is there any way that these empty entries cannot be removed as it would appear that they cannot be used again even if I want to add a new child afterwards. Screenshot attached. Thanks

[Studio 42]

For now, you can remove the line using the Browser(F12 on PC chorme or mozilla)
Select the element in the html inspector and remove it & save the product.

[Milbo]

Please use http://dev.virtuemart.net/attachments/download/1086/com_virtuemart.3.2.3.9614_extract_first.zip

should be fixed

[T.A. Garrison, LLC]

Is that file safe for Joomla 4 and VM 4.0.12 10777?

I have the exact same issue and it's costing me a HUGE amount of time because the only way I've been able to get them deleted is to delete the entire Multi Variant, where I have 4 Ramifications and a lot of children already assigned.

Every time I have one little problem with a child, I have to start over with the entire Ramifications set up.

I downloaded the zip, but I see the files were created in 2017, and they have version 3 for both. Is there an update?

I actually followed the instructions from Studio 42, and, I didn't think it was possible, but it worked. Of course it's a bit to have to drill-down to the specific line I want to delete, but it worked.

The next question is "why" in the world does that happen?
The errors only state that the child has no slug or price. It has all of the data remove when you "attempt" to delete the child, but it still exists in cyber land.

---------------

I've added the "delete" code that I found per one of the moderators that does delete - but still leaves the "ghost" of the product.
Today, 4-19-2023, I tried to delete 3 children that were set up fine, but kept throwing errors about how the slug can't be NULL and how the product id cannot be NUll.
So whatever happens during the delete of "either" the standard select the product and hit "Delete", or the code that creates a delete button to the right of each child when using Ramifications, they both still leave ghosts of the deleted product.

So I reviewed the database and saw that the products, in fact, did NOT exist in the database, BUT...there was overhead in all the areas of Custom Field, Products, Customs, Products En_GB, Prices and Shoppergroups.
Every one of those tables were noted in the errors that appeared every time I'd "Save" the Parent that contains the Ramifications.

This seems to be something that's been going on for at least 2 years. Is there any end in sight?
The reason I say 2 years is because the exact same issue dates back to 2019, where I found information about how people are doing a "work around".

I'm developing a very complex site in admin, but simple on the front end. And creating the Ramifications for the Multi Variant is the only answer to how I can create the products on the front end with the options. None of the other types of Custom Fields will work for what I need.

It's taken days to try to find out why I cannot get more than a few children created through Ramifications before I save the last one created (saving each one as I go) and get the errors that the last and 2 previous have errors in each of the tables outlined above.

My "next" work around is going to be leaving the database open and manipulating the overhead whenever the "Save" throws another error. Is there no way to fix the bug? I "literally" have thousands or products to enter and each product has as many as 150 children.

-----------------

Here's what I found in the database.

In each of the products throwing an error, the following was created in "product_params":

min_order_level=null|max_order_level=null|step_order_level=null|shared_stock="0"|product_box=null|


What it "should" be is this:

min_order_level=""|max_order_level=""|step_order_level=""|shared_stock=0|product_box=""|

Notice the null where double quote should be, and quotes around 0 in shared_stock that should not be there.

When creating "children" from Ramifications, the "previous" child, if there is one, will be copied to make the next child. Apparently, the child I had in first position, even though it was NOT throwing any errors, was the problem.
That child was the first to have null where "" should be, so every child after that had the same.

I do also have the Quantity Prices plugin installed.

I'm in the midst of working out how to stop the children from having null in place of ""

==============================

In order to attempt to find what is causing the problem, I created a new site with nothing installed but the VM and Joomla 4.
I created the product, 2 custom fields and began making the ramifications necessary.
I went through the entire process and everything worked perfectly.

So I returned to the development site and wiped out 100% of the products and children in the 1 parent and children where the errors continue to appear.

I slowly rebuilt the Parent, Children, everything necessary to create the correct matching fields for the drop downs on the front end.
Everything was going smoothly until...I saw that there was text that had been left out of 1 line in 1 of the ramifications.
I added the text, saved, and BAM! The errors returned with a vengeance!

Obviously, when I make a change in the ramifications, that throws "something" into the database that changes all the stored data from whatever data it was to NULL everywhere. Not just in the product tables, but a lot of other tables - so many that I'm not even going to attempt to run down the problem.

I'm hoping that this thread will drive Milbo crazy enough that it will get some attention.
I've tried to pay for help, Milbo, and you / nobody will respond. I've sent messages through support and never had a response.
If I could even get a "we don't want to talk to you" response, at least I would know what's going on. Thank you so much.