CMS Best Practices

Don't include JQuery libs at component level

I have seen so many people who include JQuery libs at component level, the disadvantage of including at component level is for each and every component the system will make request to server to download JQuery libs and it may lead to page performance

Sometimes we get lot of undefined JavaScript errors because of loading multiple versions of JQuery libs

Solution:

Maintaining central location, I suggest create client libs and include at Basetemplate level, if new version comes just update client libs

In some scenarios the system will force you to include at component level, in such cases use JQuery.noConflict () option to avoid conflicts

Consider that the AEM also provides JQuery libs, some functionality which is depending on particular version of JQuery then download into your clientlibs; otherwise try to utilize OOTB JQuery Libs

Don’t deploy CSS or JS files in to production

Is it right approach deploying CSS, JavaScript files as part of deployment package in “Content Management System”?

Why,  because I have seen some people who came from traditional web development and no knowledge on CMS trying to deploy css and js files through package and finally mess up entire environment like overriding content of css and js files of content authors

How can we handle this situation, in any CMS you can find two types of content one is static content and another one is dynamic content

Dynamic content:

The content which you think it changes frequently by content author or admin’s need to be handled by content deployment or replication or page activation

Ex: Style sheets, images, text etc…

Normally, the content authors or site admin’s performs this action

Static content:

The content which you think it will not change in future need to be deployed as package such as style sheets, images, JavaScript files etc…
This is the developer job and the developer includes this content into package and deploys into a respective environment

Solution:

Don’t include css and js files in your deployment package, if you feel the content author is going to modify it, keep it in central location which can be accessible by content authors as well as developers

Normally in SharePoint you can do this by placing style sheets in style library and in CQ5 you can do this by putting in etc/designs folder

Don’t deploy configuration file in to the production environment

The general meaning of configuration file is to change settings of system at any time, but if you deploy your settings through deployment package that may override existing entries which has made by author and the system may go down

I strongly recommend don’t deploy your configuration settings through package which you feel it changes frequently

Always create I18n folder at site level not at component level

Don’t create I18n folder at component level, if you create your I18n folder at component level you may lose certain capabilities,

Suppose in future if you want to create new locale it is very difficult to check entire solution to identify I18n folders, which needs to convert into new locale and which may lead to maintenance issue and moreover there is a chance for duplicate entries

These duplicate entries may override existing ones and you need to spend lot of time to debug the issue

Always use locale copy while creating new website

Don’t create web site by simply creating pages in hierarchy manner, it is very difficult to implement MSM

The page nName needs to be in the format of or _, for example en, en_US, en_us, en_GB, en_gb.
•    The supported language code is lower-case, two-letter code as defined by ISO-639-1
•    The supported country code is lower-case or upper-case, two-letter code as defined by ISO 3166
 
Don’t iterate nodes, try to use Query Builder, if you are performing any search operation


Use Case:

The user shall be able to receive news based on subscribed opt-in's

The Taxonomy for news is

    Therapy area news                                         
    Oncology news       
       
While registering into site the end user select’s any of news taxonomy keyword either Therapy area or oncology, based on the selection the system will send respective news related email’s to the user

Here, don’t iterate each and every user node to find out opt-in, try to use query build to avoid performance impact

The sibling nodes should not exceed more than 2k

Keep in mind that the sibling nodes should not exceed more than 2k , under normal circumstances it is fine like simple creating and reading node’s but, if you are  performing any kind of search operation on these nodes this may impact on performance


Don't enable dispatcher level cache in lower environment only enable in production environment

Don’t enable dispatcher level cache in lower environment, if you are planning to do load testing, test it on lower environments either pre-prod or the environment which is similar to your production box

Always make sure the cache should be enabling in production box, initially this may impact on performance but while going forward the performance will increase

Before enabling cache in production box think about your application digital asset size, if the volume of size heavy, then it is better to enable cache ASAP

All environments should be in sink to avoid surprises

Always make sure that the environments should be in sink to avoid last minute surprises, I strongly recommend don’t directly work on production environment if you face some problems in production environment, first fix it in pre-prod environment , then test it in prod author and finally fix  it on publish environment

I recommend first deploy package in author and publish environment then replicate content from author to publish environment, before replication content check all configurations are fine or not

I have seen some people who directly work’s on publish environment and making entire system down, but this is not right approach


Don't do over architecture keep it simple


While developing components don’t do over architecture keep it as simple as possible, sometimes the over architecture may impact on performance, for simple components try to reduce layers


Don't store PII information in cookies


The Personal Identification Information is very important for any client, so don’t store PII information in cookies like user password, social security number etc,..

Try to leverage to use OOTB functionalities


Once you receive requirements from your client first check whether it is feasible with OOTB functionality or not, if it feasible then tries to use OOTB, if it is not feasible then only start developing custom components

Identify Data Model before start developing custom components

Choosing database is not an big difficult just compare relational database features with JavaContentRepository features

Ex :

For some of the requirements demands versioning capability, in such cases the relational database does not support versioning functionality, so we need to think about JCR

Avoid loading unnecessary dependencies in POM files


Try to avoid loading un-necessary jar files through POM entries, identify all required common jar files and create separate module and import that in to other modules

This we can achieve only through user education


Don’t refer untrusted resources


I have seen some components which is directly referring like below code


The best practice is download the .js file to your solution and refer it

Use CDN 


To achieve greater performance, if possible try to implement CDN, but this totally depends on client

Don’t hard code CDN server url while making image, video, file etc… it is very difficult to identify each and every link

Create separate Filter which parse each and every url, if it is a digital asset then redirect to CDN server to download that Digital Asset

Create custom error pages


For any website the custom error pages are mandatory like 500 server error, 404 not found etc… if we directly display as it is then this will directly effect on overall website credit

So always design custom error message pages and apply it


XSS

Cross site scripting enable attacker to inject maliculious code in to your system, so don’t forget to encode user inputs before submitting form

Use XSSFilter in CQ5 to validate User entered information

 Know the difference between Sessions

If you see Any CMS there are two sessions one is Admin session and another one is User Session

For read only operations use User sessions and if you are doing some edit and update operations then go with admin sessions

If the requirement is just reading items or nodes and display it on a page then just go with user session

Try to avoid using admin sessions , if  you are obtaining inputs from end user try to store into /content/usergenerated folder in content repository

For just reading nodes and properties use user session slingRequest.getResourceResolver().adaptTo(Session.class)