Bug in User Fields? vm_extrafield vs extra_field_1

[gerrit8020]

When i tried to use the vm_extrafield all kinds of errors occured (orders disappear, purchase order doesn't show the information, confirmation email is send to is empty, not able to update account info).

Note: the other extra fields in the manage user fielfs list are named:
extra_field_2
extra_field_3
extra_field_4
extra_field_5

It seems that there is no related column in the mysql database. There is a column extra_field_1 though...

[gerrit8020]

found this in another post:

Error Message:
--------------
Unknown column 'vm_extrafield' in 'field list' SQL=INSERT INTO `jos_vm_user_info` ...
--------------

Temporary Fix: Add Field 'vm_extrafield' in #__vm_user_info.

I have not seen, but suspect there is a bug in the installation script.

Greetings
Reinhard

[ruigato]

When i tried to use the vm_extrafield all kinds of errors occured (orders disappear, purchase order doesn't show the information, confirmation email is send to is empty, not able to update account info).

samething hapened wen i added a extrafield. Just notice after some days without sales.. I´m using VM 1.1.3 so this wasnt fixed n th new relase..



Note: the other extra fields in the manage user fielfs list are named:
extra_field_2
extra_field_3
extra_field_4
extra_field_5

It seems that there is no related column in the mysql database. There is a column extra_field_1 though...

[Anthony C.]

Is this a bug? or the feature has been removed from VM 1.1?

[Anthony C.]

haha.. I am sorry.. my bad..   lol i am a noobie ^_^

for those are like me, please go to
Admin--> Manage User Fields --> publish the fields you need

^_^ Cheers

Anthony

[lowmips]

A client of mine has also run into this bug. Joomla 1.5, VM 1.1.3.

Basically, if you try to edit any of these fields in the "Manage User Fields" admin page, the "Field Name" is renamed to "vm_extrafield", and the input box will not allow you to rename it:
extra_field_1
extra_field_2
extra_field_3
extra_field_4
extra_field_5

Once you click "Save", the field is renamed in the database table jos_vm_userfield.  However, the jos_vm_user_info table retains the old field names, and any inserts using the new field names fail!  This leads to a looping behavior when a user attempts to check out for the first time.  The "Customer Information" screen is shown and asks for all published user fields (Billing Info). However when the user clicks "Submit", they are redirected right back to the same page.


In order to fix any renamed fields, go into the jos_vm_userfield table and manually rename them from "vm_extrafield" back to their original "extra_field_X" name.

I have not traced down where the bug is occurring exactly, but will post here if I do.

*Update*

admin.user_field_form.php
around line 136

Code Select Expand

<td align="left"  width="20%"><input onchange="prep4SQL(this);" type="text" name="name" mosReq=1 mosLabel="Name" class="inputbox" value="<?php $db->sp('name'); ?>" <?php if($db->f('sys')) echo 'readonly="readonly"' ?> /></td>

The prep4SQL function is defined further down in the file:

Code Select Expand

  function prep4SQL(o){
if(o.value!='') {
o.value=o.value.replace('vm_','');
    o.value='vm_' + o.value.replace(/[^a-zA-Z]+/g,'');
}
  }

This function prepends the name with vm_ and replaces any non-alphabetic characters with null. Therefore extra_field_1 becomes:
vm_ + extra(null)field(null)(null)
vm_extrafield

This function is the culprit, but I have yet worked out why only some fields are changed and others are not.

*Update 2*

I've changed the function to this:

Code Select Expand

  function prep4SQL(o){
  alert("o.value is " + o.value);
  /*
if(o.value!='') {
o.value=o.value.replace('vm_','');
    o.value='vm_' + o.value.replace(/[^a-zA-Z]+/g,'');
}*/
  }

The strange thing is that the onchange() event is not being fired every time.  I've clicked through all available fields and only a few fire the event.

*Update 3*

I've poked around in some javascript help forums, and they generally recommend using the onClick method instead of onchange.  They state the onchange method is fickle/buggy.  This may explain why only certain fields trigger the event.

If the event fired for every field we try to edit, this bug would have reared its head earlier. 

I think the prep4SQL function needs a revamp. Attached is an edited version of the file, with the prep4SQL code commented out.  It will no longer sanitize any field names, so be careful when creating new ones.

-Reggie


[attachment cleanup by admin]

[tez]

thanks, helped me a lot! this needs to be in next version.

[Soeren]

Hi,
see Task #2631 - prep4SQL renames field names . It's fixed for VM 1.1.4.

[derebo]

hi soeren,

i think you're doing a great jobs. no single complain. i've updated to 1.1.4 and the bug is still there. field name cannot be edited and it will become vm_extra_field_1 after saving. so i cannot rename that field name to my liking.

one question: is it possible to have the field be a memo box instead of character-defined field?

soeren or anyone, i'm willing to help so if you want some betatesting just say.

greetings,

[aravot]

What doesn't work, I just tried it and it works.

[pollar]

Try this:

Code Select Expand


  function prep4SQL(o){
if(o.value!='') {
o.value=o.value.replace('vm_','');
if (o.value.substring(0,11) != 'extra_field') {
    o.value='vm_' + o.value.replace(/[\W]+/g,'');
} else {
o.value=o.value.replace(/[\W]+/g,'');
}
}
  }


[Anthony C.]

I've tried in in 1.1.4. The problem is still there.

That happens after I clicked on the save button.

Anthony

[lord_alan]

I can confirm this bug is still present.

A new install with VM-1.1.4 on Joomla! 1.5.15. "extra_field_1" became vm_extra_field_1" and caused the loop on checkout.

We have the system configured for No Account Creation.

[Jesper Dinesen]

Im not sure if this bug has been fixed in 1.1.5 or not, but Im using 1.1.4, and a quick fix is to delete all the existing user fields. When they get recreated they seem to be created with right name in both tables, and this works.

[z-analysts]

I'm using 1.1.5 and the bug is still there. I want to thank Jesper Dinesen for his quick fix! It saved me from giving up on user fields.