Limitations of Styled theme and usage of Classic

[jbalsas]

Hi everyone!

For a long time, usage of the Classic theme as a starting point has been discouraged. We keep seeing this question pop up from time to time, so we're looking for feedback on current usage and limitations of the Styled theme and reasons to start from Classic.

Some answers we're looking for are:

• What type of themes are you building on top of Styled (if any)?
• What type of themes are you building on top of Classic (if any)?
  • How many additions/overrides/resets are you applying?
  • How are you managing changes in the upstream theme?
• What specific things do you need from Classic that's lacking in Styled?
  • Is it a default template for navigation?
  • Is it the color scheme?
  • ...

Waiting to hear from you!

Thanks!

[caneta]

For a long time, usage of the Classic theme as a starting point has been discouraged. We keep seeing this question pop up from time to time, so we're looking for feedback on current usage and limitations of the Styled theme and reasons to start from Classic.

I don't think starting from styled has some kind of limitation: I use it 99% of the times I create a new theme and I'm ok with that.

* What type of themes are you building on top of `Styled` (if any)?

Every theme I create for customers: it's a valid starting point to create my own css, js and templates.

* What type of themes are you building on top of `Classic` (if any)?

Only for study purposes: I would like to have a comfortable way to have a classic theme starting point to understand how this is build and how I can modify it.

  * How many additions/overrides/resets are you applying?

For styled themes, I rewrite a lot of templates (portal_normal.ftl, navigation.ftl, portlet.ftl) and I add almost everything inside the css and js directories. Usually, I use _custom.scss to import everything and I overwrite main.js as described above

  * How are you managing changes in the upstream theme?

Usually I copy files I need to overwrite from the build directory after a gulp build into my src directory.

* What specific things do you need from `Classic` that's lacking in `Styled`?

Nothing in particular.

[ferdez]

IMHO I think the default liferay theme should be loaded with structures and templates to create essential widgets like carousels, photo galleries, embedded videos, geotagged content, etc.

For many years now, the main disappointment we have when installing a fresh liferay is how much work you still have to do afterwards to build a simple website with a modern look.

Marcos Castro has been doing an excellent job with theme samples but it's not bundled with the distribution.

HTH

[severinrohner]

My starting point is the classic theme, but I remove/change a lot from the classic stuff, because the css use:

• many id's
• px instead of %, rem or em
• strong selectors with many classes (nesting in scss)
• less variables

From the classic I use the JS for login in popup. The styles are more a starting point and a change it to my needs, mostly because the reasons above and because the needs of the current design.

Mostly I change a lot in a theme, fonts, colors, button style, breakpoints, grid, ... Sometimes it's very hard, because if I change a global Liferay variable or add global styles to have a own font in the whole portal, a lot of Liferay stuff will be broken. IMHO, one reason is, that Liferay use a lot of px.

In the Liferay Lexicon are some helps how to change a theme, but for me this is to less. It would be useful to have a guid, which variable can be change, which not, or how to change the default theme. E.g. how can I change the look and Feel of my page without targeting the portlet configurations.

I use own/modified template for nearly every thing. (portal_normal, navigation portlet, AssetPublisher, journal article, category navigation, ...)

We also add custom gulp task for css and js linter, this is very comfortable since Liferay 7.

[ovanderzee]

I always start my themes upon Styled. Our customers always seek for their own identity, and that is why i choose the least opinionated one. I might choose Classic when I would theme would truely be a logo and a color.
I often put together a reset stylesheet to change some rules set by alloy-ui. In _custom.scss I always import my projectstyles within a '#wrapper.container-fluid' selector, to minimize style-bleeding. Also, I often use _aui_variables.scss to set the path for alloy's fontawesome when that covers my icon needs. I often add icons to lexicon. I ofter add the pagename and layoutset-name to the classname of the body. I always add autoprefixer and mq-packer to the gulp task.

[faragos]

We mainly used the styled version of the Liferay-Theme. One day we decided to do our own base-theme, because everytime we set up a new one we do stuff like: Adding linters, adding autoprefixer, removing unnecessary code, creating filestructure for CSS, adding some utils in the custom inits and so on. We took the styled as a base and added some parts for the classic one. I think we took out the navigation styling. I already had the idea to start with no Liferay styling, because stuff like styling every label or such strong selectors that you can only overwrite them when you have like 6 classes are kinda annoying.

The reason why I would take the styled again over the classic one is because you have to overwrite less and have more control.

[duracell80]

All of the below ...

IMHO I think the default liferay theme should be loaded with structures and templates to create essential widgets like carousels, photo galleries, embedded videos, geotagged content, etc.

I had to spend 6 months creating these, they should have already been there. The next user will have to do the same and then you have 700 users all trying to figure out how to make something that should have already been there.

What specific things do you need from Classic that's lacking in Styled? Is it a default template for navigation? Is it the color scheme? ...

It started out as being color scheme yes. Overall we were happy with the theme changes from 6.1 to 7.0 and didn't need to make our own stuff. Also we were sold heavily on Lexicon as being a framework and language to design with, so why would we choose not to use Lexicon?

We also don't run our portal as a web site (I would always choose better tools like Wordpress for external sites). Our usage is Intranet and while we have design standards, we're not putting out highly customized portals or CRM's so we can stick to baseline. Honestly our theming is very close to classic so for us it just makes sense to keep in step. We do not have a highly customized theme.

If I would go down the path of _unstyled and build my own theme entirely that's a boat load of work that we don't get given time for in our project timelines to create. Going with _styled (as recommended) allowed for a lot of the base work to already be there. Going back to things that should already be there as mentioned above.

Customization isn't supported by LESA so you have to go there as an enterprise and well do we go alone on this journey or do we partner with the vendor? If we customize the vendor locks us out of support. Customization is the devil. I couldn't stay in sync with fixpacks if I wasn't close to base level DXP.

I would always take styled. I also keep classic on the server and hide it from our users, because it helps figure out well did I cause this issue or is this issue down to the vendor? So the comparison is helpful. Finally themes still suck in Liferay for developers. Notice how many themes are out there for Wordpress and how little there are for DXP? The separation of Admin and Site theme helps.

But again our use case isn't to produce wild layouts or hook in to commerce solutions or any of that, primarily our use of DXP is for publishing and information sharing, there is no need for us to produce a wild theme and again I'd choose Wordpress over DXP to make a pretty site. I would absolutely choose anything other than DXP to create a nice looking site because Liferay is overkill for a simple site or even a series of simple sites.

[duracell80]

What specific things do you need from Classic that's lacking in Styled?

A comprehensive "already there" series of variables in _aui_varibles.scss so that I can change color schemes and make good use of SaSS without needing to run around and debug 300 partials. Again stuff that should already be there, it should be developer friendly. Take 7.1 theme ... add our color scheme, it shouldn't take 1 month to do that, more like an hour or two at best.

How many additions/overrides/resets are you applying?

Honestly, fixing portlet CSS is my biggest use of the theme.

[duracell80]

Kill theme contributors. These are overkill. Bring that stuff back into the theme.

[jbalsas]

For anyone watching here... we know it's long overdue, but we're planning to work on some version of this prior to 7.3 (and likely backporting it to older versions of the toolkit).

I've created Add support for "Classic" extend to add the possibility to somehow get that look and feel out of the box quickly.

Please, head over there if you want to provide any additional feedback on the matter!

Thanks everyone for your participation! :)