After updating from 2.0.14 to 2.0.15b, my overrides for the product editing in backend doesn´t work anymore.
VM allways fetches the default files, not those in my backend template.
I have already doublechecked misstyes a.s.o.
All other overrides in backend and in frontend still works fine.
Please help!
friendly bump
anyone?
Hello,
2.0.15b is a test version not a stable one ... try 2.0.15c
Hopefully you didn't upgrade a live site.
Regards
I did so after some testings - but I simply renamed the original php-files to make VM using my overrides - just as a workarround...
Just a post how you could make template overrides ...
http://forum.virtuemart.net/index.php?topic=110977.msg372400#msg372400
Use firebug to examine you site code and css styling: https://forum.virtuemart.net/index.php?topic=102850.0
Template Overrides:
Creating Template overrides: https://forum.virtuemart.net/index.php?topic=98505.0
Template System: https://dev.virtuemart.net/projects/virtuemart/wiki/Hints_for_the_use_of_the_template_system
Regards
Thanks bytelord.
But I´m using overrides already sind VM 2.0.4 :) and it was working since updating to 2.0.15x!
Just renaming (or deleting) the original files makes my overrides working - so, there must be another reason why the overides are not aknowledged.
overrides on backend editing? Missed that ... what exactly are you trying to do?
I´m overriding product_edit_information.php and product_edit_dimensions.php.
Originally, these files are located in /administrator/components/com_virtuemart/views/product/tmpl/.
The overrides are in /administrator/templates/bluestork/html/com_virtuemart/product/.
But again, what exactly you are trying todo?
I´m misusing some fields for other purposes as they are originally used for (f.ex.for Vendor article no, EAN...).
The reason is simply, that I´m using Third-party-tools, which cannot properly handle custom fields.
So for example, I want to have the field "product_box" on the product-information-side and use it for EAN.
Custom fields is not an option for this?
No it isn´t - 2 reasons:
- you have to add custom fields each time, you add a new product: this isn´t very intuitive for the enduser when managing a larger shop
- custom fields are located on the last tab page. EAN and SKU should be on the first tab
- I´m using third-party-tools which cannot handle custom fields at the moment
Learn to use parents as patterns, then you dont have this problem. Your customers should just clone a child and thats it. Very handy to use. SKU is on the first page.
Using an EAN is a sku. EAN is just a normed way of SKU. Using both at once is imho wrong warehouse setup. But due the sloopiness of merchants and manufacturers it may be necessary.
But to answer the main question: We did not change anything there, so the overrides should still work as before.
Quote from: Milbo on December 14, 2012, 13:10:07 PM
Learn to use parents as patterns, then you dont have this problem. Your customers should just clone a child and thats it. Very handy to use.
Thanks Milbo, but we are using parents/childs! But that doesn´t solve our problems.
QuoteSKU is on the first page.
Using an EAN is a sku. EAN is just a normed way of SKU. Using both at once is imho wrong warehouse setup. But due the sloopiness of merchants and manufacturers it may be necessary.
If you say, EAN is a sku, then we do need 3 different sku:
- our own sku
- manufacturers sku
- EAN
Manufacturers sku and EAN are needed both, if you want to offer your products via shopping-portals like billiger.de, idealo.de, guenstiger.de a.s.o.
In this case I would write a customfield plugin, add it to my pattern. the plugin is using its own table and using the vm SKU to xref the others.