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
You mean
Save a "Group" template.
Like all the manufacturer's Colors in 1 template. Then apply them to whatever products they apply?
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.
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
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
It is and was never that way. afaik.
Hi Milbo,
I don't understand. What do you mean by "It is"? "and was never that way"?
Thanks,
Chuck
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 ...
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.
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
Quote from: Electrocity on October 29, 2011, 11:51:20 AM
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 :-\
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
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...
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
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.
I understand and appreciate the effort it would take to make the custom fields not be duplicated in every product. And I completely understand you are trying to get a stable version done, and I'm just adding to your stress. It's just that I have to load and maintain over 300 furniture manufactures, each with hundreds of products, and each product has over fifty leather and fabric options. That makes about 3 million options! As you can imagine, I was praying not to have all these options duplicated in thousands of products to maintain as they change over the years. I also thought Balai's offer to do the database work and the saving work in his first post would make his recommendation possible. But if not, thanks for all the great work regardless.
As far as the plugin, I wish I was talented enough to write the plugin to do this functionality, but I'm dependent on experts like you guys.
Thanks,
Chuck
@cas
Well the way I understand it to set a values list for a custom field we would need one more table to store these values with IDs, description, label, ordering ect.... then to link these values to the field you would need a relational table that would link the custom fields id to the values list table... it is true that we would only need the two more tables now that I think about it. But it would also require a significant re-write to support the new functionality... weeks at least... months probably. It might have to wait until after we get a stable release...
I always over estimate my development time though so in all reality IDK.
I once used VM for a furniture manufacture I didn't stay on to load all the products but I can understand your pain.
Cas, I have a similar situation with you. As we speak I hire a guy to hack v1.5 to be able to do this+ a lot more.
Price update based on attributes selection ( like in v2), main pic change to reflect attribute color...
If you're interested once he finish I give the link where I'll install the hack!
Hi Cristi,
When you say v1.5, are you referring to Joomla v1.5 or some VirtueMart version? I'm using Joomla v1.7.2 and the latest VirtueMart v1.9.8.RC2 M.
Thanks,
Chuck
Virtuemart version
Hi Cristi,
Too bad it's not in VM V2. But I would enjoy seeing the results when it's finished, so please send me the link with completed. If the guy does a good job, maybe he would be interested in doing it for V2.
Cheers,
Chuck
the only reason i have him work on 1.5v if because it stable and it's a very robust version. V2 its new and as with any new versions it will take months to fix all the bugs... and I need something fast for my new site.
@Cleanshooter
QuoteWell the way I understand it to set a values list for a custom field we would need one more table to store these values with IDs, description, label, ordering ect.... then to link these values to the field you would need a relational table that would link the custom fields id to the values list table... it is true that we would only need the two more tables now that I think about it. But it would also require a significant re-write to support the new functionality... weeks at least... months probably. It might have to wait until after we get a stable release...
Just keep in mind that database changes are hard to be done in next versions because those versions won't be backward compatible.
And in this case the value that comes from that change counts much more than 1 month more to the development cycle.
Hi Balii,
I hope the development team decides it's worth the effort. It will be a long time until you ever get the chance to do it right again. By the way, I discovered that Custom Fields of type Image are stored separately from the product using the Media File manager. Maybe this approach can be reused for all Custom Field types. Just a hopeful thought.
Thanks,
Chuck
Quote from: cas on November 04, 2011, 06:13:02 AM
I understand and appreciate the effort it would take to make the custom fields not be duplicated in every product. And I completely understand you are trying to get a stable version done, and I'm just adding to your stress. It's just that I have to load and maintain over 300 furniture manufactures, each with hundreds of products, and each product has over fifty leather and fabric options. That makes about 3 million options! As you can imagine, I was praying not to have all these options duplicated in thousands of products to maintain as they change over the years. I also thought Balai's offer to do the database work and the saving work in his first post would make his recommendation possible. But if not, thanks for all the great work regardless.
As far as the plugin, I wish I was talented enough to write the plugin to do this functionality, but I'm dependent on experts like you guys.
Thanks,
Chuck
CAS, I have been looking at the custom field plugins, and a lot is going to be done with these.
FOR example, You can have a "Attribute Template Set" . So, for a manufacturer that has a set of colors. You will be able to create the set in "custom fields". Then apply it to the products you want.
QuoteYou will be able to create the set in "custom fields". Then apply it to the products you want.
Is there any documentation or example with this?
Hi Banquet,
Having a "set of attributes" that can be applied to a product will definitely help with the initial loading of products & attributes, but how does this help when attributes change over time? We will still need to go into all the products one-by-one to change the duplicated attributes. But if the attribute is unique and stored once in a separate table as Balai has described in his earlier post, then all we have to do is update that one attribute and we're done. I can appreciate the effort it would take to change VM to store the attributes in a separate table, and I understand the added issue with backward compatibility, but I hope the VM team can understand the level of effort it will take for us who use VM to maintain attributes that are duplicated in all the products. In my case, it will be a maintenance nightmare because my furniture shop has thousands of products and if the hundreds of leather & fabric attributes are duplicated in all these products, I estimate there will be 3 million attributes to maintain! Bottom line, I completely understand if there just isn't time to make this change, but I'm willing to pay you guys to have this done right the first time if someone is willing to do it. Otherwise I will have to pay my data entry folks to maintain 3 million attributes forever. The new version of VM is absolutely a work of art, so why not make managing attributes just as high quality as the rest of VM. At least make it equal what osCommerce has had for many years around what they call Options & Option Values. Regardless of whether you can get this done or not, thanks for all you do!
Chuck
Quote from: balai on November 13, 2011, 16:29:53 PM
QuoteYou will be able to create the set in "custom fields". Then apply it to the products you want.
Is there any documentation or example with this?
^ Not done yet, but Its not going to be hard. You can make your own plugins. (check out one of the plugin files)
The plugins can change the way its stored, AND the way its displayed.
So, it can be stored as a comma separated string
Red,Blue, Green, Yellow, Purple,
Then the output on the front end can use the comma to know when to start a new <select>Red</select>
THEN, can pass that Text on to the cart via Text Input. (hidden)
NOW, as far as attributes that change price. I have not thought about that yet.
////SOOOOOOOOOOOO, what I am saying guys is. Dont panic.
There are going to be things you do not like and wish were different with 2.0. BUT, its WAY better than 1.1. (as long as you move to J1.7)
http://dev.virtuemart.net/projects/virtuemart/wiki/Product_Plugins
If anybody develops this plugin, please let us know.