Wait what? These aren’t the same thing?
No! They are not! Runmodes are global and AEM has two build in: author and publish. Most all AEM developers are familiar with these because of the jar naming conventions, e.g. “cq5-author-4502.jar” or “aem-publish-4502.jar” as taught in Adobe’s component developer classes.
These run modes correspond loosely to wcmmode settings — edit, design, and preview mode in author and “disabled” in publish.
What most AEM developers never learn is that runmodes are NOT limited to the built in author and publish modes. In fact, you can have whatever runmodes you like, and more than one can be active at a time.
Custom Runmodes
There are a number of ways to set custom runmodes. I won’t go into detail here as the linked article from Adobe covers the primary methods of setting the runmodes on startup. Instead, I’m going to cover the main usage.
There are a number of ways to set custom runmodes. I won’t go into detail here as the linked article from Adobe covers the primary methods of setting the runmodes on startup. Instead, I’m going to cover the main usage.
Using custom runmodes for user-specific configurations
In most AEM projects there are development, UAT, and Production environments. In those environments, it’s not uncommon to also have a full AEM stack — author instance, publisher instance, and dispatcher running in either Apache or IIS. Using the standard sling:OsgiConfig nodes and the config.author and config.publisher folders, you can set configurations for author and publish instances — but what if you need specific configurations for development, uat, and production environments? This is where runmodes are quite useful. By adding a known runmode at launch, it is easy to keep and maintain OSGI configurations for different environments in a shared codebase and know that these configurations will only be active in the appropriate environment.
For instance, you may want to have extensive logging and error handling enabled in the dev environment, but restrict visual presentation of errors in production. This is a great time for config.production and config.development folders containing sling:OsgiConfig nodes along with custom production and development runmodes.
Just make sure to be careful with your testing. Don’t add runmodes and settings in production that you haven’t tried in development and UAT. As a general rule, Production should be running a restricted and not expanded number of settings.
In most AEM projects there are development, UAT, and Production environments. In those environments, it’s not uncommon to also have a full AEM stack — author instance, publisher instance, and dispatcher running in either Apache or IIS. Using the standard sling:OsgiConfig nodes and the config.author and config.publisher folders, you can set configurations for author and publish instances — but what if you need specific configurations for development, uat, and production environments? This is where runmodes are quite useful. By adding a known runmode at launch, it is easy to keep and maintain OSGI configurations for different environments in a shared codebase and know that these configurations will only be active in the appropriate environment.
For instance, you may want to have extensive logging and error handling enabled in the dev environment, but restrict visual presentation of errors in production. This is a great time for config.production and config.development folders containing sling:OsgiConfig nodes along with custom production and development runmodes.
Just make sure to be careful with your testing. Don’t add runmodes and settings in production that you haven’t tried in development and UAT. As a general rule, Production should be running a restricted and not expanded number of settings.
WCMModes in AEM
AEM’s WCM modes are much more restricted than runmodes. As of now, there are only 6 WCMModes: Edit, Design, Preview, Disabled, Read Only, and Analytics. The Analytics WCMMode is relatively new and was added in CQ 5.6.
While runmodes and wcmmodes are related (specifically, the publish runmode restricts what wccmmodes are available and their behavior), the wcmmode is not a global property of a given AEM instance. Components on a single page can be rendered in multiple WCMModes under programmer control. For instance, in many projects, I restrict the editing of global headers and footers on most pages by including them using an iparsys, and then having that iparsys load in WCMMode.DISABLED except on specific templates.
AEM’s WCM modes are much more restricted than runmodes. As of now, there are only 6 WCMModes: Edit, Design, Preview, Disabled, Read Only, and Analytics. The Analytics WCMMode is relatively new and was added in CQ 5.6.
While runmodes and wcmmodes are related (specifically, the publish runmode restricts what wccmmodes are available and their behavior), the wcmmode is not a global property of a given AEM instance. Components on a single page can be rendered in multiple WCMModes under programmer control. For instance, in many projects, I restrict the editing of global headers and footers on most pages by including them using an iparsys, and then having that iparsys load in WCMMode.DISABLED except on specific templates.
No comments:
Post a Comment
If you have any doubts or questions, please let us know.