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)