7

I'm creating a custom Theme Layout for Communities. I've created a Lightning Component and I would like to use the customization options available in Community Builder and reference them from within my template (See image below). Specifically, I would like to access the "Header Image" value, but the other properties would be nice to know as well.

enter image description here

Do I access these in the component like so? (And what are the property names?)

<aura:component implements="forceCommunity:themeLayout" access="global" description="My Theme Layout">
    ...
    <img src="{!v.nameForHeaderImageProperty}">
    ...
<aura:component>

Or are they accessible as design tokens in the CSS? (And what are the property names?)

.header {
    background-image: t(nameForHeaderImageProperty);
}

I've scoured the SFDC dev site as well as the '16 and '17 release notes, but can't seem to find this answer.

0

2 Answers 2

1

I'm posting this answer as a partial answer/work-around to hopefully help others, until a better answer is provided.

Primary Font

Accessing the chosen "Primary Font" from Community Builder can be accomplished by using the design token in the CSS file:

.THIS .myThemeSection {
     font-family: t(fontFamily);
}

Company Logo and Header Image

(Requires Site.com Studio)

To force your ThemeLayout to use "Company Logo" and "Header Images" uploaded through the UI, it appears that you must use Site.com Studio. You will need to hard-code the path to a generic image name within your Component markup or CSS files:

Component CSS Version

.THIS .myHeaderClass {
     background-image: url(http://[communityurl]/myThemesHeaderimage.jpg);
}

Or

Component Markup Version

<img src="http://[communityurl]/myThemesHeaderimage.jpg">

Then, when uploading an image file through Site.com Studio, make sure that whomever uploads the file follows your file naming convention and names/renames their file 'myThemesHeaderimage.jpg'. This is less than ideal and looks to have a downsides.

  1. It requires the use of Site.com Studio.
  2. It appears to cause some caching issues when the image is changed multiple times, but this can be fixed with a hard reload in the Web browser.
  3. It forces the user uploading the image to use the prescribed naming convention.
  4. Hard-coding. Blech!

Header Fonts

I have yet to find an answer/workaround for this, but I'll update if I do.

0

I know this is a late answer, but I'm thinking the best practice here would be to create a custom static resource, including a custom stylesheet and a folder with images. This way you can refer to the image's relative path in the CSS, then you can move from sandbox to prod (for example) without any issues.

The problem with hard-coding that URL for the image is: if you change from sandbox to prod, that URL changes and you'll have to manually alter all of the URLs you've created, which means you have to document them, etc.

You must log in to answer this question.