Welcome to this forum!

[Antoine F]

Hello everyone!

The purpose of this project is to better assist contributors in the accompanying (yes, you!) when creating themes 1.7. 

 

Why you should develop templates for PrestaShop 1.7 right now:

- Templates creation is becoming easier thanks to our new Starter Theme and dedicated documentation. 

- It is a huge opportunity for you to be one of the first among our 1.7 templates catalog: the sooner you offer templates for 1.7, the bigger your visibility will be!

So take part of this private discussion with our great Australian Ambassador Adrian who will be glad to help you develop your first 1.7 template! 

 

Feel free to create your own posts & share your opinion in this forum. We will share all the posts with the dev team. 

 

Best,

Antoine

[shacker]

Hi. Thanks for the Help. The documentation is this?: https://github.com/PrestaShop/docs/tree/master/themes

[Antoine F]

Hello Shacker, I'm not sure. I'm going to ask the team & I'll get back to you with the answer.

 

Edit: Yes, this is the dedicated documentation.

[Dreamtheme]

Hello, nice topic. I want to ask several questions.

 

1. What software dev environment will you recommend for 1.7.x PS themes ( SCSS, Scout, Sublime, DW etc ) - Any complete package? a guide on that will be good.

2. Any video guide on how to export/create theme based on the starter theme will be very helpful.

3. As in 1.7 there is no "theme configurator" module anymore, what's the best course to handle multiple colors of the theme and handling banners?

4. Is the starter theme based on bootstrap, if not what's the best way to integrate it?

 

That's for now thanks.

[iqit-commerce]

Hello

 

1. When Prestashop module validiator will be updated to check for ps 1.7 coding standard ?

2. How to make module compatible with ps 1.6 and ps 1.7 which will be valid with prestashop module validiator ? I know there is some small doc about that, but it is to genera. For example naming of files dedicated for ps 1.7 and ps 1.6, it is enoguh to add suffix _17 to file name for example and then tpl will be validiated with 1.7 rules ? Now validiator complains about no escaping smarty variables

[Antoine F]

Hello and thank you for your questions.

 

I'm going to gather & share them with the dev team. I'll post the answers here as soon as I get them.

[iqit-commerce]

Also

 

3. It will be possible to provide two module package files on addon store? I would prefrer to deliver ps 1.6 version module separatly instead of using nasty workarounds. Currently we can upload only module zip file, would be nice to be able to provide some additonall file too

[Julien Bourdeau]

Hello, nice topic. I want to ask several questions.

 

1. What software dev environment will you recommend for 1.7.x PS themes ( SCSS, Scout, Sublime, DW etc ) - Any complete package? a guide on that will be good.

2. Any video guide on how to export/create theme based on the starter theme will be very helpful.

3. As in 1.7 there is no "theme configurator" module anymore, what's the best course to handle multiple colors of the theme and handling banners?

4. Is the starter theme based on bootstrap, if not what's the best way to integrate it?

 

That's for now thanks.

 

1. you should create a thread dedicated for this I would be happy to share my preferences and I guess many people can join in.

2. Not yet, but I'd like to make one.

3. The best way so far is to create a custom module to do that. Every developer will create their own. We would like to have a special kind of module, a "theme option module"

4. Nope. StarterTheme is agnostic, there is no lib bundled at all. The best way will be to use npm to get bootstrap 4, then import it in your theme.css and theme.js. Then modify templates to use bootstrap classes.

 

 

Hello

 

1. When Prestashop module validiator will be updated to check for ps 1.7 coding standard ?

2. How to make module compatible with ps 1.6 and ps 1.7 which will be valid with prestashop module validiator ? I know there is some small doc about that, but it is to genera. For example naming of files dedicated for ps 1.7 and ps 1.6, it is enoguh to add suffix _17 to file name for example and then tpl will be validiated with 1.7 rules ? Now validiator complains about no escaping smarty variables

 

1. Thomas is working hard on the module validator right now, it should be in production soon.

2. Having a module compatible with both version is a **very very very very bad idea**.

 

1.6 will be maintained for a long time but there is no new features and such so your module shouldn't require much modification. Since 1.7 is a major version, loads of things have changed, like PHP version for example. There is also loads of great new features for front office: widgets, smarty is automatically escaped in 1.7, many smarty functions has been removed. 

 

If you want to have your module compatible, it will be hard, plus you won't be able to use ANY new feature (for example because namespace will break on PHP < 5.4. If you want to I believe the best way will be to have 2 modules.

[iqit-commerce]

2. Having a module compatible with both version is a **very very very very bad idea**.

 

1.6 will be maintained for a long time but there is no new features and such so your module shouldn't require much modification. Since 1.7 is a major version, loads of things have changed, like PHP version for example. There is also loads of great new features for front office: widgets, smarty is automatically escaped in 1.7, many smarty functions has been removed. 

 

If you want to have your module compatible, it will be hard, plus you won't be able to use ANY new feature (for example because namespace will break on PHP < 5.4. If you want to I believe the best way will be to have 2 modules.

 

Hello,

 

Yes I agree with you on that, that would be better to have two modules. I rewrited my free shipping module and it works nice with both ps versions, but i had to use few if statements for example for price handling etc. But on my other modules which are more advanced it is getting very hard to make it compatible with both ps version. And i would prefer to deliver on addons store two separate packages(.zip) one for ps 1.6 and one for ps 1.7, but currently there is no such possibility. Are you planning to add it?

 

Becouse I do not want to loose a lot of potential customers, for some time there will be still a lot of people who will want to extend own ps 1.6 version. (For example I still receive questions about compilancy with ps 1.5)

For now the only solution is to publish two separate modules,

You must provide some solution on addons page for that, otherwise other devs probably will want to support in one module two ps version which as you said **very very very very bad idea**.

 

I think we should have more flexibily in creation of modules .zip packages which we upload to market.  So when customer will download module from addons he will have folders something like

 

- for ps 1.5

- for ps 1.6

- other (for example i would like to include some sample data for my modules)

Edited September 23, 2016 by iqit-commerce (see edit history)

[shacker]

You know that update modules 2 times  (one for ps 1.6 and one for ps 1.7) is a night mare

 

ANd customers really sometimes dont care about download packages, just download and didnt check if works in  ps 1.6 / 1.7

 

in views we can create a 1.6 / 1.7 folder to make the validator better

[Julien Bourdeau]

Maintaining 2 modules might be complicated but maintaining backward compat' is WAY worse.

[iqit-commerce]

You know that update modules 2 times  (one for ps 1.6 and one for ps 1.7) is a night mare

 

ANd customers really sometimes dont care about download packages, just download and didnt check if works in  ps 1.6 / 1.7

 

in views we can create a 1.6 / 1.7 folder to make the validator better

 

It is not just about validiator of smarty views, there is also needed to check for version in php code, some functions are deprecated, some other are avaiable in ps 1.7 but not in ps 1.6 etc.

 

Maintaining 2 modules might be complicated but maintaining backward compat' is WAY worse.

 

I agree with you on that, ps 1.7 have much cleaner code and nice features(i like js event emmiter very much) and supporting two version of ps at the same time may cause general worse quality of module.

 

So, Julien any plans to support module .zip packages containg more just module itself, or any other solution to deliver same module in addon store for diffrent ps versions?

 

Regards

[Krystian Podemski]

Hey iqit,

 

are you sure that you can't upload few versions of the module on Addons Marketplace?

 

You can offer several zips for a same product with different compatibilities; these different versions will be gathered on the same product sheet. Depending on the version of his/her shop, your customer will be able to choose the right zip.

[iqit-commerce]

Hey iqit,

 

are you sure that you can't upload few versions of the module on Addons Marketplace?

 

 

Hello,

 

Thanks it looks like you are right, I missed that, if it works that way then problem is solved for me

[Krystian Podemski]

Hey Antoine,

 

is there any chance to move this forum somewhere higher? Maybe under Addons section?

[Antoine F]

Hello Krystian,

 

I've talked about it with the Addons team before creating this thread. We will move this forum higher once we get more answers about it (if it's not the case I will move it sooner). We have two developers ready to answer to the questions so if we move it higher now, I'm not sure that they will be able to answer to everyone.

In the end, the objective is to get feedback from the community.

[rocky]

Hi everyone,

 

Just letting you know that I'm watching this forum (along with many others). If you encounter any problems when developing PrestaShop v1.7 themes, please create a new topic in this forum and I'll try to help as much as I can.

[Dreamtheme]

As from the PS dev blog articles, i understand that the main point was front-end developers to be able to create themes much faster then before with 1.7.

However at this point, i think that not only that front-end developers won't make it faster but they will also need heavy backup from back-end developers and creating of bunch of custom modules which will slow down the process greatly and will take more people into it. And as we know that the biggest problem is the short life of the products due to too often versions with drastic code changes, in the end 1.7 at this point seems regression for theme creation compared to 1.6 and previous versions.

 

I hope that PS team will create very good documentation, guides and modules for front-end developers to use and community too, otherwise will be hard.

[Krystian Podemski]

I disagree, codebase in 1.7 is much more clear and simple. Of course is not that easy to work with PrestaShop at first anymore, because you need to understand how webpack works (or how to replace webpack with something different), how to work with asset compilation etc. etc. but... well, such a skills are standard these days.

 

At this moment documentation provides everything what you need to start working on your theme.

 

What specific information do you need?

 

For me it's great that PrestaShop raised the bar of needed knowledge to work with themes creation. I hope this would make themes quality higher.

[Dreamtheme]

I disagree, codebase in 1.7 is much more clear and simple. Of course is not that easy to work with PrestaShop at first anymore, because you need to understand how webpack works (or how to replace webpack with something different), how to work with asset compilation etc. etc. but... well, such a skills are standard these days.

 

At this moment documentation provides everything what you need to start working on your theme.

 

What specific information do you need?

 

For me it's great that PrestaShop raised the bar of needed knowledge to work with themes creation. I hope this would make themes quality higher.

 

I don't mind raising the skill bar, but don't confuse skill with effort.  I mind against the the need in 1.7 to put too much effort in creating themes. Time is money someone said.  With the short shelf life of themes you can't afford to put too much effort in a theme. For example WP themes may take up to 1-2 months for develop, but shelf life is 2-3 years. In PS that is not the case.  We know that 1.7 is a transition version so shelf life in 1.7 will be short too.

 

You have to calculate the effort needed to create a theme vs returns and then decide it if it would be better to create themes for other CMS's. Raising the effort doesn't mean returns will rise too, that's why i ask for PS to minimize the effort needed as much as possible, by creating guides, video guides, modules, starter theme versions and etc. I want our front-end developers to able to create themes fast by themselves not to spend a week speaking with the back-end devs... Why spending 1-2 weeks for developing your own "theme configurator" module when we all can use an already made one? Why spending time implement bootstrap, google fonts and etc when there can be Starter theme version that includes this things. This is a repeatable work which can be avoided.

 

In my company we are around 15 devs and only 2 people are wiling to work with PS, all other prefer other CMS's and don't want to hear for PS. Every major version you have to do almost everything from scratch. We have postponed theme development for PS since January as 1.7 was expected to hit in 2nd q. What's the point in creating theme with shelf life 3-4 months and then start from scratch again when putting the same effort in other CMS can bring you much more shelf life.

 

Everything that i have requested is in my first post here.

[Krystian Podemski]

Sorry, i don't follow. Why you can't create your own theme-framework based on StarterTheme, and use it every time? What's the problem with that? Based on StarterTheme you can create what you want, you don't need to get rid off many useless code like it was in default-bootstrap.

[Krystian Podemski]

Ok i see.

 

Point #1 and #4 are not related to PrestaShop, these are basics of the front-end development workflow. Doesn't matter if you want to use webpack, gulp, GUI or any other task-runner/tool. You can load Bootstrap using npm, you can import it in Sass/Stylus/Less, you can load from CDN. Whatever.

 

Point #2: at this moment there's no export tool however everything is super simple to setup in theme.yml file. How to create theme based on ST? Instruction is in GitHub repository of the StarterTheme

Point #3: I know that Julien is working on it and this is not ready yet, but even tho is not ready "by default" you can now in 1.7 create custom smarty plugins, you can create your base module and create entire configurator by yourself. 

[Dreamtheme]

Sorry, i don't follow. Why you can't create your own theme-framework based on StarterTheme, and use it every time? What's the problem with that? Based on StarterTheme you can create what you want, you don't need to get rid off many useless code like it was in default-bootstrap.

 

The main problem is third-party module compatibility and how often this theme-framework will need to be updated in order to stay compatible.

 

 

Ok i see.

 

Point #1 and #4 are not related to PrestaShop, these are basics of the front-end development workflow. Doesn't matter if you want to use webpack, gulp, GUI or any other task-runner/tool. You can load Bootstrap using npm, you can import it in Sass/Stylus/Less, you can load from CDN. Whatever.

 

Point #2: at this moment there's no export tool however everything is super simple to setup in theme.yml file. How to create theme based on ST? Instruction is in GitHub repository of the StarterTheme

Point #3: I know that Julien is working on it and this is not ready yet, but even tho is not ready "by default" you can now in 1.7 create custom smarty plugins, you can create your base module and create entire configurator by yourself. 

 

Point#1 and #4 are specifically requested because PrestaShop approve themes, and i want "recommended" setup and procedures so there is no surprises later in the approval process. We have been disapproved for code that is made by PS team So that's why.

 

Documentation at GitHub is very basic.

 

Point 3: I know that we can create entire configurator, but then every developer would have to "teach" customers how to use their module, and this is not good especially for theme demos where the potential customer have to "find and learn" where is the option to change something. This may look trivial for you and me, but we had customers who thought that "theme" is an "exe" which he can double-click and next-next-finish install It is much better majority to use one universal one as in 1.6 and also minimize dev work.

[Julien Bourdeau]

As from the PS dev blog articles, i understand that the main point was front-end developers to be able to create themes much faster then before with 1.7.

However at this point, i think that not only that front-end developers won't make it faster [...]

 

Have you actually looked at it? I really don't get how you can say that it's not easier/faster. Look at ANY template in default-bootstrap and compare it to the 1.7 template (either StarterTheme or Classic, I guarantee you'll find it **much** cleaner and clearer.

 

I understand it can be hard to re-learn and it's not always nice to see things changing, but if you make this little effort at the beginning, you'll see that you'll never touch default-bootstrap ever again.

[Dreamtheme]

Is it "still" possible to add and install custom modules as in 1.6 when you adding theme via the back office?

[Dreamtheme]

 

Hello everyone!

The purpose of this project is to better assist contributors in the accompanying (yes, you!) when creating themes 1.7. 

 

Why you should develop templates for PrestaShop 1.7 right now:

- Templates creation is becoming easier thanks to our new Starter Theme and dedicated documentation. 

- It is a huge opportunity for you to be one of the first among our 1.7 templates catalog: the sooner you offer templates for 1.7, the bigger your visibility will be!

So take part of this private discussion with our great Australian Ambassador Adrian who will be glad to help you develop your first 1.7 template! 

 

Feel free to create your own posts & share your opinion in this forum. We will share all the posts with the dev team. 

 

Best,

Antoine

 

 

Seems that no one is looking this forum anymore as there quite a few questions and no one answer.

[Julien Bourdeau]

Is it "still" possible to add and install custom modules as in 1.6 when you adding theme via the back office?

 

Hi,

 

When you install a theme, the custom modules defined by the theme as dependencies are installed.

In 1.7, the theme maker can define what he wants to achieve with modules: enable/disable, hook/unhook, and so on. If there is any special modules, they are bundled with the theme and installed at the same time.

 

Everything happens in the theme.yml: http://developers.prestashop.com/themes/gettingstarted/index.html#theme-yml

 

We thought it didn't make much sense to ask anything to the use at this step. If you want to disable a module afterwards, you can do it in your module page of course.

 

I hope this answers your question.

[Dreamtheme]

Hi,

 

When you install a theme, the custom modules defined by the theme as dependencies are installed.

In 1.7, the theme maker can define what he wants to achieve with modules: enable/disable, hook/unhook, and so on. If there is any special modules, they are bundled with the theme and installed at the same time.

 

Everything happens in the theme.yml: http://developers.prestashop.com/themes/gettingstarted/index.html#theme-yml

 

We thought it didn't make much sense to ask anything to the use at this step. If you want to disable a module afterwards, you can do it in your module page of course.

 

I hope this answers your question.

 

Hi thanks, i have figured out in the docs. However currently there are to topics which need answer.

 

1. How do we put theme key in the theme.yml? Nothing about it is mentioned in the docs.

2. Modules exceptions in theme.yml doesn't work as the syntax explained in the docs, could you please see the two topics about that here in this forum and answer.

 

thanks.

[Julien Bourdeau]

1. How do we put theme key in the theme.yml? Nothing about it is mentioned in the docs.

What do you mean? I don't get it.

 

I'll have a look for the rest.

[Dreamtheme]

What do you mean? I don't get it.

 

I'll have a look for the rest.

 

I ment for the "addons store" theme key. Seems quite a lot of people asked about it, and there is nothing mentioned in the dev docs. Some person have replied that:

 

You can add the theme_key tag under the version tag in theme.yml.

 

So your theme.yml file could look like this:

 

name: jegia

display_name: jegia

version: 1.0.0

theme_key: jdduej383n3uc3n

 

 

Looking forward for exceptions.

[Dreamtheme]

Seems i won't get any answer regarding:

 

Modules exceptions in theme.yml doesn't work as the syntax explained in the docs, could you please see the two topics about that here in this forum and answer.