In the end our site is updated to include styles to match the WKND brand.
This is a multi-part tutorial and it is assumed that the steps outlined in the Page Templates chapter have been completed.
Next, make changes to the theme sources so that the site matches the look and feel of the WKND Brand.
Let’s look at how we can update the site with brand-specific styles. Now, our site came with some pre-defined styles as part of the wireframe template. In this video, we’ll look at how we can update those theming sources, and code against the live AEM environment.
In order to code against the live AEM and author environment, we need to create a local user for authentication. This should only be done on development environments, and should be avoided in production. From the AEM start screen, I’ll navigate to tools, security, users.
This is the user management screen. From here, we can create a local user. Again, this local user is just for development purposes. In production, only IMS authentication via an Adobe ID should be used.
For ID, I’ll name it dev-author, and then I’ll set it a password.
Next, assign the local user to the authors group. So, they’ll have permission to log in, view, and edit pages.
Then save and close the changes to the new user.
Next, let’s look at how we can begin to modify the theme sources for our site.
So first, I’ll start by navigating to the site’s console.
Next, I’ll select the WKND site.
And in the left rail, I’ll select site. Here, we’re presented with an option to download the theme sources. And by downloading the theme sources, we can begin to customize the site, using just front-end code. I’ll download the theme sources, which is a zip file, to my local file system. And unzipping the file, we can see the contents. Now, this is a traditional front-end project, built using Webpack. Let’s go ahead and open it up in Visual Studio Code. This is the editor IDE of choice, but you can use, really, any IDE.
And when you open up the read me for the project, you can see information about the project, as well as build and usage instructions. Now, the source folder contains all of the front-end code used to style and script the site. The project is based on Webpack, and it makes use of various NPM libraries to compile the front-end code.
Let’s go ahead and install the project using the command line. First, I’ll verify that I have NPM installed and available from the command line. Version six or seven will work. Then I’ll go ahead and install the project using the command, NPM install. Based on the dependencies listed in the package.JSON file, various libraries will be installed.
.ENV is an environment variable file. Next, we need to update the .ENV file with the information about our AEM environment, so that we can connect to it.
I’ll go ahead and open up the .ENV file. And there are three variables that need to be updated. AEM URL points to your AEM cloud environment. AEM site points to the root of the website. AEM proxy port is the port used by our local proxy server. Now, if you’ve downloaded theme sources directly from your environment, these should be pre-populated. Okay, so that looks good.
Next, we’ll start a proxy server that’s going to proxy the HTML content from AEM. In the read me, you can find the instructions. And the command is, NPM run live.
This will open up a new browser window, running on port 7,000. And if that port’s already in use, it will use the next available port.
Next, we’ll use the local user account created earlier to log in to the AEM environment. We need to use a local user account when connecting via the proxy. So my user was dev author, and I’ll enter the password.
Notice that we’re now logged into the AEM environment as dev author. Next, let’s go ahead and navigate to the magazine article we created earlier. So, under magazine, I’ll open up “The Ultimate Guide to LA Skate Parks.” Observe that when we open the window, we see the browser sync message. Browser sync is one of the pieces that enables a live reload of the page when we make changes.
I’ll return to VS Code, and rearrange these windows a bit, so we can see both the page and our editor. The theme sources project uses SAS as a pre-processor for the compiled CSS. One of the advantages of SAS is that we can set variables, and use them throughout different files in the project.
Let’s start by making some changes to our variables file, so that we can see these changes reflected in the browser. I’ll update the background to be this hot pink color. Notice that when I save the changes, the terminal is recompiling the code. And then the browser is automatically reloaded with the updated styles. So this is pretty ugly, and not the brand colors we are looking for. However, we can see that the live coding set up is working.
Let’s revert that change, and then start making some updates to the styles to match the WKND brand.
So, to start, let’s update the layout of this main container, in the body, beneath the header and above the footer. Using my browser’s development tools, I’m going to inspect the div for the main body of the magazine article page.
If you recall from the previous chapter, we set the policy for this main container to include a CSS class named main. And here we can see that this CSS class has been added to the container. Next, let’s update a CSS rule that targets the main container class.
I’ll return to VS Code.
And under components, container, you can see a few different files for styling the container. There’s a file for container main. We’ll go ahead and open up that file, and we can see that we already have a rule populated. I’ll update this rule, so that the main container has a max width of 873., and I’ll also set the margin to zero space auto, which will center the div. I’ll save those changes, and return to the browser.
Once the CSS changes are compiled and synced, we can now see that our rule has been applied, and that the main container now has a fixed width.
Let’s make another update. In our mock-ups, the footer has a black background with white text. Once again, I’ll use the developer tools to inspect the markup. The experience fragment used for the footer has an HTML ID attribute set. And it is set to main-footer. And you can configure this ID attribute for any component in AEM, but it’s a good idea to use this sparingly. Since we know that the experience fragment footer will only be used once on a page, this is a good use case. Now, I’ll open up my experience fragment_footer.SCSS file, and you can see here, we’ve got a rule to target this ID of main-footer.
Now, in our mock-ups, the footer was dark, and was really the inverse of the rest of the page text. So, we’ll set the background color to color-foreground, so that we get the inverse effect. And then we’ll set the color to color-background. So we’ll get a dark background with light text.
Go ahead and save those changes. And then if we return to the browser, you can see, we’ve got the start of our styled footer.
So, as a front-end developer, you’re basically repeating these steps until you have styled the different core components and containers to match your brand’s mock-ups. Now, at some point, you might run across an element in your mock-ups that is unique and requires an additional CSS class. One of the great things about coding against the live environment is that you can make changes to the template and various policies to introduce additional CSS classes as needed. To complete the WKND styles, I’m going to take a shortcut. Below this video, you’ll find a zip file that you can download with the finished source files for the WKND site, named weekend-theme-source.zip. I’ll go ahead and unzip this, and then I’ll replace the source file that was in my theme sources project.
I’ll reopen VS Code, and I can see that the variables file has been updated. And under components, you can inspect the different files to see the different changes. I’ll go ahead and restart the proxy server by running NPM run live.
And when I return to the browser and view the skate park magazine article, I can see the final styles have been applied. So, this looks much closer to the WKND mock-ups, and that original wireframe theme has pretty much disappeared. So, this looks great! Note, to see the full changes, you may need to restart your browser, and possibly clear out your cache. In VS Code, feel free to inspect the changes. You’ll notice that some icons to support the WKND site have been added. We’ve also replaced some of the fonts in favor of web fonts, and we’ve updated the styles for individual components.
Now, currently, these changes are only visible using our local proxy server. Next, we will look at how to apply these updates to the actual AEM environment. -
High level steps for the video:
Download the finished styles for the WKND Sample Theme
Deploy updates to a theme to an AEM environment using Cloud Manager’s Front End Pipeline.
I’ll save these updates and Cloud Manager will now create my new git repository.
This usually takes a couple of minutes and once the repo has been created, we can view the details about it.
So if you recall, my front end theme sources is just a plain old folder that we downloaded earlier. Next, we’ll take all the files and folders in this project and commit it to our git repository.
So I’ll run the command, “git init -b main”. And that’s going to initialize this folder as a git repository and the branch that we’re going to be using will be called main.
Next I’ll run the command “gid add .” and this is going to include all the files beneath the current directory. I’ll next run the command “git commit -m”, and the message I’ll put in is “initial commit”, and this is going to commit my first change. All right, so now we want to push our changes to the Cloud Manager git repo we created in the previous step.
I’ll return to Cloud Manager, view the details about my target repo and copy this URL.
Back in my front end theme sources folder, I’ll type in “git remote add origin”, and then paste the URL to the git repository.
Finally, I’ll push the changes by typing in the command “git push -u origin main”, where origin is my Cloud Manager repo, and main is the bridge. “-u” means that my local branch will track changes with the Cloud Manager branch.
Next I’ll return to Cloud Manager and navigate to pipelines.
We’ll add a new pipeline and this will be a non production pipeline, since we’re targeting my dev environment.
The type of pipeline will be a deployment pipeline since we’re going to be deploying code, and I’ll give it the name of “WKND Frontend Theme” so we can easily identify it in the UI. I’ll leave the rest of the options set to their default.
I’ll go ahead and select my dev environment, and under source code, I’ll select my WKDN frontend-theme repository, and I’ll select the branch main, which we just pushed up. There is an optional setting to specify a relative folder for the front end location. And in this case, our front end project is the entire branch and it’s already located at the root, so we can leave these settings set as default. We’ll go ahead and save the changes.
So now I can see our new WKND frontend theme pipeline, and it’s been created. And if we go to the program overview, you can see our front end pipeline, and we can go ahead and kick it off.
We can check the progress by navigating to activity and view details. Here we can see that it’s deploying code from our WKND frontend theme repository, and our main branch, and that the latest commit is this hash ID.
We can also verify that this is the latest commit we have pushed by returning to the command line and running the command “git log --oneline”.
And there we can compare the two hashes. So you can see that this “5c7c4” matches what’s in Cloud Manager. All right, so the front end build is pretty fast, only five or six minutes, but go ahead and fast forward the video to when it has completed.
So the pipeline has finished and we couldn’t inspect the build and deployment logs for more details about what was built.
All right, so let’s go ahead and check out our changes. I’ll navigate to my AM author instance. That’s part of my dev environment.
And under the site’s console, I’ll go ahead and open up the LA skateboarding article.
So now this is opened. We can see the updated WKND branding styles and colors have been successfully applied.
Once again, I’ll view my page as published. And then I’ll inspect the source code.
And if we run the front end pipeline again, the hash for those front end files would be updated. And then the updated files would be referenced by the page in AEM.
High level steps for the video:
Create a new git repository in Cloud Manager
Add your theme sources project to the Cloud Manager git repository:
$ cd <PATH_TO_THEME_SOURCES_FOLDER>
$ git init -b main
$ git add .
$ git commit -m "initial commit"
$ git remote add origin <CLOUD_MANAGER_GIT_REPOSITORY_URL>
Configure a Front End Pipeline in Cloud Manager to deploy the front end code.
Run the Front End Pipeline to deploy updates to the target AEM environment.
There are a couple of example GitHub repos that can be used as a reference:
Congratulations, you have just updated and deployed a theme to AEM!
Take a deeper dive in to AEM development and understand more of the underlying technology by creating a site using the AEM Project Archetype.