hi,
is there a reason to have a 255 characters limit in the fields "Default" on custom fields?
Next VM versions will free up this limit?
Some infos and request here:
http://forum.virtuemart.net/index.php?topic=102843.0
Regards
p.s. if this is not the request area, where can I post requests?
the custom_value is customfield_value and is set to "text" by default for vm3
I just noticed that I did only increased the size of field in the product_customfields, but not the customfields. I set 8k now, like in the product_customfields and in vm3 20k in customs and text in product customfields ( the custom just sets the standard).
if someone needs more, there is a plugin internal table which can be defined by yourself.
Thank you Milbo! :)
p.s. is there a safe way to increase the size in VM 2.6.x?
I changed it already, it will be in the next vm2.6.8. But I am not sure when we release it. There are only some minor fixes. Maybe there is a release in 1-2 weeks. If you want it directly, please compensate our time http://extensions.virtuemart.net/support/virtuemart-supporter-membership-detail
hi, I am using virtuemart 3.0.12 and I created a custom field. I put text into the editor but unfortunately is cut. how have you resolved? many thanks in advance
clearly installed vm3
table #_virtuemart_customs
(http://image.prntscr.com/image/63c8ab40a2224c7a95f271204eca07b2.png)
table #_virtuemart_product_customfields
(http://image.prntscr.com/image/482433ac94354bae9556cb04e69940d4.png)
Quote from: Milbo on June 23, 2014, 23:41:20 PM
if someone needs more, there is a plugin internal table which can be defined by yourself.
Which plugin do you mean? Where i can find them?
So, if i change field type to text - it is safe for update?
I changed the table field type to "text"
The new text value of the custom field (approx 7000 chars) was saved without cropping.
I updated virtuemart from 3.2.0 to 3.2.1, and saw:
AlterTable CHANGE fp1hy_virtuemart_product_customfields.customfield_value
And got the following in the database:
Customfield_value varchar (2500)
Accordingly, the problem of updating is not solved.
What to do?
The problem appears for people who use the customfield "texteditor"?
I wonder why someone wants to write so much data there. The field is mean for small data, like keywords, tags, attributes, but not whole descriptions. I even would like to downsize it (better for performance). When the problem comes due the textfield, then I should rewrite the textfield to use the params to keep the description. Because the params field is set to text and has "unlimited" space.
Hi, Milbo!
In most cases, a large field size is required to store characteristics in a table format.
In order to display tabs on the product page:
Description, specs, reviews, etc.
Processing all specification values as separate units is often impossible - they are too different and too many. Our suppliers do not offer structured data for automatic processing.
We have to copy descriptions and characteristics from their sites manually.
All this is because a large slow text field is cheaper than a lot of fast little ones.
The thing is, I could rewrite the customfield with the editor, to store the text in a param. It would also make more sense for this customfield, actually. for me it was just a string customfield, without any "string logic" (variants and so), but with editor.
hi.
im not sure if i understand well. you increased the limit for field type textarea but not for editor?
if yes.. why? i need to display long infos about products (specification tables, files for download etc. ) in the custom field editor.. and its always cut.
why we cant do this?
in few stores i changed the limit in the db but its not a real solution as update override it..
please make some update safe solution. increase the editor limit in default. or let us to choose a limit in admin.
im waiting to solve this issue long time..
thanks a lot
jankoo
I think it's about that a $product contains a huge amount of data
Try to make a var_dump($product) and see what's in it.
If for a detailed page this is not so important, then imagine how large fields will affect the output as a product category?
After that, most people also start screaming about why virtuemart is so slow ...
But, i understand you. And i have same goal and problems, as you..
Please test vm3.2.3
http://forum.virtuemart.net/index.php?topic=137816.0
http://dev.virtuemart.net/projects/virtuemart/files for experienced users.
Once VM3.2.4 is finalised that will replace 3.2.2 in the downloads section as the "official" stable version.
Quote from: Milbo on May 24, 2017, 16:47:27 PM
Please test vm3.2.3
I updated now to 3.2.3 but there is the same limit on default product description, is this limit still there? I thought it will be removed...
There is a hidden config, dbpsdescsize - https://docs.virtuemart.net/manual/general-concepts/206-hidden-configurations.html - I thought that was for increasing the table size (I have not tested it), which is very likely to impact on page speed, so is there for experienced users.
Quote from: jenkinhill on July 19, 2017, 13:34:00 PM
There is a hidden config, dbpsdescsize - https://docs.virtuemart.net/manual/general-concepts/206-hidden-configurations.html - I thought that was for increasing the table size (I have not tested it), which is very likely to impact on page speed, so is there for experienced users.
Many thanks friend :)
In /administrator/components/com_virtuemart/helpers/tableupdater.php I fond following code:
$fields['product_desc'] = 'varchar('.VmConfig::get('dbpdescsize',18400).') '.$linedefault;
Would it be danger if I make there a corehack to:
$fields['product_desc'] = 'TEXT '.$linedefault;
Or can I override tableupdater.php without to losing data after updates?
hidden config dblayoutstrict=0 does the same for you