theillo

I think I found out why it happened: https://build.prestashop.com/news/prestashop-in-2019-and-beyond-part-2-pain-points/

https://build.prestashop.com/news/prestashop-in-2019-and-beyond-part-2-pain-points/ This sheds some light on the technical side of all this...

That explains the high number of WTFs per minute............ Thanks this is a great article, allowing me to make a more educated decision about how to move forward with my upgrade.

Well, SemVer has clearly been violated if the hooks that are documented under 1.7 are no longer backwards compatible with a subversion of 1.7 https://devdocs.prestashop.com/1.7/modules/concepts/hooks/list-of-hooks/ This documentation tells me that in version 1.7 I have a hook available, called action<AdminControllerName>ListingFieldsModifier But according to everything you've told me here, this 1.7 API is no longer backwards compatible in 1.7.6.5 because the hook no longer gets called, because of a merge to Symfony or whatever. "MINOR version when you add functionality in a backwards-compatible manner" Functionality was added, but not in a backwards compatible manner, because documented functionality was removed. So if I'm understanding everything correctly, 1.7.6.5 should really be called 1.8

Ok. Thanks for the link, this should probably work. But man, I'm pissed. I'm in the process of upgrading from 1.6 to 1.7 and now you're telling me the documentation for 1.7 is outdated, because there was a major change in the architecture from 1.7.something to 1.7.6 ? Who's in charge of versioning at PrestaShop? Who's in charge of making sure that any changes are backwards compatible with the documentation?

index.php/sell/catalog/categories I want to add a column to the category list using the hook actionAdminCategoryListingFieldsModifier but I don't even know yet if it's called actionAdminCmsCCategoryListingFieldsModifier or something else. But that's not going to be a very sustainable method for me to keep developing, if I need to ask you where to find the hooks... What happened to the documentation? Has version 1.8 been released, and the 1.7 documentation is no longer valid? I'm using 1.7.6.5 by the way, which I've downloaded approximately one month ago...

What the actual F? Then why in the world would the documentation point me to /classes/controller/AdminController.php where the Hook gets called that I wanna use? I'm so lost right now So where is the action<AdminControllerName>ListingFieldsModifier Hook located in a "modern" controller? Where does it get called, so I can hook into it?

What the actual firetruck? Then why in the hell would the documentation point me to /classes/controller/AdminController.php where the Hook gets called that I wanna use? I'm so lost right now So where is the action<AdminControllerName>ListingFieldsModifier Hook located in a "modern" controller? Where does it get called, so I can hook into it?

Is the AdminController a Symfony controller? I think not, right...?

Thanks for the reply! Yes, I'm using the dump function, see my code... What am I doing wrong? Usually, dump(); die(); works perfect, but in this specific case it doesn't seem to do anything. Seems to straight up ignore it.

According to https://devdocs.prestashop.com/1.7/modules/concepts/hooks/list-of-hooks/ there is a hook called action<AdminControllerName>ListingFieldsModifier I would like to use this hook, but in order to do so, I need to debug, to find out what the parameters are, etc. So then I go into /classes/controller/AdminController.php to public function getList() in line 3153 There, the following code does nothing: public function getList( $id_lang, $order_by = null, $order_way = null, $start = 0, $limit = null, $id_lang_shop = false ) { //// THIS IS THE CODE I'VE INSERTED/// dump($this->controller_name); die(); //// END OF MY OWN CODE/// Hook::exec('action' . $this->controller_name . 'ListingFieldsModifier', array( 'select' => &$this->_select, 'join' => &$this->_join, 'where' => &$this->_where, 'group_by' => &$this->_group, 'order_by' => &$this->_orderBy, 'order_way' => &$this->_orderWay, 'fields' => &$this->fields_list, )); The page is loading as if nothing ever happened. How can I debug anything in this function, when die() and dump() don't do anything?

Here's the commit during which the removal happened: https://github.com/PrestaShop/PrestaShop/commit/cd61b3ddc6ca19d5cb90614f1df57b62c1233238 538 deletions for AuthController.php and the Ajax functionality was removed. Why? Was it put somewhere else? The title of the commit is "Add account creation in AuthController". Why did we have 538 deletions to "add" something?

Question for the Core Devs: I'm upgrading from 1.6 to 1.7. Previously I was able to send an Ajax request to the AuthController. In 1.6 the AuthController had this useful bit of code in it: if ($this->ajax) { $return = array( 'hasError' => !empty($this->errors), 'errors' => $this->errors, 'token' => Tools::getToken(false) ); $this->ajaxDie(Tools::jsonEncode($return)); } This allowed me to make an Ajax request to the Auth Controller, and I'd receive back a Json Object with any errors that might have occurred during login. I could then handle the errors in whichever way I wanted. This worked just fine. Convenient, simple, and effective. However, now there is no trace of this code in the 1.7 Auth Controller. What's the new process for Ajax calls to front controllers, specifically the Auth Controller?

Also, I've gone straight up into the template file checkout/cart.tpl and replaced everything in there with {Tools::redirect('order')} There's absolutely no point to having this "cart" page, all it does is make the customer jump through another hoop before clicking the "pay now" button, especially since checkout.tpl (which is the file you see when you go to the order contoller) - especially since this file looks almost the same as cart.tpl 🙄 Edit: This definitely causes glitches sometimes. May be better to create a cart.tpl that looks identical to checkout.tpl in case a customer ever visits /cart or for whatever other reason they might land on this page. It's definitely possible to delete /cart in back office (Shop Parameters -> SEO & URLs). {$product.add_to_cart_url} will then be resolved to /index.php?controller=cart instead of /cart Of course, this may still lead to a customer sometimes being taken to index.php?controller=cart, so the cart.tpl still needs to be optimized for checkout.

You can do it with the hook actionCartSave Create a module, or upgrade an existing module, let it install this hook, then create this function in the module: public function hookActionCartSave($params){ Tools::redirect('order'); } Now anytime you're adding, removing, or somehow updating the cart, it will redirect you to order.php https://devdocs.prestashop.com/1.7/modules/concepts/hooks/list-of-hooks/