Small issue with mysql table field sizes (Feature suggestion)

[Krx]

Hi

One of my client needs to have several Custom Fields: Drop down list to choose between 50-100 values.
Because custom_value field in virtuemart_customs table can hold 256 chars only,
I've changed this field into mediumtext so that it can hold more values.

Since I modified that, Virtuemart upgraded few times, and several times that field reverted to default char 255,
which trimmed excess of data, and I needed to redo modifications.

Because it's very likely that some more Virtuemart users may need to have more space in that field,
I'm proposing that you change that field into medium text by default.

To accompany previous suggestion, in Virtuemart backend in Custom Field manager,
"Default" inputbox could be changed into textarea, which would make editing much easier.

administrator/components/com_virtuemart/models/customfields.php, approx. line 290:
change
$html .= VmHTML::row ('input', 'COM_VIRTUEMART_DEFAULT', 'custom_value', $datas->custom_value);
into
$html .= VmHTML::row ('textarea', 'COM_VIRTUEMART_DEFAULT', 'custom_value', $datas->custom_value);

What do you think?

Regards

[Milbo]

I changed it to textarea for 2.1.

I agree in general also with the other point. But we just redesign the whole customs and customfields stuff. For example the line you mentioned is now in custom.php and not customfield.php anylonger.

Even the engine is heavily changed simplified, faster and easier to work with, it is not changed from the user point of view, except that some restrictions are removed. For example you can list now several products with their own customfields, which are always the same custom (for child, variant stuff). You can also just add more than one textinput field to a product without creating two customs for it.

But now I want to rework the selection and input possibilities for the user. There are so many redundant or almost the same options. For example, "is cart attribute" and "Cart variant". Or "is list". We dont understand ourself, why we have for example boolean. A boolean is for the user a list with two options. A list is not the way I want to represent it and so on.

I think we need as input possibility for the product editor
String, Media, Date, List

We can have a list of something, therefore the idea to handle it as attribute, but atm it is not intuitiv. You can select contra productiv options. So we need to redesign the parameters/options of a custom to be more intuitiv and easier to use.

So we should have a list for String, Media, Date, Group, and Plugins

All of this should have the attributes
- cart attribute, means we see it in the cart and it is stored in the order
- fixed list/BE list, means a list for the product editor, to select a variable (for example, artists, default sizes, and so on)
- variable list/FE list, means a list which is is different for most products and which is displayed as list in the FE
- only admin
- hidden

At the moment, the difference between fixed list and variable list is done somehow by using the Cart variant or seleting the "is cart attribute" thing. Usually a choice done by the shopper must be stored. On the other hand, it makes sense to have some attributes automatically added to the product in the cart, for example the size and the manufacturer of a screen. Therefore the backend list must have also the option to be a cart attribute, or?

and before people have great ideas. Consider that there must be a possibility that if people upgrade, that we migrate the old stuff to the new system without missing any opportunity we have already now.

PS: To come back to the feature request to rise the table size. The idea is also to give the BE lists an own table, like the FE lists have already.

[Krx]

Hi MIlbo

Wow, that was huge reply 
I'm glad to see/hear where Virtuemart is going and that you listen users suggestions.

I'm also welcoming new feature which is available with latest 2.0.12f :

Product cloning is great time saver when adding a lot of similar products into shop.
If product contains a lot of Custom Fields assigned, these gets cloned as we
ll.
Previously there was a catch: Custom Fields for cloned product weren't editable in a way to simply click into already assigned Custom Field and change its value into more appropriate one. Instead, specific custom field option needed to be removed from that article and to be assigned again, which consumed time for product defining.

In latest VM 2.0.12f I can see that cloned product retains drop down lists in already assigned Custom Fields. So shop editor can simply just select new value for that Custom Field, instead of deleting it, re-assigning it and selecting new value.
This saves a lot of clicking.

Why am I talking so much about custom fields?
Because I'm considering em very important for all shop owners where shop contains a lot of articles with many variants.
Every bigger shop needs good searching system, which is solved by using VM filtering modules where visitors can filter products by category, price, manufacturers AND custom fields.

What could be improved even further?
In many cases majority of products always contains certain Custom Fields.
So to save time even more, Custom Field editor could be enhanced by adding check box labeled "Always include". When checked, each newly created product would already contain this Custom Field.

What you suggested in 2nd part of your reply are also great suggestions.

Consider that there must be a possibility that if people upgrade, that we migrate the old stuff to the new system without missing any opportunity we have already now.

Well, that is always an issue. Maybe it will be easier to retain VM upgrade-ability if new features are introduced gradually.

Another suggestion.

Scenario: Many VM users doesn't upgrade as soon as upgrade is available. So they skip few versions.
Finally, they upgrade into latest version and BAM - problems everywhere. Hair is being pulled, and moderators are swimming in flooded forums. Screaming everywhere.

Why is that happening?
Let's say that upgrade from v.10.1 to v.10.2 of something is safe because no major things are changed. 10.2 to 10.3 is safe. 10.4 as well. Still no major thing are changed so it's safe to upgrade even from 10.1 into 10.4.
BUT - Version 10.5 brings some major (database) changes. When updater is programmed, Developer is considering changes from 10.4 and still from 10.1.
OK, so developing is going even further. 10.6 to 10.9 - still minor changes. 10.10 again brings major changes. At this point it's becoming really hard or impossible to retain bug free upgrade-ability from 10.1 into 10.10.
Yeah sticky forum post is made, but many users visits forums only when problem occurs, Backup isn't created, screaming and pointing fingers rises.

So, how to prevent this issue before happening?
You could involve some kind of upgrade breaking points where breaking points are major changes.
So if upgrade script detects that user wants to upgrade from 10.1 to 10.5 - it proceeds regularly.
But if upgrade script  detects attempt to upgrade from 10.1 into 10.11 - it alerts user and advises them to upgrade into 10.5 1st, only then into 10.11.

This could prevent problem before it happens.

Regards