Manuel Manhart 2 Years Ago - Edited Hi Vitaliy, I found this article very interesting but have some things to add / question: First of all because I think its most important, where did you get that the theme based approach will become deprecated? Or is this just a guess? (Then a footnote would be good). As for the pro "All code is stored in a single place" I don't think that this is the case even with theme based, as we nowadays always have some fragments (in a toolkit project in git) and often some widget templates (also in a seperate git project). So in my opinion its as scattered as the theme-less approach. I also wanted to add for the "no deployment" theme-less approach argument - Liferay reccomends to use the fragment toolkit project, which generates a deployable zip - yes one could argument that this is no deployment as it can be imported via the UI, but to me this is still some kind of deployment. Also for some of our customers the theme based approach always wins, because of performance reasons - in the theme we can improve the reached performance in eg. a web vitals or google page speed test big times. As for header and footer what we always add into our themes are theme settings for not rendering them - and we use eg. navigation & webcontent display widgets. Please don't think of my comment a critique but as additional thoughts as I think it's a good base for some interesting discussions. (Actually we had some of these in the past few projects). Reply Reply as... Cancel Vitaliy Koshelenko Manuel Manhart 1 Year Ago - Edited Manuel Manhart, More and more new Liferay features are dedicated to empower developers with possibility to create content without a custom theme: - "Addition of CSS classes to fragments from the Page Editor" from 7.4-ga34: https://liferay.dev/blogs/-/blogs/liferay-portal-7-4-ga34-and-liferay-commerce-4-0-ga34-release - "Modify Theme CSS of Pages, without the need to deploy the Theme, with the new Theme CSS Client Extension" from 7.4-ga44: https://liferay.dev/blogs/-/blogs/liferay-portal-7-4-ga44-and-liferay-commerce-4-0-ga44-release which means, they prefer content-based approach over the theme-based. Reply Reply as... Cancel Manuel Manhart Vitaliy Koshelenko 1 Year Ago - Edited Both of the features sound very nice. And while I do agree that it's clearly the intention of the devs of enabling to create a site without custom themes altogether I don't believe it's used widely (in the wild) soon. I am still in the nessecity of creating child themes, theme settings and so on, as it's not easily possible to replace all of that yet. I do believe as long as the JS framework keeps being a big monolith (even when distributed to many small files) and the SPA mode in some cases not being handleable its neccessary to be able do some magic in a custom theme :) But in the last years there was a big shift from backend dev to frontend (devs and even editors) and that's a good thing as one can save many dev hours when thinking how a requirement can be tackled by using the (new) OOTB mechanisms. Reply Reply as... Cancel
Vitaliy Koshelenko Manuel Manhart 1 Year Ago - Edited Manuel Manhart, More and more new Liferay features are dedicated to empower developers with possibility to create content without a custom theme: - "Addition of CSS classes to fragments from the Page Editor" from 7.4-ga34: https://liferay.dev/blogs/-/blogs/liferay-portal-7-4-ga34-and-liferay-commerce-4-0-ga34-release - "Modify Theme CSS of Pages, without the need to deploy the Theme, with the new Theme CSS Client Extension" from 7.4-ga44: https://liferay.dev/blogs/-/blogs/liferay-portal-7-4-ga44-and-liferay-commerce-4-0-ga44-release which means, they prefer content-based approach over the theme-based. Reply Reply as... Cancel Manuel Manhart Vitaliy Koshelenko 1 Year Ago - Edited Both of the features sound very nice. And while I do agree that it's clearly the intention of the devs of enabling to create a site without custom themes altogether I don't believe it's used widely (in the wild) soon. I am still in the nessecity of creating child themes, theme settings and so on, as it's not easily possible to replace all of that yet. I do believe as long as the JS framework keeps being a big monolith (even when distributed to many small files) and the SPA mode in some cases not being handleable its neccessary to be able do some magic in a custom theme :) But in the last years there was a big shift from backend dev to frontend (devs and even editors) and that's a good thing as one can save many dev hours when thinking how a requirement can be tackled by using the (new) OOTB mechanisms. Reply Reply as... Cancel
Manuel Manhart Vitaliy Koshelenko 1 Year Ago - Edited Both of the features sound very nice. And while I do agree that it's clearly the intention of the devs of enabling to create a site without custom themes altogether I don't believe it's used widely (in the wild) soon. I am still in the nessecity of creating child themes, theme settings and so on, as it's not easily possible to replace all of that yet. I do believe as long as the JS framework keeps being a big monolith (even when distributed to many small files) and the SPA mode in some cases not being handleable its neccessary to be able do some magic in a custom theme :) But in the last years there was a big shift from backend dev to frontend (devs and even editors) and that's a good thing as one can save many dev hours when thinking how a requirement can be tackled by using the (new) OOTB mechanisms. Reply Reply as... Cancel
Vitaliy Koshelenko 2 Years Ago - Edited Hi Manuel, Thanks for your input, really appreciated. The main idea of this post was to demonstrate that there is a new "code-less" approach for site building, besides the regular theme-based approach. Liferay folks often recommend using Master Pages instead of custom theme, when possible (in community slack, on forums, etc.). I think, themes themselves will allway be there, and will never die... But some theme-related features are deprecated already (e.g. Resource Importer). Also, Liferay team invests more and more time and resources into Web Experience development (improving fragments, master pages, style books, etc.), while theme-related features (theme settings, color schemes) remain untouched. As for code storage/version history - when changes are made directly on portal (with "code-less" approach) sometimes it's hard to reset the previous state, if something is broken. That's why I suggest keeping the version history of modified files on portal (e.g. in Git repository, even though they are not required for deployment). As for deployment - it's more about possibility to avoid the deployment... We can use fragment toolkit for fragments deployment, we can also use site initializers to import widget templates and setup other content. But, if required, we can make the required changes directly on portal. With theme-based approach we still need to re-deploy a theme to apply the changes. Actually, we can get the most, if we combine both approaches: we'll get the power of themes, and the dynamism of master pages. Custom theme can be used to define the styling elements, which then can be used inside fragments/templates. But, as for page structure - it's better to define it with a master page (and we can use a custom theme with disabled header/footer in theme settings). Everything should be as dynamic as possible (thus, require as less deployment as possible). Thanks, Vitaliy Reply Reply as... Cancel