Extending the communities component – Part 2

In one of the earlier post, I talked about extending the communities component. While working on this in my project, I faced another problem. I had a use case to override the toolbar in order to adhere to the custom styles we wanted to apply on the component.

Problem:

  • In comment.hbs, the below line includes the toolbar.hbs. 
{{include this template="toolbar"}}
  • The problem that I faced was that my template changes were not getting picked. I was over-riding the toolbar.hbs, but it was always picking the default OOTB template file.
  • The reason is that whenever we post a comment, it gets saved in the usergenerated content and resource type always points to the OOTB component.community.PNG
  • This resourceType property gets picked up and passed as a parameter to a servlet which resolves the template. You should be able to see the below call in the networks tab of the browser.

http://localhost:4502/services/social/templates?resourceType=social/commons/components/hbs/comments/comment&ext=hbs&selector=toolbar

Solution:

To resolve this issue, we need to tell AEM that it needs to pick our custom resource type rather than OOTB one. There is a configuration for this in the component.

  • Go to the design mode and open the design dialog for comments component.

communities-design-dialog

  • As shown in the above image, you need to specify the path of the custom comment resource type that you want to use in the design dialog. Once you save the changes, you should be able to see your template loading fine.

Hope it helps !! 🙂

Advertisements

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 !! 🙂

 

Mod Proxy | Trailing Slash Issue

If you are using mod_proxy in apache and facing the trailing slash issue i.e. an extra slash is appended after the URL. For instance, if you are hitting http://mydomain.com and it  is getting redirected to http://mydomain.com// then make sure you don’t have a configuration like this.

ProxyPass "/" "http://mydomain.com"
ProxyPassReverse "/" "http://mydomain.com/"

It can be easily fixed by having the trailing slash in both the statements i.e.

ProxyPass "/" "http://mydomain.com/"
ProxyPassReverse "/" "http://mydomain.com/"

I faced this problem recently in one of my projects. I found this fix so shared it.

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 !! 🙂