Jump to content

I need a fair technical validation


MEG Venture

Recommended Posts

Hi

 

For the last two weeks, I am trying to get one of my new modules technically validated, and it started to get tedious.

 

I use the Prestashop validator and clear all the errors, but I can't succeed when it come to the Addons technical validation. 

 

The main errors I fix are the errors which are also existed in the default Prestashop installation. Like escaping variables, casting, etc. I replace some of the default theme files by changing some lines and Prestashop Addons team asks me to fix their theme's security leaks everytime. I have done this so far although I don't think it is fair. I am sure other developers experience the same unpleasnt situation.

 

But this time, it is a little bit different. I write this post for you to assess my situation. 

 

Except some optimization and standards errors, all are fixed except 1, and from my previous technical validations, I know that clearing the security errors and errors are essential, not the others. I use the same original controllers file coding of Prestashop 1.6.0.11 (controllers>admin>AdminProductsController.php line 4051), but the Addons team keep saying that there is a security error.

 

So why Prestashop doesn't fix it?

 

/override/controllers/admin/AdminProductsController.php
  • Hard coded images types are forbidden 74. ————————————————————————————$data->assign('imageType',·'small_default');

 

 

 

Link to comment
Share on other sites

Because they apply a double standard, which I have complained about for many months.  They will not admit that their own developers produce garbage code that would not pass their own 'standards' and technical validation, but choose to ignore it.

 

On the flip side, I guess that is why their modules and new releases are riddled with defects and bugs.  Which of course they leave to the community and contributors to fix for them.

 

So how do they expect you to deal with this?  Are you supposed to use constant variables?  And if so, are those constants defined in all versions of Prestashop that the module supports?

  • Like 2
Link to comment
Share on other sites

On the flip side, I guess that is why their modules and new releases are riddled with defects and bugs.  Which of course they leave to the community and contributors to fix for them.

 

I don't know where that comes from, but that's really really far from the truth. Anyone saying that "new releases are riddled with defects and bugs" must not have read 1.6.0.11 and 1.6.0.12 changelogs... It doesn't take a code genius to realize that new releases don't introduce new bugs but fix hundreds of bugs.

 

As for "Which of course they leave to the community and contributors to fix for them" 95% of them bugs are reported on the Forge (for our in-house developers to fix) and the remaining 5% are reported directly on Github (with the appropriate patch and pull request), and we feel lucky and humbled that the Community is so really much dedicated to the cause of fixing bugs.

 

All in all, it saddens me that you feel that way but your post is unfair and inaccurate. 

  • Like 1
Link to comment
Share on other sites

All in all, it saddens me that you feel that way but your post is unfair and inaccurate. 

Funny and ironic that I feel the same way about the addons validations.  There is a double standard being applied by the addons team, and we the contributors are being held to a higher standard than Prestashop's own developers.  The default bootstrap theme and Prestashop's own modules do not adhere to the same standards.

 

I guarantee I can take many of the Prestashop modules, and have them fail technical validation.  I can also take the default bootstrap and have it fail as well.

 

As for my statements about new releases, perhaps I am being too harsh, certainly they fix many issues.  But unfortunately I believe you are being blind to the truth shown in the community forums and bug reports for the latest release.  It really speaks for itself.

  • Like 1
Link to comment
Share on other sites

There is a double standard being applied by the addons team, and we the contributors are being held to a higher standard than Prestashop's own developers.  The default bootstrap theme and Prestashop's own modules do not adhere to the same standards.

 

There are no low standards and higher standards, there are former standards and new standards.

 

 

We think it's pretty fair to require of contributors that they develop modules according to new standards as we, on our end, go by these new standards as well for software improvements and modules development.

Link to comment
Share on other sites

There are no low standards and higher standards, there are former standards and new standards.

 

 

We think it's pretty fair to require of contributors that they develop modules according to new standards as we, on our end, go by these new standards as well for software improvements and modules development.

Fair is to enforce the same rules to everyone (contributor and prestashop developers), but until I see that actually occur, then it is just a double standard and only we the contributors are being held to it (call it new or higher, it really is the same in the end).

Edited by bellini13 (see edit history)
Link to comment
Share on other sites

I don't know where that comes from, but that's really really far from the truth. Anyone saying that "new releases are riddled with defects and bugs" must not have read 1.6.0.11 and 1.6.0.12 changelogs... It doesn't take a code genius to realize that new releases don't introduce new bugs but fix hundreds of bugs.

 

As for "Which of course they leave to the community and contributors to fix for them" 95% of them bugs are reported on the Forge (for our in-house developers to fix) and the remaining 5% are reported directly on Github (with the appropriate patch and pull request), and we feel lucky and humbled that the Community is so really much dedicated to the cause of fixing bugs.

 

All in all, it saddens me that you feel that way but your post is unfair and inaccurate. 

 

Hi Xavier

 

Thanks for your answer.

 

I didn't want to start a discussion here. My concern is that developers shouldn't be urged to fix all validator errors until that error is also fixed within Prestashop default. I understand that Prestashop tries to reach to the best and also wants developers do as well, but if this is a transition process, we need some tolerance from the Addons team. I shared the validator report above. You'll see that there is only one error and this error does also exist with the new released 1.6.0.11. So instead of a direct decline, we could be kindly asked to fix it in the next update of the module.

 

Technical validation is not a quick process and to be urged to start over each time with a simple message like below, makes us think that Prestashop Addons Team's technical validation is not held as professsional as we believe. Prestashop and customers are not the only one who need to be satisfied. We, developers, need some satisfaction, too.

 

My two cents...

 

Prestashop technical validation default response:

 

 

 

We noticed some warnings during validation process. In order to improve the quality of new modules available on our marketplace, we invite you to check your module with validator.prestashop.com and improve as much points as possible.
  • Like 2
Link to comment
Share on other sites

MEG Venture, great response.

 

I would also ask that the Addons team provide a document/wiki/web page/something that shows what all the standards are.  The validator tool is a great way to automate and enforce those standards, but still I have no idea what all the standards are in a concise and transparent way.

Link to comment
Share on other sites

Hi Emmanuel,

 

Thanks for commenting.  Since it seems my other question was over looked, could you also comment on the expectations for modules that have to support PS v1.4.

The following is great for PS v1.5 and v1.6, however in PS v1.4 ImageType does not contain a function named 'getFormatedName'

 

 

This is the answer to your question: https://github.com/PrestaShop/PrestaShop/commit/2dc8545f8836903a50b000b35fb8349b4d1d17c3

 

You need to use:

$data->assign('imageType', ImageType::getFormatedName('small'));
Link to comment
Share on other sites

for 

 

Hi Xavier

 

Thanks for your answer.

 

I didn't want to start a discussion here. My concern is that developers shouldn't be urged to fix all validator errors until that error is also fixed within Prestashop default. I understand that Prestashop tries to reach to the best and also wants developers do as well, but if this is a transition process, we need some tolerance from the Addons team. I shared the validator report above. You'll see that there is only one error and this error does also exist with the new released 1.6.0.11. So instead of a direct decline, we could be kindly asked to fix it in the next update of the module.

 

Technical validation is not a quick process and to be urged to start over each time with a simple message like below, makes us think that Prestashop Addons Team's technical validation is not held as professsional as we believe. Prestashop and customers are not the only one who need to be satisfied. We, developers, need some satisfaction, too.

 

My two cents...

 

Prestashop technical validation default response:

for images hardcoded, my modules pass the validation

 

public function getImages($type)
{
$sql = '
        SELECT *
        FROM '._DB_PREFIX_.'image_type it
        WHERE it.'.$type.' = 1';
return Db::getInstance()->ExecuteS($sql);
}
 
where type is the image format
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...