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.

Roadmap

View and comment on GitHub
  • RESTful management of ContentTypes (in progress) »

    Labels: Epic Release : 3.8.0
    Created: Jul 15, 2016 4:02:11 PM
    Comments: 0 (comment now)

    We need to make the management of contentTypes completely RESTful and implement more modern code patterns.

  • Modernize UI (in progress) »

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

    • Begin developing the Angular2 framework we will use to re build UI
    • Begin re-writing core UI functions using Angular 2
    • First Candidates : Browser Tree, Edit Mode
    • Second Candidates: Content search, Content edit
    • Trying to turn dotCMS/admin into a 1 Page app or Angular 2 Portlet Framework?
    • Have a base ng2 app in the dotCMS backend to allow us a single app that we can add components/directives - as a framework for future buildout
    • Angular 2 Portlet will act like the RestPortlet - in the sense that screens will load, inline
    • Dynamically generate the NG2 routes based on the Angular2 portlets in the backend.
  • Allow Files to be Multilingual (in progress) »

    Labels: Epic
    Created: May 6, 2016 3:49:31 PM
    Comments: 2 (comment now)

    • Currently, files are not multi-lingual. We should allow this.
    • Unit test, Unit test
  • JWT based Authentication (in progress) »

    Labels: Epic
    Created: May 6, 2016 4:01:41 PM
    Comments: 0 (comment now)

    • /html, /c should be a disallowed path for non-users
    • Remove login logic from login.jsp, MainServlet and PortletRequestProcessor and put in a Filter
    • Maintain backward compatibility with current LDAP, AD and other custom providers
    • Stop the “authenticate then redirect portlet madness”. If a user has “remember me” checked and hits a backend url with a new session, they get logged in and shown the url.
    • Token based logins
    • Allow an administrator to create auth tokens that can be shared to allow for automatic logins. These tokens can have a start date, end date, and a user that the token will authenticate as. These tokens can be added to a link
  • Implement non-SQL based content Store »

    Labels: Epic Road: Requires Sponsor Road: Under Consideration
    Created: May 6, 2016 3:53:51 PM
    Comments: 4 (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

  • Content Metrics »

    Labels: Epic Road: Requires Sponsor Road: Under Consideration
    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
  • In-site Google Analytic Reporting »

    Labels: Epic Road: Under Consideration
    Created: May 6, 2016 3:40:06 PM
    Comments: 0 (comment now)

    Site managers want to have a single place to manage and report on their sites performance. Additionally, now that Google is sharing less and less data, more companies are moving at least some of their analytic capabilities to google analytics. Google provides an api that would allow us to build a screen within dotCMS to report on a sites performance without the site manager having to leave dotCMS.

    • Provide Site managers a screen that would call google analytics API to render google traffic and analytic data in dotCMS.
    • RestPortlet
    • I think we will need to use the API becuase the Embed code is tied to a user - we will need app level permissions
    • Jason Smith will be the story owner
  • “Preview As” for Mobile Preview »

    Labels: Epic Road: Under Consideration
    Created: May 6, 2016 3:44:34 PM
    Comments: 0 (comment now)

    • Preview a page as mobile devices
    • Use Device Definition files that can provide Viewport, breakpoint and skin information
    • Customers can provide their own Device Definition Files
  • Customize Template layout per page »

    Labels: Epic Road: Requires Sponsor Road: Under Consideration
    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
  • Scheduled Push Plugin »

    Labels: Epic Road: Requires Sponsor Road: 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 Road: Requires Sponsor Road: 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.
  • Workflow Phase 2 »

    Labels: Epic Road: Under Consideration
    Created: May 6, 2016 3:57:15 PM
    Comments: 0 (comment now)

    • Allow a single workflow action to be associated with multiple workflow schemes and steps. Having this would allow us use specific workflow actions across large swathes of content (batch actions)
    • Allow a single workflow action to be available for locked and/or unlocked content
    • Content Workflow screen becomes a board view of content in various phases, which can be viewed and or dragged to the next or previous step.
  • Machine Learning »

    Labels: Epic Road: Under Consideration
    Created: May 6, 2016 3:57:59 PM
    Comments: 0 (comment now)

    • Have content auto classified and auto tagged based on bayesian or smarter tech
    • Build recommendations based on accrued tags
  • Enterprise Support Reporter »

    Labels: Epic Road: 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 my.dotcms.com 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 dotmarketing-config.properties
    • 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.

  • Static Publishing »

    Labels: Epic Road: Requires Sponsor
    Created: May 6, 2016 4:00:29 PM
    Comments: 0 (comment now)

    • Ability to statically push to a remote endpoint
    • When configuring a PP endpoint, allow a user to select a static folder on the server or a script to execute.
    • Allow push to S3 (and thus cloudfront), remote server via rsync.
    • Prime only feature
  • Vanity URL Rebuild »

    Labels: Epic Road: Under Consideration
    Created: May 6, 2016 6:28:07 PM
    Comments: 0 (comment now)

    We need to update our vanity url impl

    • The table should not extend Inode class
    • id
    • title
    • host identifier (system_host = global)
    • uri field (can be > 255 char)
    • regex with matchers?
    • active (bool)
    • last mod date
    • response code (301, 302)
    • redirect or forward (requestdispatcher)
    • Run First OR Last
    • Support urlrewrite
    • Use Tuckey under the covers?
    • how does this affect current tuckey users?
    • Push Publishable
    • provide bulk edit capability - csv import / export?
  • Update Form Builder »

    Labels: Epic Road: Under Consideration
    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

  • Content Variants »

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

    Variants

    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