Custom fields not working in 2.9.6

[sealion]

I am having problems getting the custom fields to work in Virtuemart 2.9.6, for example:-

• create a new custom field of any type, even a simple string
• then try to attach it to a product, the jquery select box does not work properly in creating the new custom field
• if you try selecting a custom field type anyway then save the product, no custom field is saved

,

Also if you try to create a custom field of the plugin type, this cannot be done properly because the section to specify the plugin parameters is not created once the plugin is selected.

I think I know why you are having these problems, in the table virtuemart_product_customfields you renamed three of the fields in VM 2.9:-
custom_value => customfield_value
custom_price => customfield_price
custom_params => customfield_params

I do get why you did this, I guess it was because these field names conflicted with the same field names for different variables in the virtuemart_customs table, so possibly it was a good idea to change them, however it has left you with some problems where there seem to be quite a few places in the code where this change has not been picked up. I am attaching a file where I have listed the problems that I can find. I have to say that I have not tested these, it is based on my understanding (such as it is) of how the relevant code works. Also the list is probably not exhaustive, there are some parts of the code, particularly to do with the custom_params, where my knowledge is not sufficient to suggest any changes.


[attachment cleanup by admin]

[Milbo]

Thank you for this list. First I thought, what the heck you wanna tell me. The changes are the big difference between vm2 and vm3. There are more than 200 locations in the code.

But except your suggested change in "file components/com_virtuemart/views/category/view.html.php line 347", you are right. The sql in function getSearchCustom is outdated and just wrong. The stockable wont be updated. We suggest to use the dynamic childs instead.

But I think you just had bad luck. Only one type of the customs was not working and you tried that one. You may read here http://docs.virtuemart.net/tutorials/development/175-code-adjustments-for-virtuemart-3.html and help to complete it.

[sealion]

Thanks for the link, it does make things clearer. I was just trying to help with the list, not be alarming, I am keen for it all to be working.

[Milbo]

I am happy for your testing. contact me in skype to get an updated version. PLeease :-)

[sealion]

Max, thanks for the updated version. I have been doing some testing with the custom fields, I have found some problems. I can probably debug  some of these for you, but it would help to know what is supposed to be working.

You say you are not supporting the stockable variants plugin, what about the other custom plugins, the text input and the specification plugin? Neither of these works at the moment.

You say to use the child variant field instead of the stockable plugin. I have been experimenting with this but it does lead to some problems with stock control. If the parent product is not orderable (so has zero stock) and you are using stock control then the only way to get it to display is to set 'Do not Display Product, if child products also out of stock'. But then if you have a child variant that is out of stock it still displays, and you can still add it to the cart, although you do get a warning as well that the product is out of stock. I think it is possible to solve this problem though, it just requires getting the logic right. However it might be an improvement to make the stock handling choice part of the generic cart variant field options, because for some products you might want to make the parent orderable and use stock control only with the parent If the only way to set this is in the Virtuemart configuration it is a bit limiting.

I think it is a good idea to stop the stockable variants plugin, I always found it very confusing to use, the child variant field is easier to understand. But I think some people will complain all the same, there are definitely sites out there that use it, for them it will become impossible to update.

Instead of the cart variant field type I see that you are using just the string field type with a custom price. This works now, except that the custom price is not saved when you edit the field. I am sure this can be debugged.

[Milbo]

The stockable variant and the generic child variants are exchangeable against each other. We can enhance the dynamic child variant with parameters very easy. Wont be a big problem to add your stocking idea.

The textinput plugin was working for me fine. Hmm I retest it. btw, please be sure that you tested the last version uploaded this evening http://dev.virtuemart.net/attachments/download/758/com_virtuemart.2.9.7_extract_first.zip

edit: I just felt myself in the trap that the plugin must have "is input" and "is cart attribute" checked. We should maybe move the trigger plgVmOnStoreInstallPluginTable over $table->bindChecknStore($data), so that we  can do this with the plugin to keep unnecessary support low.

[sealion]

No, I did test the text input with cart attribute and cart input checked. I should have been clearer, the problem was that in the front end, when the product is viewed, nothing is displayed. Solution is, in plugins/vmcustom/textinput/textinput.php line 61 should be

Code Select Expand

function plgVmOnDisplayProductFEVM3(&$product,&$group) {


not

Code Select Expand

function plgVmOnDisplayProductFE(&$product,&$group) {


When you fix that the text input plugin seems to do what it should

I mentioned that the custom prices were not being saved, eg when using a string field as a cart variant, this is because of this:

file administrator/components/com_virtuemart/tables/product_customfields.php line 71

      

Code Select Expand

if(!empty($this->custom_price)){

should be
      

Code Select Expand

if(!empty($this->customfield_price)){

[Milbo]

yepp, thanks, I sent you already yesterday a fixed version. Atm I am thinking about how we can use the new and old triggers in the same plugin, but with the same name. Hmm....

lol damn I did it right in the function itself, but not the test to check if the function must be done. Thank you.

[sealion]

Sorry I have not been in touch recently.

There is one thing I noticed in 2.9.7 which still seems to be in 2.9.8, for the date custom field type, when you view it in the front end the date drop-down selector does not work. This is due to the JQuery ui which defines the datepicker not being loaded in the front end, to fix it you just need to add a call to vmJsApi::js ('jquery-ui', FALSE, '', TRUE); in the jDate method in administrator/components/com_virtuemart/helpers/vmjsapi.php.

I will have a bit more time now to do some testing, I will do some testing on the custom plugins in VM 2.9.8 now, and will continue to post things as I find them.

[sealion]

components/com_virtuemart/views/product_details/tmpl/default.php line 232

Code Select Expand

echo shopFunctionsF::renderVmSubLayout('customfields',array('product'=>$this->product,'position'=>'ontop'));


should be

Code Select Expand

echo shopFunctionsF::renderVmSubLayout('customfields',array('product'=>$this->product,'position'=>'onbottom'));


[Milbo]

I have now

Code Select Expand


    // Show child categories
    if (VmConfig::get('showCategory', 1)) {
echo $this->loadTemplate('showcategory');
    }
echo shopFunctionsF::renderVmSubLayout('customfields',array('product'=>$this->product,'position'=>'onbottom'));
echo shopFunctionsF::renderVmSubLayout('customfields',array('product'=>$this->product,'position'=>'related_products','class'=> 'product-related-products'));
echo shopFunctionsF::renderVmSubLayout('customfields',array('product'=>$this->product,'position'=>'related_categories','class'=> 'product-related-categories'));

I wonder myself, maybe showcategory template should be the last line... maybe it should be

Code Select Expand


echo shopFunctionsF::renderVmSubLayout('customfields',array('product'=>$this->product,'position'=>'related_categories','class'=> 'product-related-categories'));
echo shopFunctionsF::renderVmSubLayout('customfields',array('product'=>$this->product,'position'=>'related_products','class'=> 'product-related-products'));
echo shopFunctionsF::renderVmSubLayout('customfields',array('product'=>$this->product,'position'=>'onbottom'));
// Show child categories
if (VmConfig::get('showCategory', 1)) {
echo $this->loadTemplate('showcategory');
}

[Milbo]

Why?

If the position is not specified, the output of related products is in the position of "normal". Here is an example: http://store25.eyemotion.ru/index.php?option=com_virtuemart&view=productdetails&virtuemart_product_id=1&virtuemart_category_id=1&Itemid=121

Yepp, seems I removed the fallback. So the updater needs a check to add related_products/related_categories to the positions.

[Milbo]

I think also now we should stick with onbot and not onbottom.

We cannot just update it, if people use an override.

[sealion]

Yes, onbot is better, I had forgotten about this.

[sealion]

A couple of minor points, in plugins/vmcustom/textinput/textinput.xml

line 23

Code Select Expand

            <field type="vmjpluginwarning"/>


should be

Code Select Expand

            <field type="vmjpluginwarning" addfieldpath="/administrator/components/com_virtuemart/fields"/>


At the moment the plugin warning is not displayed.

Also in the lines

Code Select Expand

    <updateservers>
        <!-- Note: No spaces or linebreaks allowed between the server tags -->
        <server type="extension" name="VirtueMart3 plg_vmcustom_textinput Update Site"><![CDATA[http://virtuemart.net/releases/vm3/plg_vmcustom_textinput_update.xml]]></server>
    </updateservers>


If you actually go to the URL http://virtuemart.net/releases/vm3/plg_vmcustom_textinput_update.xml the information there seems to be for the paypal plugin