Jump to content

gPowerHost

Members
  • Posts

    11
  • Joined

  • Last visited

Profile Information

  • Activity
    User/Merchant

gPowerHost's Achievements

Newbie

Newbie (1/14)

2

Reputation

1

Community Answers

  1. We don't want to use the 1-click upgrade functionality as it doesn't suit our needs. We built a deployment script to help deploy to our development, staging and production servers from our own custom git repository. So far in testing it seems to work well for us. However, we would like to understand the differences and dependencies related to the official PrestaShop git releases, their included modules (in /modules and /themes/default-bootstrap/modules), the contents of /install and the upgrade process, better. 1). We think that we JUST need to track and release, as part of our own upgrade process, any modules that we modify, our own, or those that are not part of official PrestaShop Marketplace. We think this as we can selectively use the standard Modules update process to upgrade all that we don't include in our own git. So, we are considering not including most of those modules found in PrestaShop releases in /modules and /themes/default-bootstrap/modules leaving that to the standard Modules update process included in PrestaShop. Does this make sense? Do both those locations get updated as part of the standard back office Modules update process? 2). Following that, if we see that all modules are up to date (via the standard Modules upgrade functionality found in the back office) just prior to our own git deployment, and then we deploy (without most of the modules in /modules and /themes/default-bootstrap/modules), and then again we use the back end standard Modules update process, will that be good practice? 3). Won't the standard Modules update process ensure all those modules that we didn't include from the PrestaShop git release get properly upgraded? 4). It isn't just a matter of a whole bunch of extra code (from the modules we don't want to track in our own git repo), but rather will those modules could also be stale versions by the time we deploy. If a stale version of a module (say version 1.1) were deployed over a fresher version (say, 1.2) that could be troublesome, especially if the module had made database changes as part of the upgrade from 1.1 to 1.2 already. We would like to not have to write a deployment routine to handle this if possible. 4). Finally, if we base our own git deployment on a PrestaShop git release (omitting what is in /install), and we also synchronize and update SQL as part of our deployment (based on what we find in /install/upgrade/sql) is there something we are missing? Do we need to do anything else or consider what is in any of the other parts of the /install folder? I hope I've explained what we are wanting/doing well enough so that some of you can share your knowledge a bit so we can design an upgrade process that meets our own deployment needs. Thank you so much, in advance.
  2. Thank you. This solves the mystery for me.
  3. Thanks. But I'm not trying to override from a module just by placing a replacement file somewhere in /override/??? Isn't admin/themes/default/template/controllers/products/prices.tpl a "theme tpl", which can be overridden by placing an override in: override/controllers/admin/templates/products/prices.tpl ?
  4. Hello, I can easily override admin template files (.tpl), such as: admin/themes/default/template/controllers/products/prices.tpl by placing an override in: override/controllers/admin/templates/products/prices.tpl This works great! However, I can't seem to figure out how to override front end template (.tpl) files, such as: modules/blockcart/blockcart.tpl themes/default-bootstrap/product.tpl themes/default-bootstrap/modules/loyalty/views/templates/hook/my-account.tpl Can anyone enlighten me as to the exact locations for those above three files to successfully be overridden? I've seemingly tried every possible permeation, just not the correct ones! Thank you, in advance!
  5. Thanks tuk66, Since these files were stuffed, unstuffed and passed through several trusted servers, scanned, etc. it just made sense to replace the files. I can't imaging this happening again, so no need to do the complicated. Many times the simple easy solution is best. All the best! -Edie
  6. Hi, After moving a staging server site in preparation to go live the PS admin area Advanced Parameters->Configuration Information->LIST OF CHANGED FILES reports erroneously that there are 266 changed files, when there are only 4 with actual changes. We have verified that the files are indeed identical. How is this reading made, or better how can it be reset without having to do a fresh install? PS 1.6.0.9 A great majority of the files are: admin/themes/default/template/controllers/...
  7. My apologies, the issue was unrelated to the function __construct. This works just fine: class Product extends ProductCore { public $srp; public $show_member_price; public $show_srp_price; public function __construct($id_product = null, $full = false, $id_lang = null, $id_shop = null, Context $context = null) { self::$definition['fields']['srp'] = array('type' => self::TYPE_FLOAT, 'validate' => 'isCleanHtml'); self::$definition['fields']['show_member_price'] = array('type' => self::TYPE_STRING, 'validate' => 'isCleanHtml'); self::$definition['fields']['show_srp_price'] = array('type' => self::TYPE_STRING, 'validate' => 'isCleanHtml'); parent::__construct($id_product, $full, $id_lang, $id_shop, $context); } } I will attempt to mark this as resolved.
  8. Hello, I'm having an issue adding more than one field to be editable from the backend shop. I can easily read new fields from the db, but I can't get the "public function __construct" to accept more than the first new field (for validation and writing). In the examples below, only the first 'show_member_price' is editable from front end and if I switch the order say making 'show_srp_price' first in the __construct then only that is editable. Additionally, I will next be wanting to update values in columns of the same name in ps_product_attribute table. Would the construct remain "__construct($id_product" or would it, perhaps, change to "__construct($id_product_attribute"? FILE: override/classes/Product.php <?php // ADD A RETAIL PRICE FIELD AND FIELDS TO ALLOW/OVERRIDE SHOWING THE MEMBER OR SRP PRICE TO THE PUBLIC (OR NOT) class Product extends ProductCore { public $srp; public $show_member_price; public $show_srp_price; public function __construct($id_product = null, $full = false, $id_lang = null, $id_shop = null, Context $context = null) { self::$definition['fields']['show_member_price'] = array('type' => self::TYPE_STRING, 'validate' => 'isCleanHtml'); parent::__construct($id_product, $full, $id_lang, $id_shop, $context); self::$definition['fields']['show_srp_price'] = array('type' => self::TYPE_STRING, 'validate' => 'isCleanHtml'); parent::__construct($id_product, $full, $id_lang, $id_shop, $context); self::$definition['fields']['srp'] = array('type' => self::TYPE_FLOAT, 'validate' => 'isCleanHtml'); parent::__construct($id_product, $full, $id_lang, $id_shop, $context); } } ?> have also tried: <?php // ADD A RETAIL PRICE FIELD AND FIELDS TO ALLOW/OVERRIDE SHOWING THE MEMBER OR SRP PRICE TO THE PUBLIC (OR NOT) class Product extends ProductCore { public $srp; public $show_member_price; public $show_srp_price; public function __construct($id_product = null, $full = false, $id_lang = null, $id_shop = null, Context $context = null) { self::$definition['fields']['show_member_price'] = array('type' => self::TYPE_STRING, 'validate' => 'isCleanHtml'); self::$definition['fields']['show_srp_price'] = array('type' => self::TYPE_STRING, 'validate' => 'isCleanHtml'); self::$definition['fields']['srp'] = array('type' => self::TYPE_FLOAT, 'validate' => 'isCleanHtml'); parent::__construct($id_product, $full, $id_lang, $id_shop, $context); } } ?> Thanks for any assistance anyone may provide. I was basing this on: http://nemops.com/prestashop-rrp-price/#.VF4Gw4eIfwU Thanks, Nemo! and liked it because it involves overriding very little in: classes/Product.php -Edie
  9. Thanks! I'm sure loving the PrestaShop way. For any newbies, to extend the core and have your changes survive an upgrade, in PS 1.6.0.9 simply create this file in this location (to have features in the front end obey the sort order as set in the backend): Create a new file (or if one exists, merge this function, getFeaturesForComparison, or add it) override/classes/Feature.php <?php /* * 2007-2014 PrestaShop * * NOTICE OF LICENSE * * This source file is subject to the Open Software License (OSL 3.0) * that is bundled with this package in the file LICENSE.txt. * It is also available through the world-wide-web at this URL: * http://opensource.org/licenses/osl-3.0.php * If you did not receive a copy of the license and are unable to * obtain it through the world-wide-web, please send an email * to [email protected] so we can send you a copy immediately. * * DISCLAIMER * * Do not edit or add to this file if you wish to upgrade PrestaShop to newer * versions in the future. If you wish to customize PrestaShop for your * needs please refer to http://www.prestashop.com for more information. * * @author PrestaShop SA <[email protected]> * @copyright 2007-2014 PrestaShop SA * @license http://opensource.org/licenses/osl-3.0.php Open Software License (OSL 3.0) * International Registered Trademark & Property of PrestaShop SA * * */ class Feature extends FeatureCore { public static function getFeaturesForComparison($list_ids_product, $id_lang) { if (!Feature::isFeatureActive()) return false; $ids = ''; foreach ($list_ids_product as $id) $ids .= (int)$id.','; $ids = rtrim($ids, ','); if (empty($ids)) return false; return Db::getInstance()->executeS(' SELECT * , COUNT(*) as nb FROM `'._DB_PREFIX_.'feature` f LEFT JOIN `'._DB_PREFIX_.'feature_product` fp ON f.`id_feature` = fp.`id_feature` LEFT JOIN `'._DB_PREFIX_.'feature_lang` fl ON f.`id_feature` = fl.`id_feature` WHERE fp.`id_product` IN ('.$ids.') AND `id_lang` = '.(int)$id_lang.' GROUP BY f.`id_feature` ORDER BY f.position ASC '); } } ?> This way your changes will survive an upgrade and you will only have to monitor if the original function: "getFeaturesForComparison" in classes/Feature.php for any rare changes (in which case you will have to do a merge, or just copy the new function as modified and search and replace: ORDER BY nb DESC WITH: ORDER BY f.position ASC Voila!
  10. I know this is an old thread, but incase anyone else runs into an issue where "No reward points for this product" is displayed on a product page, and you have the module "Customer loyalty and rewards" installed and configured, and you wonder what it should say or do. It should say how many loyalty points you would get if you purchased this product. If it doesn't maybe your dev or live shop had some changes and the module is only showing "No reward points for this product". To fix this go to: ADVANCED PARAMETERS -> Performance -> SMARTY and select "Recompile templates if the files have been updated" and then hit "Save", If you don't want this permanent setting, or if this didn't work, temporarily select "Force compilation" hit "Save" and then reselect either "Recompile templates if the files have been updated" or "Never recompile template files" and save again. The above should cause the "No reward points for this product" if displayed on a product page to do what you might expect and show something like "By buying this product you can collect up to 1 loyalty point. Your cart will total 16 points that can be converted into a voucher of $3.20.". Hope this helps folks new to PrestaShop understand that the module is working and what it is supposed to do.
  11. It seems that this issue might have different causes, and therefore several different solutions. When, as suggested, error reporting reports no errors, we have seen this issue on dev shops especially when no CRONS are setup for blocklayered module. For those with blocklayered enabled, try rebuilding the Indexes and Caches manually in the configure area of Layered Navigation Block (blocklayered). This may help. Hope it does!
×
×
  • Create New...