Jump to content
Presta FABRIQUE

Addons: unfair module submitting/upgrading rules

Recommended Posts

Edit: open letter for Addons team and developers community

 

Hi

 

Despite positive changes and upgrades on Addons, there are a few very annoying and developer "unfriendly" rules - if we can use that word.

 

To be more precise: we wanted to upgrade our module (not named here) which has lots of nice new features - all asked and suggested by our clients - and after a hassle, lasting few weeks, sometimes receiving just short, undescriptive answers, meantime our module is not available for sale (not even old version), turned out we cannot do that, because the module cannot be installed via the PrestaShop Back office. This is totally unfair! You cannot ask developers to rewrite (in some cases even in 50%) their modules just overnight!

 

Of course, a simple ZIP install via Back Office is a nice and user friendly feature, but set it as a requirement for new modules, or ones compatible with Presta version starting from 1.5, and for older modules set a timeline from where this is required!

 

And look at it from this POW: clients using these modules (which require core modifications) will need to delete files from their Prestashop root and other directorys when upgrading, which is very dangerous thing to do by a novice! Not talking about the fact, that a rewrite of this proportions could loose the upgrade functionality by ease, resulting in clients loosing old module data.

 

And we are sure, that not all modules can be written to be installed via Back Office. In some cases this is just not possible! So these have no chance on addons, no matter how awesome they are?

 

Conclusion: let developers upgrade their modules even if they "require core modifications". And note, we are talking about an upgrade here, not new submission, which is also a pro-user thing!

 

Best regards,

Presta FABRIQUE

Edited by Presta FABRIQUE (see edit history)

Share this post


Link to post
Share on other sites

As an end-user I totally disagree.

 

I don't want ANY modules (especially if they're paid) to rewrite any core files. Period.

 

And we are sure, that not all modules can be written to be installed via Back Office.

 

I'll defer this to other module developers to say if this is an accurate statement or not. I've seen some pretty advanced modules that can be installed from the BO.

 

Just my ,02 :)

Share this post


Link to post
Share on other sites

I don't want ANY modules (especially if they're paid) to rewrite any core files. Period.

 

Hi

 

They do not overwrite core files, instead they write to the core! The 2 are not the same.

We always strive to achieve this, and all of our payed modules comply with this rule.

 

And yes, as we stated, installing from BO as a ZIP is very nice, but cannot be done just overnight for all modules! Some are way too complex and advanced to achieve this in a short period of time. We also agree to obey this rule, but trough several upgrades with a slower process, where we can add new features also, not just rewriting the mod itself.

 

Cheers!

Share this post


Link to post
Share on other sites
They do not overwrite core files, instead they write to the core! The 2 are not the same.

 

As a merchant (and definitely not a developer) could you explain the difference?

Share this post


Link to post
Share on other sites

As a merchant (and definitely not a developer) could you explain the difference?

 

Hi, yes:

 

1) Overwrite means that a module replaces files originally belonging to the Prestashop package. These could be php files from the root or controllers directory (e.g. header.php, authentication.php, MyAccountController.php etc), or could be tpl or php files belonging to default Prestashop modules.

For example: if some developer wants to enhance or change the "Featured products" module for homepage, in this case he will edit the default module, repack it under same name and offering it as a download, forcing novice users to overwrite their original module. And the worce thing is, that by deactivating module or upgrading Prestashop, you will loose the changes! Very uncomfortable situation.

 

2) Writes to the core in fact means, that the module adds and uses files outside the modules directory (can be the root or themes), but these are all NEW, non existing in the default Prestashop package!

We will use as example a module developed by us, called "Ask for a Quote", what "writes/adds" files in four places: modules, themes, admin and root but during upload, user will never be asked to overwrite files!

And to go even deeper: the module has a quote submit page very similar to "One page checkout" but instead of modifying the default one and forcing clients to replace it, we built our own "order_opc_askforaquote.tpl"

Deactivating module will NOT cause any changes to your shop and will take you back to the exact state you were before install!

 

But why write/add files to the root (core) directory?

One reason would be SEO URL, or the lack of this, as lots of shop owners don't activate it (and even if they do, custom values must be defined and added to htaccess for third party modules).

 

Example of the above if SEO URL is not activated:

  • a.) all files are in "modules", contribution does not writes to the core. Accessing it could lead in browser title bar to a URL like this:
    http://www.yourwebsh...e/my_quotes.php
    Basicly this shows the full path to people (dangerous), plus is ugly.
  • b.) module writes to the core. Accessing it will lead to a URL like:
    http://www.yourwebsh...m/my_quotes.php
    How better and nicer is that?

 

Hope it is clearer now!

Edited by Presta FABRIQUE (see edit history)

Share this post


Link to post
Share on other sites

So, they deny the publishment of new modules which include core modifications? Really?

This is insane! As a developer, i totally agree with you. Many of my modules use a simple override to add new features, and they (prestashop) can't just drop in excuses to reject modules, cause their software is limited, and we are forced to override to add the smallest new feature.

 

Fabio

Share this post


Link to post
Share on other sites

Thank you for your very detailed answer Presta FABRIQUE.

 

I'm sure that took a lot of time to write and I'm grateful for it (as I'm sure others will be as well).

 

I now see a LOT clearer what issues you are referring to.

 

@Nemo1

 

and they (prestashop) can't just drop in excuses to reject modules, cause their software is limited, and we are forced to override to add the smallest new feature.

 

I'm going to try to respond this without coming across as rude. :)

 

#1) "They" can do whatever they like as it's their software and they are a business that exists to make a profit.

 

#2) You are not "forced" to do anything. You can walk away from Presta this very second and never look back (not that I'm asking you to).

 

Just my .02 :D

Share this post


Link to post
Share on other sites

Thank you for your very detailed answer Presta FABRIQUE.

 

I'm sure that took a lot of time to write and I'm grateful for it (as I'm sure others will be as well).

 

I now see a LOT clearer what issues you are referring to.

 

@Nemo1

 

 

 

I'm going to try to respond this without coming across as rude. :)

 

#1) "They" can do whatever they like as it's their software and they are a business that exists to make a profit.

 

#2) You are not "forced" to do anything. You can walk away from Presta this very second and never look back (not that I'm asking you to).

 

Just my .02 :D

1) They should make the software better then

2) yes, we are, cause if a client wants a specific feature we have to give it to him/her. And in most cases, the only way is to use overrides since Prestashop has such a bad SW Architecture

Share this post


Link to post
Share on other sites

Thank you for your very detailed answer Presta FABRIQUE.

 

I'm sure that took a lot of time to write and I'm grateful for it (as I'm sure others will be as well).

 

I now see a LOT clearer what issues you are referring to.

 

Thanks!

 

@Nemo - we would like to keep the discussion focused on the issue it started from. Thanks for understanding!

Share this post


Link to post
Share on other sites

Hi

 

No PrestaShop Addon Admin reads these topics? We would REALLY like to know more about the issue than just that short sentence we got after submit.

 

Thanks a lot!

  • Like 1

Share this post


Link to post
Share on other sites

I can certainly understand the original OP discouragement about PrestaShop changing the rules about modules must support install/uninstall/enable/disable. I can see that this is an improvement however for the end user simply because I bought a couple modules I thought would just click in that turned into a nightmare to intall, copying files, form installation folders to live folders etc...I've also spent more time writing logic for install/uninstall/enable/disable than the actual hack. And in the end it was worth it both for me as I don't have to support moudle installations but also for my customers, who like all shoppers like the click click experience.

 

What I do have a bit of an issue with, and it's just as much my fault for not contributing as a community member, but the developers guide for module writing, last time I check didn't cover basic functions that are click-able by the customer. This left us developers out there on our own trying to figure it out, like reset executes a modules uninstall/install logic...

 

I've even considered getting out of writing my own modules and just offering services of taking developer hacks and building modules for them...it's grunt work...and I am a grunt....

Share this post


Link to post
Share on other sites

I think the issue is with what people want the modules to do. Some things you can just install a module thru the backoffice and accomplish. Other things you have to use overrides. It really just depends on how tied into the code something you are trying to change is. You have to think of the core like a car engine, some things you can just bolt on to get more power. But if you are looking for real power you are going to have to take the engine apart and change things.

  • Like 1

Share this post


Link to post
Share on other sites

I think the issue is with what people want the modules to do. Some things you can just install a module thru the backoffice and accomplish. Other things you have to use overrides. It really just depends on how tied into the code something you are trying to change is. You have to think of the core like a car engine, some things you can just bolt on to get more power. But if you are looking for real power you are going to have to take the engine apart and change things.

 

This is exactly what we are trying to say. Some modules simply cannot be written to use Prestabox - even if they don't use overrides or owerwrites!

 

Now regarding our question above: we finally got an answer (after 2 weeks) saying that they know it is unpleasent for us, but this is required to standardize the process. OK, another general answer, as we did know and stated this already above, when looked at the problem from the user / buyer POW.

 

But this raises another question - and PLEASE FELLOW DEVELOPERS DO NOT TAKE IT BADLY - it is unfair to see that our module is rejected, when Addons is full of other ones NOT Prestabox compatible. If ours is removed, remove ALL, including the ones built by the Prestashop team!

 

Or, add a feature that lets buyer know, that module is NOT Prestabox compatible, they buy at own risk, and have ALL these cases require a complete, understandable, comprehensive install guide - which is of course verified by the Prestashop team.

 

Quite simple, but not the easier way of course, since a simple reject is faster and easier.

Share this post


Link to post
Share on other sites

Is it time for a new, independent, like "Addons" repository of modules?

  • Like 1

Share this post


Link to post
Share on other sites

No PrestaShop Addon Admin reads these topics? We would REALLY like to know more about the issue than just that short sentence we got after submit.

Yeah, one, two or maybe three words would be nice. At least as a participation that you are not indifferent to everything.

Share this post


Link to post
Share on other sites

 

 

Or, add a feature that lets buyer know, that module is NOT Prestabox compatible, they buy at own risk, and have ALL these cases require a complete, understandable, comprehensive install guide - which is of course verified by the Prestashop team.

 

 

YES!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Then the customer can determine if they are savvy enough to install it.

  • Like 1

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

×
×
  • Create New...

Important Information

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