Basic URL Rewrite Rules | Hiding the Content Root from URL

One of the requirements in almost every AEM project is to set up the rewrite rules. A typical content URL follows below pattern:

http://<hostname>:<port>/content/mysite/en/mypage.html

It is a best practice not to reveal the repository structure and hide the top level path in the URL i.e. /content/mysite. This blog post will talk about the steps to be made to achieve this on both publish server and dispatcher.

Configuration on AEM Publish Server:

  • There are many ways to configure the rewrites on publish server. e.g. Resource Resolver, Vanity URLs, Sling mapping. Configuring the Apache Sling Resource Resolver Factory is one of the ways to configure rewrites on publish server. This service needs to be configured on the publish server so that if someone hits the publish server directly, we see the correct rules applied there.
    Make sure that the publish server has the below configuration appliedApache sling resource resolver factory
  • Once you apply this configuration, wait for 5 minutes so that all the services are up and running.

Configuration required on Dispatcher:

  • Set DispatcherUseProcessedURL property to 1. i.e.

<IfModule disp_apache2.c>
DispatcherConfig dispatcher.any
DispatcherLog /var/log/apache2/dispatcher.log
DispatcherLogLevel 3
# DispatcherNoServerHeader 0
DispatcherDeclineRoot 0
DispatcherUseProcessedURL 1
DispatcherPassError 0
# DispatcherKeepAliveTimeout 60
</IfModule>

  • Make sure the mod_rewrite module is loaded in apache.
  • Update the virtual host file and add the below rules in it.

<IfModule mod_rewrite.c>
#Enable this to debug the redirect logs
LogLevel alert rewrite:info
RewriteEngine on

# remove any trailing slash, if it's there.
RewriteRule ^(.+)/$ $1

#Shorten the URL
RewriteRule ^/content/mysite/(.*).html$ $1.html [R,L]
#Map the root folder to the home page
RewriteRule ^/?$ en.html [R,L]

# Ignore requests to "known" AEM root paths, and prefix all others with the proper AEM prefix
RewriteCond %{REQUEST_URI} !^/apps
RewriteCond %{REQUEST_URI} !^/content
RewriteCond %{REQUEST_URI} !^/etc
RewriteCond %{REQUEST_URI} !^/home
RewriteCond %{REQUEST_URI} !^/libs
RewriteCond %{REQUEST_URI} !^/system
RewriteCond %{REQUEST_URI} !^/tmp
RewriteCond %{REQUEST_URI} !^/var
RewriteRule ^/(.*)$ /content/mysite/$1 [PT,L]

</IfModule>

 

Troubleshooting Tips:

  • Restart your apache server every time you make any changes.
  • Enable logging for rewrite module. It will help you to monitor the rules getting applied at each level
  • Check dispatcher logs whether the rules are applied or not and which request is going to publish server.
  • Check if the page invalidation is happening correctly after applying the rewrite rules.
  • Check all the links within the page and navigation bar are correctly shortened.

Hope it helps !! 🙂

 

Communities Component Guide

Adobe has provided one of the most useful feature/utility for developing communities components, known as Communities Component Guide. It is an interactive development tool for the Social Component Framework (SCF). It provides a list of available communities components and complex features built of community components.

Apart from providing the basic information for each component, it lets you experiment with the features as well. You can access the community guides on your instance by following the below URL

http://<server>:<port>/content/community-components/en.html.

The left rail provides the list of the SCF components. Clicking on the component will display the information related to that component. e.g.

  • You should be able to see the title of the component.
  • Clientlibs are very important when it comes to community components. Your component might not behave correctly if the required clientlibs are not included on the page. You should be able to see the required clientlibs for the selected component.
  • It also has the instance of the component on the page so that you can experiment with it. The behavior of the component depends on the instance where you are accessing the guide from. If you are accessing it on the author, then you should be able to see the dialog, can edit the template scripts etc. If you are accessing it on publish then you should be able to experience the features as a site visitor.

It looks like below:

component-guide

Customization:

If you want to do some customizations on the fly, the scg:showIde property must be added to the component page’s content JCR node and set to true.

Lets’ take an example of the comments component:

  1. Go to CRXDE Lite e.g. http://<server>:<port>/crx/de
  2. Select the component’s jcr:content node e.g. /content/community-components/en/comments/jcr:content
  3. Add below property and save.
    • Name  scg:showIde
    • Type   String
    • Value  truecomments-comp
  4. Reload the Comments page in the guide. You should be able to see 3 more tabs.
    http://<server>:<port>/content/community-components/en/comments.html

comments-comp-edit

  • Template Tab: It lets you see the template associated with the component. You can make changes to it, compile and see the results on the screen. Nothing will be saved in the repository.
  • CSS Tab: It lets you modify the CSS and see the changes on the component placed on the page.
  • Data Tab: To modify the.social.json associated with the component.

If you are a beginner and trying your hands with AEM communities, this will surely help you.

Hope it helps !! 🙂

 

Extending a Communities Component

More often than not, to meet the business requirement we need to create our custom components. It’s easy when it comes to AEM Sites, but I faced a lot of problems while extending the communities component. AEM Communities provides a lot of the OOTB components which in most scenarios meets our requirement. But, these components have basic layout and skinning. If you have to modify the appearance or behavior of the component that matches your site layout and meets the requirements then you would have to customize it. As explained in the documentation also  that there are two approaches for the same:

  • Overlaying: Overlaying the component changes the default component and affects every reference to it. Since we are overlaying, we would be copying it to apps hierarchy and then making changes to it. As paths are first looked into apps and then in libs. So overlaying it simply overrides the default behavior.
  • Extending: Extending the component limits the scope and is the recommended way to customize component.

While working on customizing the component, I faced quite a lot of issues. I followed this documentation but I was still not able to get it working. There is an issue here w.r.t the way clientlibs being defined. While defining the clientlib, categories  should be unique, as in this case

aembootstrap.communities.comments

clientlib-social

Add this as a dependency in the main clientlib.

clientlib1

After these changes, your component should work fine. It looks like below once you drag and drop this component to the page and post comments. 🙂

communities-example

I have also added it the Github Repository here.

Feel free to comment if you face any issues. 🙂

Hope it helps !! 🙂

How does Sightly template work?

In one of the earlier post, I explained how to create a multifield component in sightly and using sling models. In this post, I’ll talk about how to create and use “sightly templates” in your component. Templating is a powerful feature introduced in Sightly, which helps in keeping your code clean and makes it more reusable. Identify the repetitive code blocks in your markup, create a template and reuse it wherever it is required.

Let’s see how to create a template and how to call it:

  1. A basic template can be created by below snippet. Each template requires an identifier. For Instance, in the below snippet I have created a template in a file “message.html” with the name “message1”.
     <template data-sly-template.message1>
    <h2> This is template 1</h2>
    </template> 

    Now that the template is created, we can call using the data-sly-call and data-sly-use it as follows and use it in our code.

    <div data-sly-use.messageRenderer="message.html">
    <sly data-sly-call="${messageRenderer.message1}"/>
    </div>
    
  2. We have seen the example to create a basic template, now we’ll see how to pass parameters to our template.
    <template data-sly-template.message2="${@ message}">
    Message is
    <h2> ${message}</h2>
    </template> 

    To call this template in our code, we’ll have to use the below snippet.

    <sly data-sly-test="${properties.text}"
    data-sly-call="${messageRenderer.message2 @ message=properties.text}"/>

    The entire HTML will look like:template1If there are multiple parameters, pass it as comma separated values.

    <sly data-sly-call="${messageRenderer.message2 @ param1=param1,param2=param2 }"/>

Find the complete code in the Github repository.

Hope it helps !! 🙂