byronpk

I'm unsure if it could be made to work on the new product, best sales and promotions pages, mostly because those pages use their own SearchAdaptors and the entire basis of getting this to work was in modifying the SearchProvider, Converter and SearchAdaptor classes to support the extra "fields" that it's fed from those pages. I'm sure there is a way, but given how it took me literal hours of reverse engineering and pouring over the code to get it to work in the fashion that it is right now, I'm not really sure how much more can be done to it, but in theory, anything should be possible if you can make the right mods to the SearchAdaptor. The least I can do at this point is showing that it does in fact work well enough on my local test platform.

I was recently faced with a similar issue and made a very janky modification to the ps_facetedsearch module to allow it to function on the search results page of a store I was working on for a client. Bare in mind, it's hella jank, but it seems to work just fine. I also enabled it to work on the "brands" pages. I'm sure it can be made to work in other places, but it's a very janky and involved set of mods that need to be made to work as required. Feel free to run through the files, I'm sure a simple diff will show where changes needed to be made to make it work ps_facetedsearch.zip

Is there any way to prevent the Smarty Caching system from caching dynamic TPL content in the sidebar, like the "ps_categorytree" widget? The site is very slow without caching and at this rate I'm torn between having a slow site with everything working vs a broken site that loads fast. Are there any directives in code one could add to bypass the cache for specific parts of the site? Kind regards

Darn it, that's a shame still this was for PS 1.6, so I don't know if it would work as it on PS 1.7, you did declare the hooks in the install() section and reinstall your module right? /** * Install the PrestaShop Module * * @return boolean Success or Fail */ public function install() { if (!parent::install() || !$this->registerHook('actionOrderStatusPostUpdate') || !$this->registerHook('actionOrderHistoryAddAfter') ) { return false; } return true; }

Perhaps, but I dug through my old development work backups and found the module I wrote, I used two hooks to solve my problem. Sadly the code is copyrighted to the company I used to work for, but I can share small snippits without triggering any red flags: The hook OrderHistoryAddAfter I believe fires after an update occurs in the OrderHistory. So I intercepted that call and updated the order status it just wrote directly in the database: /** * hookActionOrderHistoryAddAfter * Hooks into actionOrderHistoryAddAfter updating the Order History table with new Order status * * @param resource $params OrderHistory object */ public function hookActionOrderHistoryAddAfter($params) { if($this->orderState !== 2) { $history = $params['order_history']; $history->changeIdOrderState($this->orderState, (int)$history->id_order); if(isset($this->orderState)) { $sql = 'UPDATE '._DB_PREFIX_.'order_history SET id_order_state = '. $this->orderState.' WHERE id_order_history ="'. $history->id .'";'; if (!Db::getInstance()->execute($sql)) { die("ERROR"); } } } } The other hook I used was OrderStatusPostUpdateHook instead of OrderStatusUpdate /** * Hooks into the PrestaShop onOrderStatusUpdateHook * * @link http://doc.prestashop.com/display/PS15/Hooks+in+PrestaShop+1.5 Hook reference on PrestaShop dev site * @param mixed $params Input parameters from the PrestaShop hook system */ public function hookActionOrderStatusPostUpdate($params) { // Thread variables $id_thread = 0; $thread_email = null; $order_message = ''; // Grab the debug status from the database // Get the FishBowl configuration from the database $sql = "SELECT `debug` FROM ". _DB_PREFIX_."fishbowl_config WHERE `id_fishbowl_config` = 1;"; if ($app_data = Db::getInstance()->ExecuteS($sql)) { $this->debug = strval($app_data[0]['debug']); } // Right, here goes all the code you need to get the basic details about an order // Basic detail variables, defining the order, it's current state, etc, etc. $id_lang = Configuration::get('PS_LANG_DEFAULT'); $order_state = $params['newOrderStatus']; $order_id = $params['id_order']; $order = new Order((int)$order_id); ... So, it basically fires AFTER the order status was updated by the purchase, (which was too late for me), but the other hook would trigger the moment the entry was made into the history and I'd latch onto that and change the order status in the DB after the call was completed, essentially cheating the system Hope this helps you find a solution that works for you friend

This is why I don't bother with the forums anymore, either people just don't know that answer, they never reply or the answers are irrelavant and don't work. To this day I'm still having to solve my own problems because the forums are mostly useless 😕 Regardless, I'd post the entire module file that I used to get around this problem if I still had access to it, I had finished/given up on that project 3 years ago and I've moved on to bigger and far more frustrating problems

Hi everyone, (refering to previous forum post: https://www.prestashop.com/forums/topic/529167-mutli-store-pricing-glitch) I'm still in need of a solution to this problem. The customer is still in need of a quick way to edit products for both store simultaneously. The problem is, the stores (in multi-store) share stock, but not PRICES. This creates a situation were if the client needs to edit a description of a product in the multi-store environment, the prices for products in both stores are set to the same price, which is hugely annoying given that the wholesale store has lower prices (discount for wholesale won't work either, as wholesale does not have a consistent discount) Is there any way that we can update product details in bulk (even if it's a module, we're in a great need to solve this problem right now), but not touch the prices for each individual store. Thank you in advance!

Well, I simply need to be able to call the page directly with it's URL and pass POST variables to it. Since it's front office, I guess a controller page? I'm not sure which would be best for my use in this scenario.

Hi There! I'm currently writing a PrestaShop module for the company I'm working for and I'm in a bit of a bind. How would a go about adding a custom page to the site automatically when the module is installed? Also, I need this page to be able to accept PHP POST variables. This will serve as a confirmation page for a custom return system and I'd like to do some other integrations on that page as well. Any ideas? Kind regards Byron Kleingeld

Thanks for the reply! It's a pretty difficult customer haha. I'm pretty sure it uses the ps_stock_available table for that, and ps_product_shop for products. So it really shouldn't do this, since the ps_product and ps_product_shop tables share data, but don't hold stock quantities. ps_stock_available links to those...weird, eh? That being said, the "discount" isn't consistent between products, some get discount, some don't, some get LOTS of discounts, others a little, so it's a REAL pain.

Good Morning All! I'm having a problem with a PrestaShop 1.6.1.4 environment I've set up for a customer. They have a multi-store setup with stock sharing enabled. The one store is their public store whilst the other is their wholesale store, thus the wholesale store has different prices to the main store. The problem is, when the client tries to the change the shared stock quantities between the stores, the price for the wholesale store is changed to the price for the main store even though the stock is being handled in the "store group" context. They do not have advanced stock management enabled as they prefer manually editing the stock quantities as they change. Is there anything we can do to fix this problem or is it simply a lost cause?

Hi lumedevikeira I have not unfortunely. We eventually used a totally different approach to the problem, and some smart DB hacks. I don't feel it's a "solution" since it's not recommended or good.

@polosat: I'd love to link you, but due to my work contract I cannot post any code that could identify any customers, company details and such. That being said, the module works on my MacBook Air, so I might as well finish it there and worry about the workstation when I have time XD. I'll post some code up as soon as I a moment to sanitize it.

Hi Everyone Quick question. According to the hook documentation (http://doc.prestashop.com/display/PS15/Hooks+in+PrestaShop+1.5), the hook named "actionOrderStatusPostUpdate" is meant to be fired AFTER the order status of an object has already been changed, if I understand correctly? Thus, I assumed since the orderStatus has already been changed I could safely change it again in my code without any issues. My code contains a conditional block that scans the products in the order the moment it goes to the "Payment Received" status, and if the order contains any "restricted items" it would notify the user and change the order status to "Restricted: <reason>" (ID: 15). When I run the code and the hook fires, I end having the status set and then immediately replaced with "Payment Received". https://www.dropbox.com/s/uc4ebr2ybytx2ks/Screenshot%202016-03-15%2012.52.47.jpg Is this normal behaviour for the POST update hook? Since the status is supposed to ALREADY BE CHANGED, why would it change it anyway? ... } else { // Restricted order... $order->setCurrentState(15, 1); ... Is there another way to do this that I can ensure it changes correctly?

Hi polosat Everything checks out okay, thing is, my PrestaShop module works on my MacBook, but work work on my dev system desktop, same version of PrestaShop, same XAMPP, just a different OS, works on the one, won't work on the other...