Open Discussion - What is wrong with prestashop overrides?

[misthero]

Hello everyone, I would like to start a constructive discussion with developers about prestashop override system wich I feel can be improved.

 

I'm not here to complain, but to understand the reasons why the system is like it is today, if it can be improved and how we (me included) can help and contribute to make it better.

 

I'm a developer that worked many years on other CMS from wordpress, magento, joomla etc.. but mostly active with what I think is the best of all: Drupal (but this is just a personal opinion).

 

Only a few years ago I discovered Prestashop so I'm not a [spam-filter], anyway, I liked it, even if the first impression was that I was working with a rough and very young system, with potential, but with a lot a flaws. It never worked out of the box and was filled with bugs. Anyway that was not a problem for me, since I was able to track down most of the bugs and solve it on my own implementations.

 

Than I started contributing with little patches, made my own modules for myself and shared some. But since the first day one of the things that left me a little disappointed was the override system.

 

The point is easy, and I think it was discussed before somwhere else too.

It is based on classes extending other classes, is a nice feature, but with this file override system there is a big flaw in my opinion.

Developers, web agencies and modules can create overrides. But only one override can exist for a given function.

So you will never be able to install 2 modules that try to override the same function.

 

Think about the future...

If we want this software to spread and the community to increase and contribute is easy to think that at some point there will be many modules, and is inevitable that 2, 3 or more modules will try to interact with the same classes and functions.

Thos modules will never be installed together forcing the final users to make decision this one with this bounch of features or the other one..

The same problem will happen if you write an override on top of a module override. What happen if there is a new update for that module that needs to update the override too?

Or overrides made by users, developers and web agencies will not be future proof, if the core is updated and one of the overridden functions is affected, maybe a new functionality, maybe a bug fix, maybe a security patch.. the override will ignore it.

 

I think we all should think and start implementing something more clever.

 

The best example that comes in my mind is Drupal where you can modify almost any core output with hooks (function hooks not smarty) and theme functions, and modules can all influence the result of a same function at the same time (or at least with a manipulable weight system) and contribute to mix the result providing not only a great flexibility but giving developers the opportunity to focus on specific specialized tasks, so, as a result you have module dependencies and modules that interact with other modules.

 

For example, if you have a perfect payment module that is missing a small feature, a feature maybe not needed by everyone so it's not included in the module, wouldn't be much better to make another small module with dependencies that improve the first?

The only other option is to beg the module developer to include it, or make another identical module with the new feature added.

 

I know it would be a big change, but I think it's time to start thinking about it.. How to do it, planning it and testing it. Maybe Prestashop developers already have the solution planned for the next version, and my wall of text today is completely wasted...
But if this is not the case I would like to hear your opinion.

 

What do you think?

 

(ps: sorry for my poor english)

Edited July 16, 2014 by misthero (see edit history)

[El Patron]

I like the idea of overrides but I find that a many important classes, product for example,  has rather large blocks of code so it's not easy to override core without possibly affecting code block caused by version or custom code.  Breaking the larger blocks to functions allows one to more precisely target code and reduce developer override collisions.

 

fyi: ps addon's verification is frowning on using override (unless there is no other way and a worth while, so there are exceptions to that rule I think).

 

the idea of helpers is if I understand any of it excellent, but I am finding that many legacy controllers in bo/fo are not using helpers,yet

 

for example admin/themes/default/template/products/  does not use helper for prices, it has only a .tpl file so I can not override it.  (I'd love to be corrected on this one, so would others).

 

Having more capability to also override .tpl will open up a lot of possibilities as we can overrirde class/controller level easily enough.

 

thanks for sharing

[bellini13]

back office template files can be overridden, pretty sure the developers guide shows how

[misthero]

fyi: ps addon's verification is frowning on using override (unless there is no other way and a worth while, so there are exceptions to that rule I think).

 

I didn't know that, but I can understand why...

 

I myself tend to avoid overrides in my modules because I know and I feel is bad as a coding pratice. And is not mainenable in long term.

 

Point is not what can be overridden, but how the override system works.

 

None will use Prestashop out of the box and sooner or later, everyone needing a professional online shop is going to need modifications to the system. That is the purpose of an open source, modular software anyway. Allowing you to have a base to start to get what you want.

 

With time people ends up with a software with so many overrides, and get to a point they cannot update it anymore unless spending a lot of time searching for what has been modified, or patched and applying those modifications to every override, bug test again and so on.

 

That is probably one of the resons because many people is scared to update their shop to the latest release. Many shops will stay to version 1.5 and there are still some on 1.4.

 

An update shuold be painless and welcome, not only new features, but also security patches.

But every update can mean losing your customizations or risking to break your shop needing a professional to fix it, or even appliyng patches that will never be applied because overrides will take priority over the new functions.

 

Did you ever tryied to update a shop with dozen of overrides? Or a shop not using the default administration theme? I can assure you that is not painless at all, and the "1 Click Update" can become "1 Click Destroy"..

[El Patron]

back office template files can be overridden, pretty sure the developers guide shows how

 

my understanding and testing shows that they certainly can if helpers but for my example I would need to copy the entire price.tpl override structure to override folder.  if you find differently please let us know.

[El Patron]

I think this is more of a post not so much as discuss existing and future override support in ps as it is to say it's not a good idea at all.

 

personally I think the migration ps is using for overrides for back and front office is what it is and is not going away and it's best to embrace it and understand it especially when it comes to helpers.

 

stating that 'upgrades' are a disaster because of overrides, upgrades are a disaster when not done following ps upgrade documentation.

 

with the advent views we can now (when supported by module in theme) add additional features to existing modules without creating a new module, which is one area op has concerns about.

 

all in all, it is what it is and I feel that there will be more opportunity for developers to create modules more easily with overrides especially if we can affect theme.

 

cheers, el

[misthero]

El Patron, I didn't  state is a disaster cause of overriders, I said it can become, on highly customized shops with a lot of overrides.

 

Don't take my words as if I'm trying to state that Prestashop is bad, it's not what I'm saying. But is not perfect too, maybe it will never be, how can we make it a little better?

I'm just trying to explain my point of view about what I think can be improved.

 

Maybe I'm wrong but until now none took the time to write a couple of lines explaining me why... Am I missing something?

 

If you say that override system will stay as it is and is not going anywhere it's ok, than this topic ends here...

But are you sure it is the best possible system?

[bellini13]

my understanding and testing shows that they certainly can if helpers but for my example I would need to copy the entire price.tpl override structure to override folder.  if you find differently please let us know.

you can read about it here

http://doc.prestashop.com/display/PS15/Using+helpers+to+overload+a+back-office+template

 

smarty has the extends and block tags that allow for extending templates like you would extend a class.  if used properly you can then target specific blocks of code

[El Patron]

you can read about it here

http://doc.prestashop.com/display/PS15/Using+helpers+to+overload+a+back-office+template

 

smarty has the extends and block tags that allow for extending templates like you would extend a class.  if used properly you can then target specific blocks of code

 

yes, if they is an existing helper for what one wants to override...that is my point and I can't get past that either in testing or in documentation.

[El Patron]

El Patron, I didn't  state is a disaster cause of overriders, I said it can become, on highly customized shops with a lot of overrides.

 

Don't take my words as if I'm trying to state that Prestashop is bad, it's not what I'm saying. But is not perfect too, maybe it will never be, how can we make it a little better?

I'm just trying to explain my point of view about what I think can be improved.

 

Maybe I'm wrong but until now none took the time to write a couple of lines explaining me why... Am I missing something?

 

If you say that override system will stay as it is and is not going anywhere it's ok, than this topic ends here...

But are you sure it is the best possible system?

 

gosh no, I did not mean it that way.

 

we can discuss anything...certainly don't feel like we can't bump heads and continue discussion, yes?

 

would be better to sit around a table and kick it, but the forum brings us together from all over the world at least.

[El Patron]

currently looking how to overrdie

 

tools/smarty/sysplugins/smarty_cacheresource_custom.php

 

i'm tired

[bellini13]

not possible to override that using the current override system

[El Patron]

not possible to override that using the current override system

 

yea, this as OP suggested we are pretty limited with current state of affairs...

 

ave maria pues