News:

You may pay someone to create your store, or you visit our seminar and become a professional yourself with the silver certification

Main Menu

Bug in User Fields? vm_extrafield vs extra_field_1

Started by gerrit8020, October 02, 2008, 17:01:53 PM

Previous topic - Next topic

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

#1
found this in another post:

QuoteError 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

Quote from: gerrit8020 on October 02, 2008, 17:01:53 PM
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

#5
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
<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:
  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:
  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]
Visit my website at www.lowmips.com
View my newsletters Here (sign up for newsletters on the front page of my website)

tez

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

Soeren

The future of eCommerce: VirtueMart & Joomla!
http://virtuemart.net

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,



pollar

Try this:


  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.