Product Roadmap

Below are dotCMS features and directions that are currently in the discovery and priortization phase of development. Because internet technologies are moving so quickly, projecting dotCMS development priorities beyond a 6 to 9 month window does not provide meaningful information.


View and comment on GitHub
  • Reimagine Visitor Analytics (in progress) »

    Labels: Cat : Privacy Epic
    Created: May 9, 2018 4:16:54 PM
    Comments: 1 (comment now)

    We need to remove our legacy clickstream logging and rebuild it around a different analytic engine, e.g. elasticsearch.

    This is a multi-part epic that includes

    • realtime visitor information logging
    • js web bug for static site inclusion
    • ingest logs into elasticsearch cluster
    • dotCMS Proxy to access/query elasticsearch data
    • Dashboard and contextual analytics available in application
  • Content Metrics (in progress) »

    Labels: Epic
    Created: May 6, 2016 3:54:39 PM
    Comments: 0 (comment now)

    • move Clickstreams to External Storage
    • Much like the cache Interface, we need a pluggable storage mechanism for Visitor Object and ClickStream Data
    • ES will be our first concrete implementation (maybe a db impl as well)
    • Data does not look much different than it does now - Clickstream records page views and content (URLMapped) views.
    • Use native ES Mapping types and allow native ES queries
    • Allow a different ES endpoint to be specified for the Clickstream index vs. the Content index (or the same)
    • This is a first step for any metric or content performance measurement work
  • Authentication Modernization/Cleanup (in progress) »

    Labels: Epic
    Created: Mar 2, 2017 3:12:30 PM
    Comments: 0 (comment now)

    We need to update our authentication mechanisms.

    • This involves cleaning up messy/duplicated code throughout the system.
    • Integrate Frontend and Backend Logins. Collapse the difference between front and back end users and basically have 1 type of dotCMS user.
    • Disallow users from backend access if they do not have any tabs / tools (moving forward, this will be the only distinguishing characteristic between “front” and “backend” users)
    • Provide Single way that all authentication is managed in our system. Standard API that is only dotCMS aware.
    • Allow Authenticators to be developed and deployed as OSGi plugins
  • Customize Template layout per page (in progress) »

    Labels: Epic
    Created: May 6, 2016 3:45:22 PM
    Comments: 0 (comment now)

    • From Edit Mode (if the template is a theme based template) a user can click “Customize Template for Page”
    • This would create a copy the the template that could be customized for that one page and assign that copy to the page
    • This “Customized Template” would be hidden by default on the template screen, though could be revealed via a checkbox on that screen
    • These “customized templates” would be completely hidden from the template chooser control on the page properties screen, unless it is has already been chosen by the given page
  • Update Form Builder (in progress) »

    Labels: Epic
    Created: May 6, 2016 8:34:26 PM
    Comments: 0 (comment now)

    The form builder will need to be updated when the edit content screen in dotCMS is moved to Angular 2. We will develop an Angular 2 js client that will automatically generate the form on the front end for customers

  • Machine Learning and Predictive Analytics »

    Labels: Epic Requires Sponsor
    Created: May 6, 2016 3:57:59 PM
    Comments: 0 (comment now)

    We have successfully implemented a plugin that integrates dotCMS images with AWS Rekognition to auto tag images in dotCMS ( ) . We need to continue and expand this work to:

    • Have content auto classified and auto tagged based on bayesian or smarter tech
    • Build recommendations based on accrued tags
  • Implement non-SQL based content Store »

    Labels: Epic Requires Sponsor Under Consideration
    Created: May 6, 2016 3:53:51 PM
    Comments: 5 (comment now)

    dotCMS stores content in a database table called “contentlet” (files are on a FS). We need other implementations of the content storage that can store and retrieve content in other ways, such as from a noSQL solution. dotCMS will create a ContentStore interface that can be quickly implemented to store content in a variety of NoSql Solutions (very much like the current CacheProvider interface did for our caching layer) and create a proof of concept NoSQL implementation to store content as JSON on the filesystem under the /assets directory in a B-tree directory structure.

    • When a user creates a new ContentType, they will be able to select what Storage Provide they would like to use to store the content.
    • dotCMS will develop a RESTful interface for the management of ContentTypes and Field definitions
    • All metadata surrounding and tied to a content object's Identifier will remain in the DB, including:
      • Identifier table info
      • VersionInfo Information
      • Permissions
      • Tags
      • Languages
      • Categories

    Content will be indexed in elasticsearch as it is currently regardless of where it is stored. NoSQL providers can remove the current 25 field type field limits if as their implementation provides.

    The StorageProvider would be an option when creating a new content type (Choose Storage:) maintain all backward compatibility

  • Scheduled Push Plugin »

    Labels: Epic Requires Sponsor Under Consideration
    Created: May 6, 2016 3:47:30 PM
    Comments: 0 (comment now)

    • Phase 1 - no UI
    • Intended to keep multiple installs in sync without intervention (DR or Auth → Prod)
    • I like the idea of specifying what to send via a lucene query (can include pages, files, hosts, specific content types, etc..)
    • Include one or multiple environments to push to (or allow for multiple jobs)
    • Email on final push failure
    • Plugin can be installed multiple times for multiple schedules
  • Read only Mount External Resources (GIT, DAMs) »

    Labels: Epic Requires Sponsor Under Consideration
    Created: May 6, 2016 3:51:03 PM
    Comments: 0 (comment now)

    Customers want to store their files and assets in 3rd party reps. dotCMS needs to allow for these hard assets to be retrieved from external file repositories and accessed via dotCMS. We need to develop an extensible remote repo interface that will allow for plugable implementations to be developed. These remote repos will:

    • Shows up in “browser” views for file selectors (maybe as sites?)
    • Allow an administrator to mount an external DAM or Content Repo as a shared drive in the CMS
    • Allow external resources (images, .vtls, documents) to be referenced in dotCMS for inclusion into a site or sites.
    • Not indexed by dotCMS, just browseable, useable.
  • Enterprise Support Reporter »

    Labels: Epic Under Consideration
    Created: May 6, 2016 4:20:07 PM
    Comments: 3 (comment now)

    dotCMS needs a way for customers collect and report on the general config and health of their installations. This can be a maintenance tool that build a folder and report files and zip these up to single bundle of information, and submit it (securly) to support portal. This bundle will contain support reports like:

    • the results of show processlist or db specific equiv currently running queries
    • the customer's current context.xml (let's parse the xml and not include the username and password). (Tomcat customers only).
    • a screenshot of the cache stats screen (we will have to render the html and spit it out)
    • The current
    • A threaddump or a few threaddumps (can use the same Threaddump as is already in the maintenance portlet).
    • The last 5000 lines of their current dotcms.log using the java tail class we use in the tail log servlet. (Tomcat customers only).
    • The JVM stats and other env info from the system info page
    • a list of all scheduled quartz jobs
    • a list of all plugins in the osgi folder
    • results of a db select from cluster table
    • complete ES index list and status.
    • How long dotCMS took to start up

    These reports should each be generated via single classes that implement an interface and if any of the reports fail, the rest of the reports should still continue. This will allow us to grow the list of “SupportReports” we can run as we find other areas that we need reporting on.

    Business case, when we have any support incident, we need a single way to get information from our customers.

  • Content Variants »

    Labels: Epic Requires Sponsor
    Created: May 6, 2016 8:42:23 PM
    Comments: 0 (comment now)


    Currently, dotCMS has the concept of variants in another form - as languages. In fact, you could almost just run with our language functionality and use it to provide persona-ized content. We need to expand the concept of languages to include other variations of content such as “Mobile Friendly” or “European Visitor”

    Variants are like branching in a VCS - only the content that is changed for that variant needs to be persisted and you can only “branch” from a root branch. See variant hierarchy below.

    Additionally, we build a tool to merge one variant with another branch. What this means is that editors can create lightweight variants that can act like change sets and be merged into the main branch when the editors are ready to publish.

    A site visitor can only have one variant, which gets overwritten when the visitor actions match another ruleset or the view_token is passed in via url

    Variant Editor / Creator

    Simple Crud interface RestPortlet Ajax/JSON based table dot_variant id name view_token - varchar - a token that can be passed in via url to change the variant. small_icon - binfile to represent the variant. Think language flags. Can be stored in the db big_icon - binfile to represent the variant. Can be stored in the db

    Variants should be a permissionable, I believe. This will be important when leveraging them for VCS. An editor can only see/manage the variants they have access to.

    Site Editors will be able to select what variant they are viewing a page as (just like we do with languages). We will need to remember the last variant they were viewing as and keep that value in session and use it wherever appropriate, like the content search screen.
    When editing content and a the user wants to make a copy for a personalized “variant”, they just select the variant from the drop-down list (just like languages now). The system asks if they want to copy the content (from the variant they were previously viewing) and away they go.

    To discuss - potentially content inheritance is going to be too error prone and we should avoid. By content inheritance, we mean: You have a piece of News content for the main site with a title called “Baby Monitors for a Smart Nursery, but Parents Are Still Better.” among its many properties. A user selects that and chooses to make a mobile variant of the article and chooses to only overwrite the tile to a shorter mobile friendly “Smart Baby Monitors Suck” or whatever. When that piece of content is retrieved, it has all the properties of its parent article but has the overwritten title and when an editor updates the news story on the parent content, it would be updated in the mobile version as well. We can always come back and do this when we improve the content model.

    Variant Hierarchy (If we can do away with this, fine. If we need to make it multilevel, fine) Two level hierarchy - Root level and their children Children cannot be specified as the parent of another variant - only variants without parents can be parents. We will still need a “Default” variant if none is set. Can be set in config - no UI

  • Experiments and A/B Testing »

    Labels: Epic
    Created: May 6, 2016 3:55:19 PM
    Comments: 0 (comment now)

    • Show variations of content or pages based on A/B test params
    • Allow a site manager to define goals.
    • “Successful” content (driving more users to their goals) would begin to be shown more often
    • Reporting and Metrics - requires different clickstream impl
    • Could be built upon rules engine