Terragg

The form.tpl seems to be overridden in certain areas with the file: [...]/template/controllers/orders/helpers/view/view.tpl The table headings are controlled there. HTH,

I haven't done much work with category images, but since category images are hard-coded to the category's id ( tehy should be in [store_directory]/img/c/ or where ever your store's _PS_CAT_IMG_DIR_ is pointing ) either the save form generated by AdminCategoryController is telling your store to remove them, or the id_category is changing. I would definitely focus on the form. HTH,

PrestaShop expects that your object will have a unique integer identifier that defines it from other objects of its type. The internals try to cache the object itself so it doesn't have to spend resources in rebuilding an existing object. With nothing else to go on, maybe using a small random number as the $id in your constructor... Posting your MyClass::__construct() method could help in understanding what's going on... EDIT: The explicitSelect flag limits the amount of data returned by the AdminController::getList(). See line 193 and 2070 of AdminController (PS v1.5.2) for the nitty-gritty details.

Take a look at the Image::getExistingImgPath(). You can use that as sort of a base for making your function. It builds a file path and then runs a file_exists()on it, much like what you're trying to do. HTH,

Since you're just looking up things in the product_attribute_image by the id_product_attribute column, a simple left join should get you what you need. Look for the pai aliases in the updated code chunk below. 'SELECT ag.`id_attribute_group`, ag.`is_color_group`, agl.`name` AS group_name, agl.`public_name` AS public_group_name, a.`id_attribute`, al.`name` AS attribute_name, a.`color` AS attribute_color, pai.id_image AS attribute_color_image, pa.* FROM `'._DB_PREFIX_.'product_attribute` pa LEFT JOIN `'._DB_PREFIX_.'product_attribute_combination` pac ON pac.`id_product_attribute` = pa.`id_product_attribute` LEFT JOIN `'._DB_PREFIX_.'product_attribute_image` AS pai ON pai.`id_product_attribute` = pa.`id_product_attribute` LEFT JOIN `'._DB_PREFIX_.'attribute` a ON a.`id_attribute` = pac.`id_attribute` LEFT JOIN `'._DB_PREFIX_.'attribute_group` ag ON ag.`id_attribute_group` = a.`id_attribute_group` LEFT JOIN `'._DB_PREFIX_.'attribute_lang` al ON a.`id_attribute` = al.`id_attribute` LEFT JOIN `'._DB_PREFIX_.'attribute_group_lang` agl ON ag.`id_attribute_group` = agl.`id_attribute_group` WHERE pa.`id_product` = ' That should make the image_id (if it's available) accessible through $rowattr['attribute_color_image'] in your foreach loop. There's nothing special about the name attribute_color_image, so changing it won't break anything. HTH,

Add the column to the category table as well. Think of any *_shop table as holding a 'shop specific' version of the data that overrides any data in the main table. HTH,

(Assuming PrestaShop 1.5+) You will need to override the AdminOrderController templates to display the data and override the AdminOrderController to get the data to display. Getting the new data feild (one possibility of many): Override AdminOrderController::renderView to snag the warehouse data and add the 'location' data on a per-product basis. I think the foreach loop right under Warehouse::getWarehousesByProductId(...) provides access to the 3 things to get the location id_product, id_product_attribute, and id_warehouse. Use those id's to grab the data point from WarehouseProductLocation::getProductLocation($id_product, $id_product_attribute, $id_warehouse) and store it in the $products array. You may need to store it in a temporary array and find a way to insert it into the $products array if that array isn't keyed by product id. ProTip: Don't forget to end the override with: return AdminController::renderView(); as calling parent::renderView() will not get you the results you expect. As for displaying the new data feild: Copy: admin/themes/default/template/controllers/orders/_product_line.tpl admin/themes/default/template/controllers/orders/form.tpl admin/themes/default/template/controllers/orders/helpers/views/view.tpl to the BO template override folder override/controllers/admin/template/orders/ Add the new column for 'location' field to override/controllers/admin/template/_product_line.tpl Make sure that the column headers/footers in override/controllers/admin/template/orders/form.tpl and /helpers/views/view.tpl match the updated columns in the overridden product_line.tpl file. You'll also need to get the view.tpl file to use the overridden files instead of the default files. This isn't an exhaustive how-to, but it should get you pointed in the right direction. Hope this helps, PS: edits are in red.

My immediate thoughts are: Make sure you can actually see changes that you make directly to the database, and not just the default values. Make sure that you have a variable defined in your Category override to hold the value of the field. PrestaShop uses the object to update the database, if it's not in the object PS doesn't save it. Double check that when you define the extra column in the override's $definition['fields'] array, you make sure to use 'shop' => true after defining the type of column. PrestaShop usually does that right thing after all the definitions are taken care of. HTH,

muhsinap, Try looking at: StockAvailable::getQuantityAvailableByProduct() The classes that handle all stock-related functions are in [your_store]/classes/stock/ . Know them, love them. HTH,

You might consider doing some 'adjustment math' to the filterRange variable in the lines before the place where steps is defined. That way you can be sure to get integer values as steps for the slider.

You're welcome, glad I was able to help!

Somewhere near line 156 in blocklayered.tpl ( PS v1.5.2 ) is the javascript where the size of the steps is determined for all the layered_slider filter types: var step = filterRange / 100; But any change there will affect all sliders, including price. You'll need to figure out / flag the weight slider from the other sliders and then have the template serve your customized javascript based on that. I haven't played with the Layered Nav. very much, but I hope this points you in the right direction... Good Luck,

Yes, you can make a 'save and stay' button - but you'll need to do a tiny bit more coding. My trick was to make the HTML form action point back to the configuration screen by taking the current URL and stripping it of any stuff that I may have added. Then I used the standard _processPost() and _setConfigurationForm() methods to handle updating the values and displaying the results. If you're more comfortable with javascript and AJAX operations with PrestaShop, you may want to use those instead and bypass needing to code the 'save and stay' button/form. HTH,

Once you've finished loading include(PS_ADMIN_DIR.'/../config/config.inc.php'); you've got all of PrestaShop ready and waiting, even if you don't use it. So you certainly could trigger the UpdateProduct hook manually by adding one or two lines to your code. That said, I would choose path #2 - make it a full-fledged Module. The basic framework for the simple, admin-only module like you describe shouldn't be more than hundred lines total, including comments. I am a tinkerer at heart, so I'm constantly refining my approaches and adding new functionality. A Modules' ability to move it easily from install to install ( dev -> test -> staging -> prod ) is a big plus for me. HTH,

Sounds like it was cached. If you're going to be doing any development, make sure to turn off all caching: Advanced Parameters > Performance : Smarty Advanced Parameters > Performance : Cache HTH,