Best practice when constructing a theme

[Ben Collins, modifié il y a 10 années.]

Hi all,

I'm starting to put together a theme for Liferay 6.2, and I have a couple of questions around what theme to use as the parent.

I have a new design as supplied by my designers - all looks lovely and is based on Twitter Bootstrap v2.3.2. What I want to be able to do is (a) reproduce that design within a theme and (b) make use of the Liferay UI features for the editors and admins (the dockbar, the in-page editing, the portlet drag-and-drop and configuration).

I understand about how to create a theme, how to update the templates, apply more css, deploy it and all that - however I am struggling to find the most efficient way to construct the theme.

If I use the _styled theme as the parent I get a fully functional system but I get too many conflicts with my design, even when using my own classes - it seems that applying classes like "aui" to the body field as per the default template stops some of my stuff being picked up. If I fiddle with the use of these classes in my templates (which are modelled on the default) my fear is that I remove the Liferay UI functions that make it so good.

If I use the _unstyled theme I get a lovely clean build but have no docbar and limited Liferay UI functionality.

With so many CSS files to look at there's no real simple entry point into this and I fear I will burn up hours picking through lines of css.

I am sure someone else *must* have come across this before and I am hoping someone could offer me some pointers
- are there a set of css files to take from the styled theme to put in my theme based on unstyled to get the best of both worlds? This is my current starting point but before I start I thought i'd ask for advice.
- any decent documentation of what the default templates do - there's a load of VM commands which I have to trawl through the source and forums to find out what they are doing
- are there any pitfalls to avoid?


Any advice would be greatly appreciated!
Thanks,
Ben

[David H Nebinger, modifié il y a 10 années.]

I'd try downloading the bootstrap theme (may be in marketplace or in github) and use it as a baseline. May be the easiest path to stay with your bootstrap base yet still incorporate the normal Liferay functionality.

[M J, modifié il y a 10 années.]

@Ben

I can understand your frustrations. I have gone through many iterations of creating custom theme in 6.2 without success. Liferay team (aui team) made it extremely difficult for the developer's life miserable to do any customizations of themes. That being said, finally I got it working by inheriting classic theme. I think this is the only solution where dockbar and your customization can co-exist peacefully :-). Here is a post that you can get more details. If you need further assistance, I can provide my code.

[Ben Collins, modifié il y a 10 années.]

Thanks David & M J - I'll have a look this morning !

It is a bit of a struggle - but perhaps there are two answers:
(a) start your design from the Classic theme - and as you would with Twitter Bootstrap customiser - build on that, do not assume a blank canvas
(b) start with the unstyled theme and simply work out how to implement the UI functions yourself... I guess once you've done it the first time you can reuse it again and again (until the next LR upgrade )

I'll let you know how i get on!

[Thomas Berg, modifié il y a 9 années.]

Hi Ben,

How did you end up achieving the desired result?

I have a design based on Bootstrap 3 (and a lot of other css) but otherwise share the requirements that you have.
I've managed (by custom build) to include parts of BS 3 that we needed, e.g., the new grid system.

My experiments thus far:

1. Removing "aui" class from the body element and instead added "aui" to the section element in portlet.vm

This seems to work for the most part but in this case it seems unecessary to have all the css that comes with _styled and classic

2. Import compass and wrap our custom styles with ".aui { }"

Lots of duplicated code and some issues with "em"-sizing

3. Keep the original custom.css from classic as "custom_classic.css" in /diffs and include it in custom.css

This seems to work for the most part but there are still issues with sizing (using em's).
Also, there seems to be an awful lot of css that gets duplicated, my custom.css file has almost 4000 lines.

I believe that the easiest, most maintainable way is to start with the classic theme but i believe that there has to be a better way that reduces the amount of duplicated code and still keeps modularity, e.g., I can work with a single custom.css file and include only the files that are needed.

It would be interesting to know how you ended up doing and if you have som "Best practices" to share?

Regards Thomas

[Bradley Wood, modifié il y a 9 années.]

what I always do it copy the baseline portal_normal.vm from the bundle webapps/ROOT/html/themes/_unstyled/templates/portal_normal.vm

I also look at the init.vm to familiarize myself with the best way to reference velocity content, that can change from liferay version.

[David H Nebinger, modifié il y a 9 années.]

Actually when you start a theme project and define the parent as _unstyled and do the initial build, both of those Velocity template files are copied into your project, so you're doing something manually that is not necessary.

[Ben Collins, modifié il y a 9 années.]

Hi,

Sorry I haven't replied earlier - I've stopped getting notifications when people respond to my posts so will have to work out how to reenable that !

Not sure I would follow this route again but what I did was:

1. Started with an unstyled theme - part of the reason we did this was that the markup I was trying to add was built "stand alone" and not with LR in mind. We had a separate design/prototype process from which we would then build the theme. I suspect this was now really the best approach and think you cannot design without a lot of consideration to how LR will impact this.

2. Built my templates per the markup I was supplied and loaded in the css/js too. This allowed me to prove the site displayed as per the designs - but it mean the admin UI was all screwy. All my css/js went into a "custom" folder in the theme - and used custom.css to import these - just to separate my css from the css *I added below...

3. I then copied in the various css files from the STYLED theme to get the admin UI working. It was a trial-and-effort process of copying in a file at a time and checking what it fixed. Basically I took all the files as-is except aui.css which i stripped back - my version is:

@import url(bootstrap.min.css);
@import url(bootstrap-responsive.min.css);
$FontAwesomePath: "aui/alloy-font-awesome/font" !default;
@import "aui/alloy-font-awesome/scss/variables";
@import "aui/alloy-font-awesome/scss/mixins-alloy";
@import "aui/alloy-font-awesome/scss/path-alloy";
.aui {
	@import "aui_variables";
	$iconSpritePath: '../images/aui/glyphicons-halflings.png' !default;
	$iconWhiteSpritePath: '../images/aui/glyphicons-halflings-white.png' !default;
	@import "aui/alloy-font-awesome/scss/core";
	@import "aui/alloy-font-awesome/scss/bootstrap";
	@import "aui/alloy-font-awesome/scss/extras";
	@import "aui/alloy-font-awesome/scss/icons-alloy";
	@import "aui/alloy-font-awesome/scss/icons-alloy-extra";
}
@import url(custom/aui.css);

4. Tested and applied "a few" fixes to make the two work together. I added a class to the body to support my theme "sitename" if you like, which then allowed me to target my site and not break the admin UI

The upshot of all this is that I probably wouldn't be doing this again ! And as per your comments would probably start with the styled theme next time.

I'm in a little bit of an odd situation where I am using LR to implement a "framework" for our peer dev groups to use to build their webapps rather than building websites directly. My next step is to look to build a corporate-brand theme for people to use as a base for their themes - "my-corporate-styled" if you like. For that I'm going to start with Styled and use the SASS builder to brand accordingly. That means the dev groups can then use SASS themselves or puire css files to enhance the brand to their needs. if that makes sense.

Overall I'm still struggling with the way that the inline admin-ui is intricately linked with your sites design and that makes it hard to build themes without taking full consideration of Liferay. And when you work with designers and UI developers they like to work in isolation independent of the product - which should be the case. Not sure what the answer is (sorry!). Experience and time will tell.