Error saving a Custom Field when writing in Greek - future request FIXED

Started by Digi-web, October 22, 2018, 09:16:19 AM

Previous topic - Next topic

Digi-web

Hello,

When writing in Greek characters i get this error:
With English characters  new custom field is saved successfully (tested with text field).
vmError: TableUserfields Name in record is missing! Can't save the record with no Name.
failed

See also SEO in Joomla settings.

Virtuemart New installation with New jooomla on WAMP php 7.2.11 and 7.0.26.
Joomla 3.8.13
VirtueMart 3.4.2
Custom Joomla - Virtuemart Development and Templates
Website: http://www.digi-web.gr

Digi-web

Ah Silly me... Text field values are of course mandatory in english since they are used for php values ...
Dont we have any function to convert these into English like SEF perhaps? it would be nice to have...
Custom Joomla - Virtuemart Development and Templates
Website: http://www.digi-web.gr

Milbo

Do you mean the name of the userfields? /administrator/index.php?option=com_virtuemart&view=userfields

We just talked today about similar things. The name must be chosen carefully, else you may get in trouble with your db. But not any used db has that restrictions. Newer mysql or mariadb may able to handle it. For example I tested to create a userfields with ᎁ and it worked. So it should also work to create a userfield with greece characters.
Should I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

Digi-web

Hello,
yes this url is exactly what i mean.

I think in live server it works with Mariadb but in wamp it wont... Anyway it would be nice to have some kind of conversion so not to spend time to figure it out ;)
Good to know you have these things in mind, keep up the good work guys :)
Custom Joomla - Virtuemart Development and Templates
Website: http://www.digi-web.gr

Milbo

I could add an automatic transliterate like for the slugs, but ... newer dbs are able to handle it and will be in future. So I dont see a real point to add this to for the old dbs. We did not need that in vm1 or vm2, or vm3.0 when we really had this problem. It almost never appeared, because people knew intuitiv, that it is better to use ASCII here. For example in my case, I grew up with C64 and PC286, it took me years to use normal ä,ü, for filenames and not the ae,ue instead.

So it isnt a problem anylonger actually. On the other hand, it makes synchronisations with a CRM a lot easier. When the CRM expects Address and not address, it can be simply renamed and the export of the table fits directly.
Should I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

Digi-web

Quote from: Milbo on October 24, 2018, 09:30:23 AM
I could add an automatic transliterate like for the slugs, but ... newer dbs are able to handle it and will be in future. So I dont see a real point to add this to for the old dbs. We did not need that in vm1 or vm2, or vm3.0 when we really had this problem. It almost never appeared, because people knew intuitiv, that it is better to use ASCII here. For example in my case, I grew up with C64 and PC286, it took me years to use normal ä,ü, for filenames and not the ae,ue instead.

So it isnt a problem anylonger actually. On the other hand, it makes synchronisations with a CRM a lot easier. When the CRM expects Address and not address, it can be simply renamed and the export of the table fits directly.
My thought initially was to add a transliteration as you said... The end user or even an experienced (many times thought full or tired) developer / admin cannot know what the compatibilites are and expect this to work out of the box :) So if you have time at some point it would be nice to have.

Thank you Milbo!
Custom Joomla - Virtuemart Development and Templates
Website: http://www.digi-web.gr