Jump to content

theillo

Members
  • Posts

    91
  • Joined

  • Last visited

Everything posted by theillo

  1. I think I found out why it happened: https://build.prestashop.com/news/prestashop-in-2019-and-beyond-part-2-pain-points/
  2. 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...
  3. 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.
  4. 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
  5. 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?
  6. 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...
  7. 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?
  8. 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?
  9. Is the AdminController a Symfony controller? I think not, right...?
  10. 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.
  11. 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?
  12. 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?
  13. 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?
  14. 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.
  15. 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/
  16. Here's a module to do just that, in case you just wanna throw money at the problem... https://www.knowband.com/blog/user-manual/prestashop-one-click-checkout/
  17. I'm wondering the same thing right now. When disabling AJAX cart, then it just redirects me to a /cart instead of to /order I will research more and post my findings.
  18. So it's been 2.5 years since this was posted. I'm in the process of trying to upgrade my custom PS 1.6 theme to PS 1.7 Which is a lot of work by the way. There is 0 backwards compatibility. Hundreds of developer hours are needed to make this upgrade, if you have a custom theme (a theme that it once took hundreds of hours to design in the first place) It was supposed to be for the sake of "better software design", which I'm okay with, and why I ultimately decided to make the investment and upgrade my shop. There are certainly many improvements to the software design, and there are some really good new features in PS 1.7 That being said, there are also some major flaws, and much of the code is anything but modular, it violates several software design principles, and even goes against the very architecture it's build on (this architecture was my reason for choosing prestashop in the first place, many years ago) One example, the {render} command totally destroys the MVC architecture. Suddenly the template file (view) acts as a controller by using this command. Right of the bat, that's the biggest flaw, and the documentation can back it up, pretty much admitting that {render} was a workaround created only for the checkout page and for the login form. Here's a quote from the documentation: https://devdocs.prestashop.com/1.7/themes/reference/smarty-helpers/#render Way to go, that's good "documentation"! Some elements might need to be passed to this function. Alright, makes things perfectly clear for any developer unfamiliar with the matter. Thanks a lot! Way to improve the software design! [/sarcasm] And just to give one more example: This whole concept of {block} is a good idea, but why would you keep the naming conventions so inconsistent that block names are used multiple times in different files (e.g. block cart_summary appears twice in checkout.tpl) but then they're referring back to differently named template files (e.g. cart-detailed.tpl is the template file for the block cart_overview. Why not use cart_overview.tpl ?). That might seem like a petty minor flaw, and I wouldn't complain, but things like that are quite noticable thoughout the entire code. Who's making these decisions that give me a headache multiple times a day??? As a Theme developer I'm not only super confused trying to untangle this mess and make it work for my customizations, but I also have very little creative freedom, especially when it comes to the login form for example, and the checkout page. The login and account creation forms are totally entangled with the variables they require from their controller, so how the heck can I display them again? It was specifically stated in the documentation: https://devdocs.prestashop.com/1.7/themes/reference/template-inheritance/ When you're making a platform like this, and you're trying to allow for creative freedom, then shouldn't you consider these things? For example: Why dump all form elements into ONE file "_partials/form-fields.tpl"? Is it really neccessary to load the whole tpl file containing every possible form element every time? Plus: you're not even doing it! The contact page and the password recovery page do not even make use at all of the form-fields.tpl. And also: If there's a form field I don't want to use, or for whatever creative design decision, I wanna change the order of my fields... Guess what? I can't! Because it's pretty much determined for me and has all been packed into ONE variable, which the theme is for-looping over. What's the point of making MVC, when you could just let the controller spit out the HTML code? That's bascially what's happening as you pack all this design related information into one big array, and then loop over it to render the HTML code. Just take a look at checkout/checkout-process.tpl {foreach from=$steps item="step" key="index"} {render identifier = $step.identifier position = ($index + 1) ui = $step.ui } {/foreach} Does this look like a VIEW? A template file? Should a Web Designer really have to deal with this? There's not a single line of HTML code in this. Looks more like CONTROLLER logic to me. VIEW is HTML, CSS, and maybe some JavaScript. You're literally using a templating language to run complex controller logic, that should stay in PHP. You discourage the use of overrides, then please make it possible to NOT use overrides. This is not a matter of "there aren't enough hooks". It's a matter of not implementing the MVC architecture properly. Separation of concerns. Again: Who's making these decisions? Who's considering the creative freedom for module developers and theme designers? Who's considering how self-documenting the code is? (Because let's face it: Even though some effort was put into it, the documentation is basically non-existent. Why don't we just write code that can be quickly deciphered by humans? Then we don't have to worry about creating documentation, either, because it would be self explanatory and self evident from the code alone) And these are just some of the many problems I'm stuck on. If anything, PS 1.7 has more complicated software design, because it's extremely difficult for a developer who's unfamiliar with the system, to understand it quickly. I've been developing stuff for prestashop for 6 years now, why is it that I can't quickly do a simple theme upgrade? It was only 1.6 to 1.7, not 2.0, or is it?? The reason I came across this threat, is because I'm also trying to get my simple, convenient one page checkout working again. I wanna make sales, so I wanna keep things as eeeeassy as possible for my customers. The only button I want them to press is the "PAY NOW" button. Maybe that's another software design principle that the prestashop development team forgets about: K.I.S.S.! Does anyone familiar with the architecture have a recommendation for me? I only wanna get my login form on the checkout page, and the payment form. How can I get a one page checkout, where I only have "create your account or log in" (reusing my original login form from the login page) and then the payment module with credit card info? When I use include, trying to re-use my login form template file, I'm missing the form field definitions. When I use render, I'm missing some UI variable which I have no clue where that comes from, because render is CONTROLLER LOGIC and not VIEW logic.
  19. So as a theme developer, which PHP file should I be modifying? I'm converting my PS 1.6 theme over to PS 1.7 (ssems like the OP was doing something similar)
  20. You can do {$var_name|dump} It's actually really nice, much better than {debug}
  21. Could you please say how you used this function? Previously we used {convertPrice price=$product.price} but it's no longer working. What's the code that we write into our templates now, to achieve the same thing?? There are several answers here: {$product->convertPrice($product.price)} does not work {Tools::displayPrice($product.price)} works for me right now, but also someone said it's deprecated.
  22. I'm trying to do something similar. What exactly is triggering `hookDisplayClientCode();` to be executed? I don't see you calling on the hook anywhere.
  23. Hi, I need help big time! I have to upgrade my store, because my server won't support the PHP version required for PS 1.6 anymore. From my research so far it looks as if PS 1.7 might as well be a completely different ecommerce platform when it comes to themes. What's my best bet to convert my current, custom PS 1.6 theme and make it compatible with PS 1.7? I don't wanna have to code the whole thing from scratch. I wanna be able to get at least 80 or 90% of the way there, and then fix the remaining glitches. How can I make it so that the upgrade from PS 1.6 to 1.7 won't cost me several month of development work?
  24. I need to update my PS to 1.7 because my server is updating PHP. I have a lot of custom modules, thousands of lines of code, and don't wanna have to rewrite them. Luckily, many of them installed with no problems. But some, just give me a generic error "Installation of module mymodule failed. Unfortunately, the module did not return additional details." How can I further debug this error? Obviously, debug mode is already turned on...
×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More