Custom Fields functionality

[balai]

Hi

I was testing the custom fields functionality.

I think that some important improvements could be done.

Using the same values for the same custom fields in different products, i realized that the same values are created and stored again and again in the database.

For example giving the value: Red for the custom field Color in different products, is stored again and again in the db table #__virtuemart_product_customfields. This is against the database structuring rules as we have information repetition and increasing of the database table size unreasonably. Also it will render any filtering functionality really really slow

This could be an efficient solution:
Create 1 more table that stores the  virtuemart_custom_id to product_id relationship
Create 1 more table that stores the virtuemart_custom_id  to custom_price relationship
Also check if the value exist before saving it to the appropriate table.
The existing values for the custom fields could be displayed as proposals to the user while typing.

If you like i can undertake the part of the database reformation and the saving task

[PRO]

You mean

Save a "Group" template.

Like all the manufacturer's Colors in 1 template. Then apply them to whatever products they apply?

[balai]

Hi

No its not a matter of template.

I am referring to the db table #__virtuemart_product_customfields .

For example the value: Red for the custom field: Color could exist 10 times (actually unlimited times) in the same database table. In other words it is not a normalized table.
A better approach would be to have that table store the custom field values and a 2nd one that stores the relations of these values with the products.

The 2nd table would contain the value_id and the product_id which would be keys (ie. indexed) and the custom_price. In this case, products filtering would be much faster and also insertion/update/deletion anomalies could be avoided.

[cas]

Hi Balai,

Great suggestion!  I also recommend that Custom Field values be separated in different tables as you suggested.   In addition to having significantly less duplicate data, this would also make long-term maintenance much easier.   In your example, when the color Red changes someday to Dark Red, it would only require changing it in one place and not in hundreds/thousands of products.  I certainly prefer Joomla over osCommerce, but osCommerce does have an excellent approach to managing product attributes/options.  Maybe the developers of VM can take a look at osCommerce just to understand what Balai and I are saying about the best approach for separating Custom Fields into more tables to reduce the duplicate data and make long term maintenance of Custom Fields easier.  And to the developers of VM, we love you and you are doing amazing work, so please do not take my osCommerce suggestion for anything other than we want the best for VM and everyone using it.

Regards,
Chuck 

[cas]

To the VM team,

Is there any hope of this enhancement to Custom Fields being implemented?  I'm planning a very large product load with thousands of products and dozens of custom fields for each product, so I will gladly wait to load the products for this enhancement to be implemented if it's something you are considering.  The benefits of this enhancement would be significant for large shops like mine with lots of custom fields.   Thanks for considering it.   Please let me know your thoughts on implementing it. 

Thanks,
Chuck

[Milbo]

It is and was never that way. afaik.

[cas]

Hi Milbo,

I don't understand.  What do you mean by "It is"?  "and was never that way"? 

Thanks,
Chuck

[Studio 42]

HI cas,
in case of very similar customfields datas you can do your own customfield plugin.
All settings are saved in one fields and you can put all the product characteristics in one field (all are saved as a json string).

And you can do pre filled values in the custom plug in tables.

The default customfields are not here to add 20 values for each product, in this case you must do a plug in(or wait someone do it for you)

You can look for eg in the custom plugin/vmcustom/stockable.php. or in the wiki plug-in page to understand how it work.

In all case plug in are here to add flexibility and you can set it as you want and add CSS, JS, Flash ...

[balai]

Hi

I don't know if this enhancement could be done now (in RC versions) but i think that this is a better approach also for the normal (not plugin based) custom fields.

[cas]

Yes, I agree 100% with Balai.  This is much better to be done in the VM base and not via a plugin.   I really hope there is time to include in the RC version.  The benefits to everyone would be significant.

Thanks,
Chuck

[zzsser]

HI cas,
in case of very similar customfields datas you can do your own customfield plugin.
All settings are saved in one fields and you can put all the product characteristics in one field (all are saved as a json string).

And you can do pre filled values in the custom plug in tables.

The default customfields are not here to add 20 values for each product, in this case you must do a plug in(or wait someone do it for you)

You can look for eg in the custom plugin/vmcustom/stockable.php. or in the wiki plug-in page to understand how it work.

In all case plug in are here to add flexibility and you can set it as you want and add CSS, JS, Flash ...

Does anybody knows how to write that kind of plugin ? I've no idea on how to adapt stockable.php to create a plugin that could simplify the adding of a colour field (with 20 colours) for hunderds of products 

[cas]

Hi zzsser,

You are a perfect example why each of us shouldn't be struggling to create a custom plugin, when Balai offered to implement the perfect solution in the base VM.  I just hope it can get done.   It would make VM the perfect solution! 

Regards,
Chuck   

[Cleanshooter]

It would be a great idea to add to the base but since each custom field would need both a relation table and a table containing the custom fields there would need to be significant additions made to the customfield model which allowed the user to pre-assign custom values.   Plus the script to create both tables based on the custom fields and the .php files to control the tables would need to be generated on the fly as well.  I don't think that the the vmtable, vmtabledata or vmtablexarray classes could support the functionality necessary as is.  Since it would improving the way the custom fields are handled it would make more sense ot me if it were in the base and not a plug-in...

Bottom line this would be a big upgrade and require a lot of work.  I agree that it's a great idea for customization (especially for larger shops) but it would take a while...

[cas]

Hi Cleanshooter,

Excellent post.  Just one question... when you say "each" custom field would need 2 new tables, I'm not sure I follow that logic.  Currently there is one custom-field master table and one product-custom-field table, so wouldn't it just require adding 2 new tables total?  I agree the use case changes to manage custom fields since the values would be predefined outside the products and then just attached to the products, rather than duplicated in every product as it's currently done.  But this is how osCommerce options have worked for a long time, so hopefully VM can catch up.  And I'm not trying to minimize the effort, but the benefits would be significant to everyone, so let's hope a miracle occurs!

Regards,
Chuck

[Studio 42]

why add alll as defaut. you want a monster ?
Is as you said "PLz joomla with all templates plugin and modules and component in one package "

Second how you wan't resolve all problem ? always extend defaut code ?
I think in this case we have a stable release in 2 years or not ?

IN feature it's possible some things are added to the core, but not for next weeks.

You can create your own table, to improve the plugin, and why not add your idea as a plugin.