Jump to content

[Seller Account] Technical Validation declined


frosticek

Recommended Posts

Hi guys,

Not sure if any of you who are selling themes on prestashop store got same answer as me, but theme was multiple times declined in technical validation.

 

Last message:

"Thank you for your new contribution. We notice potential security issues 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. Regards"

 

I am not able to understand quality of people that validates themes & modules. Prestashop validator is just for modules or am I wrong?

 

In previous message man that validate theme told me that in theme file there are unescaped variables, but did not told:

- how to solve

- where is problem

 

I have kindly asked this man to send me link to documentation or information about such change (month before was everything ok), or some information with detail description, or where can I get some info about it. For sure, no more answers.

 

Problem is that there are hundreds of lines in theme files and thousands of variables, it is not possible for human to check every variable here.

 

As bonus, each validation takes about 2 days...

 

So guys, is there any tool, information, or something that could help?

Did you met with similar response from prestashop team?

 

Thanks for response ;)

Link to comment
Share on other sites

Want to really blow your mind.  Now go into the Prestashop default-bootstrap theme and identify all the places that they do not adhere to their own policies... I believe its called double standard

 

Welcome to the lovely world of validation, where PS enforces silly validations, and happily accepts modules/themes that actually do not function, or have severe security flaws.

 

I would love to know what THEME validator tool they are referring too

Link to comment
Share on other sites

@bellini13

Well, I would like to know why they are doing this. Called "improving security" is in my mind bullshit, without full documentation, reffering to some explanation or giving you detail error description with places where it is, that is more negative stuffs to seller and in fact lowering competition and final quality of service :/

Link to comment
Share on other sites

@samyha

Thanks, really appreciated.

 

Today I go again very valuable reply from prestashop team.

Question: - I suppose there are some variables that are not escaped, but there is not tool I could check it with, please send me details list of issues you found also with place in which file on which line issue is.

Answer: However, you still have some security errors that you can correct

Link to comment
Share on other sites

Hello,

 

Thanks for your update. However, I need to have the whole conversation beetween you and our developer, so could you send me your mail address please? This way I'll try to get someone to give you clear explanations about your issue and how to solve it. Thanks. 

 

Edit 02/09 - Thanks for the conversation history, one of our developers will get back at you with more explanations about this issue. 

 

Have a great day! 

Link to comment
Share on other sites

Hello Frosticek,

 

I see that Bellini is in good shape, as usual ;)

 

Anyway, i've double checked your submitted zip files and yes there are errors. But first, YES the public validator only works for modules :( However in our private validator, we used the core classes to parse themes as well. I just talked to the main developer of the public validator about that. News as soon as possible.

 

So, about the errors, first you packed your module inside a zip, WITHIN the theme zip. Major error, the install is just impossible. You should read the documentation for the theme zip structure :

| doc

| modules -> your_modules_directories -> files

| themes -> laura -> files

 

About the unescaped variables, we do not explain further because it's smarty and google has more information about that than us. You can take examples from default theme TPLs about unescaping variables. We dont also give files and lines because we have too many informations from the validator. Some work has to be done by you guys, right ? ;)

 

I didn't read all the messages sorry. If i missed something, feel free to contact me. Samyha and Xavier can also bring messages up to me if i miss it.

 

cya

  • Like 1
Link to comment
Share on other sites

@Kamel

Thanks for your response.

 

There is extra module (homeslider.zip) because this is extra module delivered with theme so it cannot be placed in themes > laura > modules, how / where should I place it (it is whole module, not overrides)?

Btw. Which documentation are you reffering? I could not find single word about structure of theme zip.

 

About unsecaped variables, I am not asking how to escape variable, but which one is not escaped? There can be more than 2000 times variable used in theme file, how is it possible to check it one by one? Such information is simply required. Is it more work for you to copy output from validator or more work for developer to search for weeks in template files where is unescaped variable left?

 

//Edit: Default theme has not all variables escaped

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

The 1.6.0.* already has a module named the same. So if you developed a full module on your own, your best move would be to rename it (and all configuration needed) so you don't have conflicts with the native one. Then, place it like this :

| doc

| modules -> yourhomeslider -> files

| themes

 

Well actually, you won't have to create the theme zip yourself. Just use the theme menu on your prestashop to generate the zip file.

 

About the errors, now that your module isn't under waiting status, i can't have the error list. The validator's report is deleted after declining or accepting the module. Sorry :(

Link to comment
Share on other sites

I think what is failing to be recognized is that Prestashop's own default-bootstrap theme has variables that are not being escaped...

 

When a developer goes to create a new theme, the first step is to take the default-bootstrap theme and then build off of that.  So the developer of the theme is already at a disadvantage, due to Prestashops own doing...

 

Why the double standard?

Link to comment
Share on other sites

Well it's not because the team forgot to add security matters that your basis has to be the same. Take the best and do your thing :)

 

Also, most of the variables are escaped/cast earlier in the controller or on the same tpl. Anyway, it's not a good thing.

 

In the validation on Addons, we are not that straight. If the module/theme contains a few things, basic and not dangerous for the customer, it will be ok.

Link to comment
Share on other sites

Well, the double standard still applies. 

 

If it is ok for Prestashop to develop a theme without the escaping of a smarty variable, and they can release that code in a release version (ie.. PS v1.6.0.9), then it should be acceptable for an theme developer to as well.

Link to comment
Share on other sites

@bellini13

You are correct, there are 2 standards:

- prestashop team - theme does not need to contain index.php in each folder (it is new as well), variables does not need to be escaped

- all others - index.php & variable escaped is a must...

 

Little sad.

Link to comment
Share on other sites

Hello Samyha and Kamel,

my new theme was twice declined. After first decline I tried to fix all errors according to public validator (many time it was incorrect first line of comment in php file (license), same issue in index.php copied from other default Prestashop modules and some unescaped variables which I tried to fix). Today I received the 2nd decline with attached txt file with examples. It containes many unescaped variables in theme and some in 2 other modules. My theme is derived from default Prestashop theme so default theme has the same issue and modules are clones of your modules (slider and facebook block) so again your modules have the same issue. 

I can fix the modules, but do I really have to escape 80 variables (from the log I received, but it can be much more I guess) in theme that you don't? Also I can't imagine maintaining upgrades of my themes for new Prestashop versions with so many changes compared to default theme.

 

Please let me know. If you want more details about the theme, please let me know.

 

Regards,

 

Jiri

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

@webplus

Unfortunately you have to.

I was talking to few people from here, and they are really not willing to help, or they just do not care.

 

Question: Default theme do not have all variables escaped, why my must have?

Answer: Yes you need, we are trying to improve our service

 

... but not in own garden...

 

But, you are lucky man that you got error output file, to me, just @Kamel was so kind and send it to me :/

 

Simply it sucks.

Link to comment
Share on other sites

I still hope they will reconsider this. I would understand if they do these changes in default theme and then force it from theme developers too. I really can't imagine upgrading my themes for new versions now. You will not be able to compare the files with default theme and copy those files that were not changed. Then, for example in slider (I cloned default homeslider module), there is {$slide.description} variable in tpl file. If I escape it, html doesn't display correctly.
Really frustrating...

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

I know UTF-8 modifier, but it doesn't work in this case (my cloned module) - it displays raw html then. Same issue is in default homeslider module (in default theme located in \themes\default-bootstrap\modules\homeslider\homeslider.tpl). Changing                                
<div class="homeslider-description">{$slide.description}</div>

to
<div class="homeslider-description">{$slide.description|escape:'htmlall':'UTF-8'}</div>
cause displaying raw html in slide.

strip_tags seems to be the right modifier in this case.

 

You are right this is rather my issue to solve something like this, although it's in default slider too. But it's huge extra effort to "fix"/escape whole default THEME variables while creating new theme and keep this in all upgrades. I hope Prestashop can reconsider this and force this from developers only after fixing it in default theme.

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

Hello everyone,

 

Thank you for your messages and raising this issue. We do care about your opinion and when there is a problem like this one, we do our best to find a solution.

 

In this case, your are totally right, there is a 'double standard' since our own theme is not totally valid with our rules. We are doing our best to fix it every day but we also have a lot of work on a lot of things to make a better PrestaShop. So it could take some times :)

If you want to help, please make a pull request. We will be happy to have you as core contributors :)

 

So, we have decided to make things easier for you on theme validation. Starting next week, we are going to be more flexible about this point!

 

Just a quick reminder about theme validation :

- The new rule applies only on the theme files, not on overrides in your theme.

- You need to have an index.php file into every folder.

- You need to validate every module separately with the validator.

 

We are really sorry about that and I hope you will understand our shift to improve the modules and themes quality.

 

I invite you to resubmit your themes and if you have any question, please tell me, I will answer you asap :)

 

Regards,

Emmanuel

  • Like 2
Link to comment
Share on other sites

I was not talking about htmlall modifier ;)

{$slide.description|escape:'UTF-8'} will work fine ;)

 

 

I know UTF-8 modifier, but it doesn't work in this case (my cloned module) - it displays raw html then. Same issue is in default homeslider module (in default theme located in \themes\default-bootstrap\modules\homeslider\homeslider.tpl). Changing                                
<div class="homeslider-description">{$slide.description}</div>

to
<div class="homeslider-description">{$slide.description|escape:'htmlall':'UTF-8'}</div>
cause displaying raw html in slide.

strip_tags seems to be the right modifier in this case.

 

You are right this is rather my issue to solve something like this, although it's in default slider too. But it's huge extra effort to "fix"/escape whole default THEME variables while creating new theme and keep this in all upgrades. I hope Prestashop can reconsider this and force this from developers only after fixing it in default theme.

Link to comment
Share on other sites

  • 2 months later...

Hello everyone,

 

Thank you for your messages and raising this issue. We do care about your opinion and when there is a problem like this one, we do our best to find a solution.

 

In this case, your are totally right, there is a 'double standard' since our own theme is not totally valid with our rules. We are doing our best to fix it every day but we also have a lot of work on a lot of things to make a better PrestaShop. So it could take some times :)

If you want to help, please make a pull request. We will be happy to have you as core contributors :)

 

So, we have decided to make things easier for you on theme validation. Starting next week, we are going to be more flexible about this point!

 

Just a quick reminder about theme validation :

- The new rule applies only on the theme files, not on overrides in your theme.

- You need to have an index.php file into every folder.

- You need to validate every module separately with the validator.

 

We are really sorry about that and I hope you will understand our shift to improve the modules and themes quality.

 

I invite you to resubmit your themes and if you have any question, please tell me, I will answer you asap :)

 

Regards,

Emmanuel

index.php must be in all directories of the theme? lime css/modules/blocksearch too?

Link to comment
Share on other sites

having the index.php in each folder just prevents people from seeing the directory listing (assuming your hosting environment is configured to show a directory listing). 

 

For CSS, JS and image files, it really does not matter much since the contents of those files can easily be seen.  However for .tpl files in those folders, it is better to have .htaccess deny rules that would prevent users from seeing the content, had they guessed their names.

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...