Irrational naming of Custom Field inputs in 2.0.7f

[balai]

Hi

Im noticing a really strange naming of the form inputs of the custom fields in the product details page.
This regards the input names and not their labels.

For example a CF named "color" (cart attribute) has the Custom field id 10.
The assigned values of this CF to the product A are:
Red ->value id: 20
Black -> value id:25

Now in the product details page those 2 fields has this format:
<input id="20" checked="checked" value="20" name="customPrice[0][20]" type="radio"><label for="20">Red</label>
<input id="25" checked="checked" value="25" name="customPrice[0][20]" type="radio"><label for="25">Black</label>

This totally unorthodox. How the value id of the 1st value is used as name for all the values?
If you want to have the same name for all the values this should be: customPrice[0][10] (using the id of the custom field and not the value).

* Custom field id-> the virtuemart_custom_id in the table #__virtuemart_customs
* value id ->  the virtuemart_customfield_id in the table #__virtuemart_product_customfields

Please take this seriously. The code of VM is used by 3rd party extensions so the changes should follow some logic

[balai]

Anyone? Max please check this.

Its important for me and for other devs as we need to know if we have to do changes in our code

[balai]

Its really dissapointing that there is no one to offically inform the 3rd party developers about changes from version to version.

Of course its a forum , of course its voluntary but how i can continue to support Virtuemart and develop add ons for that when

1. i m left in black. Its been a bunch of times that there is no one to confirm if this is a bug which is going to be fixed or will be left as is.
2. i need to change main parts of my code from version to version having a complex tree of different cases. Because somebody has renamed an API function from printSomething to somethingPrint or somebody has deleted an API function without carrying for backward compatibility.

??

[Milbo]

The stuff was not done until version J !

Second I am just on it writing that.

third the main change was done 25.4 (I am just running through the logs). Before it was just stored customfield_id:customfield_id, now it is using customfield_id:"pluginname;value;custom_id or so".

As I already mentioned before in some news, the customfields are far away from what I wanted to have. What I tried todo now is to make them better with less impact as possible. I rechecked it many times and most plugins work without any changes. It just depended what you used before, when you used the value of the array, just use the key now.

Additionally to that, the most of this stuff is directly done in the core. You do not need to think about how the plugin data is stored. We can release since yesterday evening and atm we write down the changes.

We are very happy, when you can help us with the stuff which is changing or not working for you as 3rd developer.

[Jumbo!]

Now we can see another problem. All custom fields under a group and using same item id (customfield_id). This is completely wrong.

Code Select Expand

<input id="13" checked="checked" value="23" name="customPrice[0][13]" type="radio"><label for="13">Red</label>
<input id="13" value="26" name="customPrice[0][13]" type="radio"><label for="13">Black</label>

This is creating problem with most of the browsers and it will not allow users to select the field if they click on label instead of the input box.

I also saw another post on this https://forum.virtuemart.net/index.php?topic=104984.0 Someone has posted a solution but that's not quite correct.

Please check and fix this.