Comment Architecture

January, 12 2017

Enablement, requirements, and options

Enable Comments

A quick trip to author/settings.html will allow you to enable comments. Once enabled, there will be a new section on the settings page to configure commenting options.

Important Notes:

  • If comments are enabled site-wide, all previous posts will have comments turned on by default.
  • If you wish to disable commenting on a post, you can do so by visiting the post and disabling the icon in the lower left hand corner.
  • If you decide to disable commenting site-wide, previous comments will still be stored in the JCR, but they will no longer show on any post.

Options & Requirements

Options are kept straight-forward. Google reCAPTCHA is a hard requirement to prevent spam.

  • Default Comment Status - This is used to determine whether to hold all comments for moderation or to allow immediate publish.
  • Google reCAPTCHA Site Key - Required - This site key enables reCAPTCHA services.
  • Google reCAPTCHA Secret Key - Required - This secret key enables reCAPTCHA services.

Publish Views

All comment related views are handled as AJAX calls against a specific end-point. The primary reason for this is to keep pages in cache, while still being able to keep up-to-date comment information site-wide.

Example Request


Example Response

As you can see, the response also contains the comment count in the payload. This reduces the amount of requests needed to get comments for a specific post.

Other Developer Notes

Within a given article tag, there are several properties to define what comment values should be pulled into a view. In the case of a list view, only the comment count is pulled in. In the case of a detail view, both the comment count and the list are pulled in. They are defined using data attributes.

How comments appears to a visitor

  1. The comments count is pulled via AJAX from hello-world.list.comments.json
  2. The comments list is also pulled from hello-world.list.comments.json
  3. reCAPTCHA is wired up through site and secret keys specified in author/settings.html
  4. When a comment is successfully created, the comment compose box will be removed, the comment will be posted to the page, and the cache will be evicted for the comment list end-point.

Author Views

All comment moderation happens in author/comments.html. Selecting a comment will expand the details for further refinement. Want to change status or edit the comment itself? All of that can be done here. Deleting of comments leverages the same ItemDeleteServlet used for pages and posts. Pagination also works very similarly to post and page authoring list views.

Areas of interest for developers

Below are some tidbits developers might be interested in.

  • Comments are created using a rep:SystemUser that is created in - I.E. No resolverFactory.getAdministrativeResourceResolver
  • Comments are stored in /content/slick/publish/comments/{slickType}/{item-name}/{comment-guid} This allows us to set a single permission level for all comments.
  • There is a CommentService (and implementation) that performs most of the list and creation of comments. The EditCommentServlet is used to validate the captcha. This area of concern may shift a little in the future.
  • Comment deletion is using the existing ItemDeleteServlet.
  • Most of the front-end is a combination of raw XHR, Handlebars, and JS. Much like the rest of Slick's client library stack.

Client Libraries

December, 25 2016

Slick's client library stack is built using Gulp, RequireJS, and SCSS for styling. Both JS and CSS are then (mostly) split between author and publish areas of focus. What does this all look like?


This folder is a combination of static assets and JS / CSS that gets compiled from src.

  • css - All CSS to power Slick. Broken out between author.css and publish.css
  • fonts - Slick uses the excellent and free font family, Lato.
  • img - All images to power Slick. This includes favicon.ico
  • js - author.js and publish.js
  • txt - Basically just robots.txt


The libs folder contains all external dependencies. If a dependency is used throughout the site (handlebars, highlight.js, etc.), it's pulled in as a module using a RequireJS config path. If it's used as a one-off for a specific page, it's left as a global object. Each dependency is broken into JS and CSS when needed. This keeps the structure similar to the other client library folders.

  • css
    • colorpicker - Styles the color picker in settings.
    • highlight-github-gist - Used to style 
  • js
    • colorpicker - Color picker functionality
    • handlebars - All client-side templating (mostly used for messaging and comments)
    • highlight - Format pre > code blocks
    • require - AMD library
    • rome - The calendar widget when creating / editing posts
    • wysihtml-toolbar - The editing UI for posts / pages / etc.


The src folder is where Slick's JS and SCSS are stored. Any piece of custom functionality will be located here.

  • js
    • author - The folder containing all author JS modules.
    • author.js - Defines what modules to include for authoring.
    • config.js - Our RequireJS configuration.
    • publish - The folder containing all publish JS modules.
    • publish.js - Defines what modules to include for visitors of the site.
  • scss
    • _base.scss - Very base level styles for tags. Also contains misc. utilities.
    • _colors.scss - Our colors file. This has been mostly deprecated in favor of variables.
    • _grid.scss - Slick's custom grid system powered by flexbox.
    • _rome.scss - Our calendar widget styles.
    • _variables.scss - Colors, sizes, etc.
    • author.scss - All author styles.
    • publish.scss - All publish styles.


Slick 2.1 Released

December, 22 2016

I'm very pleased to announce that Slick 2.1 is available for download. You can find it on Github, here.

As feature planning continued for the next release, it became clear that nips and tucks needed to be done throughout the client library stack. Most importantly, this meant removing our jQuery dependency in favor of pure javascript. This also meant an improvement to the javascript build system (hint, there wasn't one). Slick is now using RequireJS / AMD built via Gulp. Of course, all this rolls up into Maven nicely.

So, what's officially new?

  • Massive refactor of client libraries
    • src, dist, and libs are easier to understand
    • Better null / undefined checks
    • Removal of jQuery dependency
    • Javascript build process improvements
    • Entire JS stack is more DRY (unified messaging and HBS templates)
  • Editing an item (pages / posts) now correctly picks up publish status.
  • Accent color improvements for edit item pages.
  • Updated settings to tabbed format w/ deep linking and saving to separate servlets.
  • Publish styling improvements for highlight.js

Anything broken?

  • robots.txt and favicon.ico have been moved. If you run a production site, update apache appropriately.

What's next?

Comment support is probably the biggest upcoming feature. Next would be authoring improvements related to media. It's still far too difficult to get an image into a post. Social media analytics events are also low hanging fruit that should be addressed sooner rather than later.

SlickApacheSlingReleaseOpen Source

Analytics Support

December, 9 2016

Slick now has robust analytics support. This has been tested with Adobe Analytics, Google Analytics, and even Adobe DTM with Analytics and Target integrations! You can get the source code at GitHub.

Previously, Slick had a generic script tag in settings. By allowing head and foot tags, you have more choice in how you implement your scripts. In addition, specifying the service type will allow future integrations with these services. Including custom events triggered based on actions on the site.

Experience Managed is now exclusively powered by Adobe Analytics, Target, and DTM. You can see an A/B test below.

The Settings screen has been updated, and all analytics related OSGi configs have been moved into a separate PID as part of a refactoring effort.

Lastly, the old analytics script has been left for compatibility reasons. This is to prevent any breakage of existing sites. You should definitely move your script into in the appropriate script section. Here's the full settings screen...


Announcing Slick 2

April, 3 2016

Version 2 of the Slick Blogging Engine has been released. It's built on top of Sling 8, with both Oak and Sightly rolled in automatically. 

Download: You can get it on GitHub starting today.

End to end, there's been a ton of improvements:

For Authors and Readers

  • Easy to get creating content fast.
  • Creating and editing posts, pages, and media
  • Post and Page Scheduling
  • WYSIWYG Editor
  • RSS 2.0 Feed
  • Accent color support
  • Authentication and user management
  • Search
  • Dispatcher
  • Analytics, SEO, and social integrations
  • Pagination
  • Basic Localization

For Developers

  • Proper OSGi services and configurations
  • Much improved dispatcher support
  • Entire stack was re-written to be easier to maintain (Java, JS, Sightly, SCSS)
  • Front-end build process now part of autoInstallBundle (and using Gulp)
  • Project is now a custom Maven multi-module project similar to AEM Archetype
  • Travis CI Integration
  • Basic Localization string support


Experience Managed â ¢ Slick Blog


When Slick was originally released, there wasn't much direction other than, "I want to make a blog using Sling and Sightly." Fast forward a few months and it was clear that lessons learned demanded a complete rewrite. Along the same time, my friend Nate Yolles released his excellent blog engine, Publick.

Slick 2 takes those lessons learned, concepts from Publick, and combines them with the opinionated design that's been around since day one. It's built in a way to support (mostly) good design patterns across the entire stack.


First Run





Posts List

Edit Post

Settings (Theme, SEO, Dispatch)


User List


RSS Feed

Basic Localization

Slick 2ApacheSlingOakSightlyJava