Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
RE: The future of the Theme
I'd like to ask about the future of the Theme in Liferay. We have these shiny new content pages and things evolve. For example: I believe, the layout templates aren't really necessary with the new content pages anymore (or maybe only for special cases).
What about the Theme? Are there any plans for a "Theme 2.0"?
I'd like to mention a few pain points:
-) Theme deployments cause a hiccup, for a few seconds the standard theme is used. Because of this, we have moved functionality out of the theme to minimize deployments. Most other osgi component deployments are rather smooth or so much faster that nobody notices. Please don't forget that not all customers have clusters.
-) Theme builds are rather slow. gulp watch is somewhat okish, but we have actually moved as much as possible of our js and css out of the theme and use webpack + dev proxy for rapid development.
-) SEO: The theme has several flaws. The canonical urls are often wrong, the h1 "Navigation" tag that's inserted is really weird. Some guy with SEO experience should rework it
-) For non-authenticated users it loads a ton of unnecessary stuff. Yes, I know, this is a hard problem, especially for the general case, but I am sure, improvements are possible.
-) It's unflexible. Why can't I just drag and drop a header fragment and a footer fragment into a page, add a navigation fragment and a login fragment and a language selector fragment ... AND declare: "This is my theme!" I mean, it is basically just a freemarker template + css + js.
-) We often have the requirement to add stuff to the technical header of a page. Add google tag manager, add a verification key, add some open graph stuff. I don't want to deploy the theme for that, I want to be able to have extension points for that. (Maybe there already are, it is sometimes hard to keep track of new features ;) )
-) Upgrades: With each Liferay version, the bootstrap version changes. Upgrading the theme is a tad annoying. Not sure, if this can be improved at all, since it relies on bootstrap and bootstrap changes.
I could probably come up with even more things that annoy me with the theme and I can also think of several improvements (we have worked around several of the issues I have mentioned) but I'd like to stop here. Maybe somebody else has more painpoints, that are important to him/her. But I'd also like to hear from Liferay, if there are any plans to improve the current theme infrastructure.
Please note that I want to "kill" the current theme with that, at least not at once. Maybe it also could just slowly evolve to resolve these issues. Or maybe an alternative could be introduced in 7.3 and maybe the current theme deprecated in 7.4 and so on.
What about the Theme? Are there any plans for a "Theme 2.0"?
I'd like to mention a few pain points:
-) Theme deployments cause a hiccup, for a few seconds the standard theme is used. Because of this, we have moved functionality out of the theme to minimize deployments. Most other osgi component deployments are rather smooth or so much faster that nobody notices. Please don't forget that not all customers have clusters.
-) Theme builds are rather slow. gulp watch is somewhat okish, but we have actually moved as much as possible of our js and css out of the theme and use webpack + dev proxy for rapid development.
-) SEO: The theme has several flaws. The canonical urls are often wrong, the h1 "Navigation" tag that's inserted is really weird. Some guy with SEO experience should rework it
-) For non-authenticated users it loads a ton of unnecessary stuff. Yes, I know, this is a hard problem, especially for the general case, but I am sure, improvements are possible.
-) It's unflexible. Why can't I just drag and drop a header fragment and a footer fragment into a page, add a navigation fragment and a login fragment and a language selector fragment ... AND declare: "This is my theme!" I mean, it is basically just a freemarker template + css + js.
-) We often have the requirement to add stuff to the technical header of a page. Add google tag manager, add a verification key, add some open graph stuff. I don't want to deploy the theme for that, I want to be able to have extension points for that. (Maybe there already are, it is sometimes hard to keep track of new features ;) )
-) Upgrades: With each Liferay version, the bootstrap version changes. Upgrading the theme is a tad annoying. Not sure, if this can be improved at all, since it relies on bootstrap and bootstrap changes.
I could probably come up with even more things that annoy me with the theme and I can also think of several improvements (we have worked around several of the issues I have mentioned) but I'd like to stop here. Maybe somebody else has more painpoints, that are important to him/her. But I'd also like to hear from Liferay, if there are any plans to improve the current theme infrastructure.
Please note that I want to "kill" the current theme with that, at least not at once. Maybe it also could just slowly evolve to resolve these issues. Or maybe an alternative could be introduced in 7.3 and maybe the current theme deprecated in 7.4 and so on.
I don't believe that themes are going anywhere... I mean, at the end of the day the theme is the thing that provides the consistency across each rendered page.
1. Typically you can work around that short period of deployment time by deploying at times when portal is not being used. Also, even if you are not using a cluster, you could still handle a blue-green deployment model so users are not impacted during deployment.
2. "slow" is always a matter of perception, but I think you're probably right that most would consider them slow to build. Personally I'm not all that crazy about needing additional tools just for the theme builds, but that's just me. At the end of the day, I guess this one falls under "it is what it is".
3. I know that Liferay thinks SEO is important. If there are issues with canonical URLs or the h1 navigation tags that interfere with SEO, please open tickets on issues.liferay.com or, if you're a customer, open them in help center.
4. Well, Liferay just doesn't come out and spell out all of the options you have between authenticated and guest users. Liferay has two properties in portal-ext.properties, javascript.barebones.files and javascript.everything.files. These two properties give you control over what JS Liferay will include for guest vs authenticated users. Barebones tends to be on the heavy side because Liferay really doesn't know what widgets you will be using on a guest page, so most of the Liferay javascript is in there necessary to ensure all of the Liferay OOTB portlets will still work. At the end of the day, only you know what portlets will be visible to guests on your site(s), so ultimately you would be the one to move the JS from the barebones to the everything list to thin it down. I think this is more work than what most admins want to do, especially since the moves can be challenging to get the right balance to keep guest functionality while finding the right minimum set of JS, but the option is still there.
5. That sounds like a view of a theme by how you build your sites though. You might actually be better off working on a theme that uses settings to dynamically change the banner, header and footer to switch between different options or even use some web content entries... Remember that Liferay has been used to serve up sites of all kinds, from kids interactive sites through standard brochure sites, pretty much anything you can think of. The themes to serve each of these sites are wildly different than the ones that you are referring to. It's only through the versatility in the theme layer that this kind of thing can be pulled off in the first place. With all of that power, there is also some responsibility on your part to use it effectively.
6. I would actually recommend looking at theme settings and/or theme contributors for this kind of thing, they might be a decent solution to help you implement these things without having to rebuild your theme.
7. Upgrades are hard. Half the time we hear that devs want to stay on BS3 so they don't have to update their theme, the other half are asking when we are planning support for BS5. It is impossible to make everyone happy, that I can tell you. There was a huge effort for 7.1 (and it may still be in 7.2) to introduce a BS3-compatibility layer that was built to allow 7.0 themes to work mostly as-is under 7.1 (and perhaps 7.2, but I haven't tested it there). Liferay knows that upgrades can be challenging, but they do try to give you pathways to minimize the upgrade impact. All of that said, I personally recommend rebuilding themes for each target version; not because I want to maximize the pain of upgrades, I just feel like a theme is used on every page being rendered and therefore I want my themes to be the best they can for the version I'm using. I feel like that will minimize cruft in the theme, although I really don't have any evidence to back that up, it's just more of a gut feeling than anything else.
Just me speaking, I can remember how in Liferay 5 and Liferay 6 I could easily be a Liferay full stack developer, taking care of not only the backend code but also the themes, too. I don't know if it is just Liferay 7 or really more a reflection of how the front end is developed today, but I'm at the point where I would much rather rely on a dedicated front end resource for Liferay 7 themes. Sure I can still do it if given the time, but themes are now using their own toolsets, build tools, etc. that I just don't want to take the time to master. With all of that, however, the themes that are being built today with the popouts and floats, etc., I do find to be much more appealing and professional when compared to what we were typically building for Liferay 5. So things continue to get more complicated from a theme building perspective, but they're also getting better than how they used to be.
All while keeping the ultimate in flexibility in allowing you to build any site you want to on Liferay, from a simple child's site through the most complicated site you can imagine. Themes are the feature that allow for that kind of dynamicism in the UI.
I'd suggest checking out more of the theme settings and theme contributors. It's possible that you can find some additional tools there that will help you address some of the development issues you're facing...
1. Typically you can work around that short period of deployment time by deploying at times when portal is not being used. Also, even if you are not using a cluster, you could still handle a blue-green deployment model so users are not impacted during deployment.
2. "slow" is always a matter of perception, but I think you're probably right that most would consider them slow to build. Personally I'm not all that crazy about needing additional tools just for the theme builds, but that's just me. At the end of the day, I guess this one falls under "it is what it is".
3. I know that Liferay thinks SEO is important. If there are issues with canonical URLs or the h1 navigation tags that interfere with SEO, please open tickets on issues.liferay.com or, if you're a customer, open them in help center.
4. Well, Liferay just doesn't come out and spell out all of the options you have between authenticated and guest users. Liferay has two properties in portal-ext.properties, javascript.barebones.files and javascript.everything.files. These two properties give you control over what JS Liferay will include for guest vs authenticated users. Barebones tends to be on the heavy side because Liferay really doesn't know what widgets you will be using on a guest page, so most of the Liferay javascript is in there necessary to ensure all of the Liferay OOTB portlets will still work. At the end of the day, only you know what portlets will be visible to guests on your site(s), so ultimately you would be the one to move the JS from the barebones to the everything list to thin it down. I think this is more work than what most admins want to do, especially since the moves can be challenging to get the right balance to keep guest functionality while finding the right minimum set of JS, but the option is still there.
5. That sounds like a view of a theme by how you build your sites though. You might actually be better off working on a theme that uses settings to dynamically change the banner, header and footer to switch between different options or even use some web content entries... Remember that Liferay has been used to serve up sites of all kinds, from kids interactive sites through standard brochure sites, pretty much anything you can think of. The themes to serve each of these sites are wildly different than the ones that you are referring to. It's only through the versatility in the theme layer that this kind of thing can be pulled off in the first place. With all of that power, there is also some responsibility on your part to use it effectively.
6. I would actually recommend looking at theme settings and/or theme contributors for this kind of thing, they might be a decent solution to help you implement these things without having to rebuild your theme.
7. Upgrades are hard. Half the time we hear that devs want to stay on BS3 so they don't have to update their theme, the other half are asking when we are planning support for BS5. It is impossible to make everyone happy, that I can tell you. There was a huge effort for 7.1 (and it may still be in 7.2) to introduce a BS3-compatibility layer that was built to allow 7.0 themes to work mostly as-is under 7.1 (and perhaps 7.2, but I haven't tested it there). Liferay knows that upgrades can be challenging, but they do try to give you pathways to minimize the upgrade impact. All of that said, I personally recommend rebuilding themes for each target version; not because I want to maximize the pain of upgrades, I just feel like a theme is used on every page being rendered and therefore I want my themes to be the best they can for the version I'm using. I feel like that will minimize cruft in the theme, although I really don't have any evidence to back that up, it's just more of a gut feeling than anything else.
Just me speaking, I can remember how in Liferay 5 and Liferay 6 I could easily be a Liferay full stack developer, taking care of not only the backend code but also the themes, too. I don't know if it is just Liferay 7 or really more a reflection of how the front end is developed today, but I'm at the point where I would much rather rely on a dedicated front end resource for Liferay 7 themes. Sure I can still do it if given the time, but themes are now using their own toolsets, build tools, etc. that I just don't want to take the time to master. With all of that, however, the themes that are being built today with the popouts and floats, etc., I do find to be much more appealing and professional when compared to what we were typically building for Liferay 5. So things continue to get more complicated from a theme building perspective, but they're also getting better than how they used to be.
All while keeping the ultimate in flexibility in allowing you to build any site you want to on Liferay, from a simple child's site through the most complicated site you can imagine. Themes are the feature that allow for that kind of dynamicism in the UI.
I'd suggest checking out more of the theme settings and theme contributors. It's possible that you can find some additional tools there that will help you address some of the development issues you're facing...
David H Nebinger:
I am a big fan of consistency and having a core structure/design that defines the look and feel of a page is invaluable. But I believe that it could be done better than now.
I don't believe that themes are going anywhere... I mean, at the end of the day the theme is the thing that provides the consistency across each rendered page.
About 1) Sure, we deal/live with it. But maybe it could be improved.
About 2) When you are used to Webpack and Livereload, "slow" is not a matter of perception. Editing a theme is incredible annoying compared to Livereload ...
About 3) It is more than just one issue. These were just examples. There are other, harder problems which are only partly theme related. e.g. duplicate URLs (they are everywhere in Liferay). But sticking to the issue: I don't think that fixing a detail here and there is sufficient.
About 4) I know. As you write: "this is more work than what most admins want to do". Well, than maybe the way to go is to improve the usability of that feature
About 5/6) Again, just an example. I didn't mean that something couldn't be build. But it requires a lot more know how about theme creation that I think is really necessary. As we talked in the chat, maybe an improved theme generator with a variety of base themes could be helpful. In any case, I think there is room for improvement.
About 7) We recreate the theme for each version. It is a lot of effort, yes. This is one of the most difficult issues since it depends on some many things like the underlying bootstrap version. I have to confess, I really have no idea to solve that, but there are a lot of incredibly talented people working for Liferay. Maybe there are things that can be don.
I am also more of a backend developer and the frontend is not my speciality. When I look at our frontend guys, when I look at the issues we face, often Liferay and the theme makes things a lot harder than it would be without it. And I believe that it could be done better.
Maybe it is just me and everybody else thinks, things are just fine. If so, so be it. But maybe other people also feel that the theme is kinda a pain point.
For me as a theme maintainer, stability is helpful. Having to re-write the theme for Bootstrap 4 is painful but is a good opportunity to remove technical debt. The real issue with themes is one that affects the entire front end scene these days. Anyone of us could go into a particular node module and break the internet.
Honestly NPM can go to h**l. I've developed a strategy to keep my node modules static and insulated from whatever craziness is occurring. When there is an update that is needed, I control it and distribute a known stable tar ball of theme node_modules. In a team situation early on I found I was building Lexicon version 1.x and another team member was building Lexicon version 1.xx ... our themes were different. Mine would often be working, theirs would often not build, or build corrupted.
https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/
"Writing software for the web has become dependent on a patchwork of code that itself relies on the benevolence of fellow programmers."
My theme won't build, it's not a Liferay thing, it's LoDash. Ok so we go on a time wasting journey to get the right version of LoDash, well then it's something else, and something else and then something else, several uninstalls and install -g @version blah blah later it's something else again. There's a module that will run a regex on a mixin and there's an error on line 218 ... my theme won't build. It's not me or Liferay, it's this hellscape that has been created.What percentage of the 46 megabytes of node modules is needed to build a theme?
I won't sugar coat theme contributors, they are rubbish, our theme contains a bunch of jQuery HTML re-writes of module HTML to affect things like the dockbar. Contributors are not front end dev friendly. If I see a Java developer, they are likely going to be terrible at Front end, if I see a person that sees the world in HTML, they aren't going to be able to deploy a theme contributor. A theme contributor or product menu contributor requires two incompatible skill sets, trying to organize that can be difficult. So you have to take a Java dev off a really important issue to figure out how to change a background color on the dockbar? I give a hex code to a backend developer and it might be changed within two months. Nope. Contributors, I wouldn't say remove them, just ignore them.
Same with layouts, ignore them. We rely heavily on layouts, I created our own that were missing that our users use all the time, in both pages and nested applications.
Honestly NPM can go to h**l. I've developed a strategy to keep my node modules static and insulated from whatever craziness is occurring. When there is an update that is needed, I control it and distribute a known stable tar ball of theme node_modules. In a team situation early on I found I was building Lexicon version 1.x and another team member was building Lexicon version 1.xx ... our themes were different. Mine would often be working, theirs would often not build, or build corrupted.
https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/
"Writing software for the web has become dependent on a patchwork of code that itself relies on the benevolence of fellow programmers."
My theme won't build, it's not a Liferay thing, it's LoDash. Ok so we go on a time wasting journey to get the right version of LoDash, well then it's something else, and something else and then something else, several uninstalls and install -g @version blah blah later it's something else again. There's a module that will run a regex on a mixin and there's an error on line 218 ... my theme won't build. It's not me or Liferay, it's this hellscape that has been created.What percentage of the 46 megabytes of node modules is needed to build a theme?
I won't sugar coat theme contributors, they are rubbish, our theme contains a bunch of jQuery HTML re-writes of module HTML to affect things like the dockbar. Contributors are not front end dev friendly. If I see a Java developer, they are likely going to be terrible at Front end, if I see a person that sees the world in HTML, they aren't going to be able to deploy a theme contributor. A theme contributor or product menu contributor requires two incompatible skill sets, trying to organize that can be difficult. So you have to take a Java dev off a really important issue to figure out how to change a background color on the dockbar? I give a hex code to a backend developer and it might be changed within two months. Nope. Contributors, I wouldn't say remove them, just ignore them.
Same with layouts, ignore them. We rely heavily on layouts, I created our own that were missing that our users use all the time, in both pages and nested applications.
Attachments:
Actually, I see stability also as a goal of a "Theme 2.0". I would like to decrease the burden of upgrades. Of course, there would be a higher "one time" cost to switch to a new theme structure. But if it is more stable afterwards (I am actually really sick of bootstrap already), it could be worth it.
And I certainly agree, npm is a pile of s**t. The dependency management of node is creepy. The headaches are legion. But this stuff is here to stay. Frontend developers are used to have liverreload and Typescript and <other stuff>. So, this stuff needs to be available as an option. There's no way around it.
And I certainly agree, npm is a pile of s**t. The dependency management of node is creepy. The headaches are legion. But this stuff is here to stay. Frontend developers are used to have liverreload and Typescript and <other stuff>. So, this stuff needs to be available as an option. There's no way around it.
NIce discussion.
Regarding SEO / Canonical URLs there is some current work being done to make things more configurable, please see for example: https://issues.liferay.com/browse/LPS-97646
Regarding SEO / Canonical URLs there is some current work being done to make things more configurable, please see for example: https://issues.liferay.com/browse/LPS-97646
Another problem was also that the hreflang URLs for locales specified with both language / region were redirecting (like for australian english). That has been fixed here: https://issues.liferay.com/browse/LPS-97660
There is another issue with CSS in Liferay ... Senna.js. Loading and unloading will cause certain CSS to stick to HTML. It's very hard to explain it and even harder to see unless you're in IE11. I've come to think of it as Senna.js being a glue like substance that just won't let go of some styling and brings back styling from pages ago. There's no rhyme or reason to it and I've come to expect that Senna is going to magically corrupt my page upon page switching (again not an issue in a fast browser).
NPM and Hot Pockets ...
https://medium.com/s/silicon-satire/i-peeked-into-my-node-modules-directory-and-you-wont-believe-what-happened-next-b89f63d21558
NPM and Hot Pockets ...
https://medium.com/s/silicon-satire/i-peeked-into-my-node-modules-directory-and-you-wont-believe-what-happened-next-b89f63d21558
Anyone notice the title element on blogs? Subtitle has always been before title.
David, that's my feeling too : "I don't know if it is just Liferay 7 or really more a reflection of how the front end is developed today, but I'm at the point where I would much rather rely on a dedicated front end resource for Liferay 7 themes."
David, that's my feeling too : "I don't know if it is just Liferay 7 or really more a reflection of how the front end is developed today, but I'm at the point where I would much rather rely on a dedicated front end resource for Liferay 7 themes."
Adding DDL fields to a theme was a neat trick I found early on ... in liferay-look-and-feel.xml and using logic in the freemarker. This then presents in the site and page "look and feel" configuration. You could add a plethora of configuration items for the theme. I found the "color scheme" options too late in developing my theme.
<setting configurable="true" key="Show Breadcrumb" type="checkbox" value="true" /><setting configurable="true" key="Wrap Page Navigation After Number Of Items" type="select" options="9,8,7,6,5,4,3,2,1,10,11,12,13,14,15,16,17,18,19,20" />
Copyright © 2025 Liferay, Inc
• Privacy Policy
Powered by Liferay™