The public release beta of dotCMS 2.0 has been out since March. Prior to that, the current stable version, 1.9.5, was released. This month, they also made the long anticipated move away from traditional SVN over to Github. Needless to say, 2012 has been busy, and the 2.0 release has been a long time coming. With that said, if you’re looking at dotCMS for the first time or wondering if it’s worth upgrading from 1.9.5, I wanted to look at a few of the features coming in 2.0 that you’ll likely want to note. These are some of the bigger singular items, but there are countless other improvements, bugfixes, and tweaks as well that cumulatively are just as important.

So, in no particular order, we’ll start with the…

1:) Multifile Uploader

Multifile Upload Popup

Multifile Upload Popup

This is a personal victory for me. Not because I had anything to do with it, I’ve just been griping about the multifile upload tool since version 1.5. Prior to 2.0, users were limited to uploading only up to 19 files at a time (through the browser – not if you had WebDav access), and even then, it was through a form with 19 input fields. It was cludgy, slow, and not at all user friendly. This is a big step forward to much more efficiently facilitate the upload of large batches of files.

I’d like to see this tool continue to evolve, for instance emulating other systems’ ability to do things like explode a zip file and selectively upload the contents. Maybe show image thumbnails, and let you edit metadata prior to saving. A progress bar or inline visual uploading (a la Flickr) would be nice for general UX. A lot of ways you could go, but this is a big step forward in the area of file management, and I’ll take it.

2:) Files on Root

Admittedly, this is a pretty simple addition, but for everyone that’s ever created vanity URLs or URLRewriteFilter rules to handle things like favicons or robot.txt files, this will be a welcome addition. Just like it sounds, you can now have files that live at the root level of a host. There are always reasons for this, whether the aforementioned, or other things like Google Webmaster Services, that allow you to authenticate ownership of a domain by placing a simple HTML file on your server.

3:) Key/Value Pair Field

Key/Value Pair Content Field

Key/Value Pair Content Field

If you’ve ever used Custom Fields in WordPress, this new type of structure field should be very familiar to you. The key/value pair field is going to provide a great way to add custom additional data to contentlets that may not always warrant an entire field, or in cases where you don’t need to care as much about the UI as the data. Or, use it as a way to include debug data or test fields with a contentlet while you develop, without needing to expose your day-to-day users to additional interface weight. Better still, if you’re an e-commerce site or someone that has to deal with products or items that have varying specs, you can use this type of field to help easily build out things like feature tables.

One other use that comes to mind that has varying usefulness depending on your organizational structure is this: if you’re in a situation where you would benefit from being able to give certain people access to sets of data that might get repurposed and reused across the site, but you don’t want to convince them to edit Velocity variables, you could set up a “Dataset” structure with a title and key/value pair field that they can populate. Then, you pull the appropriate data set in to pages across your site (financial aid info, user demographics, sports statistics, etc).

I’ll look forward to possible improvements in the future, like inline editing and autosuggest for keys and values. All in all, this is a pretty raw way of dealing with data on a contentlet, but really, sometimes that’s just what you want.

4:) Files as Content

Setting up a new File content structure

Setting up a new File content structure

Files as content is another natural evolution of one of the internal cogs of the system, and it won’t be the last. In 1.9, hosts and forms became content. At some point beyond 2.0, I suspect we’ll see users and pages as content as well. The content engine is really the heartbeat of dotCMS. The evolution we see is taking something that used to be rigid and static in the system previously, and allowing you to extend it as a structure. This dramatically improves dotCMS’s ability to serve as a lightweight DAM solution, as well as CMS. At the same time, it can give you access to additional file metadata you wouldn’t have otherwise when you include or link to it (besides what is now extracted automatically from files and indexed along with it, like image EXIF data). Now, you can pull and query for files in dotCMS just like content.

Don’t be fooled, this is a pretty significant step forward for asset storage in dotCMS. Just the fact that now meta data is extracted as key/value pairs by itself is pretty important (imagine the possibilities for file repositories, photo galleries, etc).

5:) ElasticSearch

ElasticSearch is a somewhat more invisible change for a lot of folks, but it’s important nonetheless. Why invisible? Because it sits on top of the Lucene engine, but in such a way as to be able to wrap the old queries (similar to how the move from 1.7 to 1.9 went with the newer syntax, and 1.9 just magically let the old syntax work). So, the syntax itself doesn’t need to change for any of your content pulls and queries. Where this becomes an important change though is for larger users, especially in clusters. Lucene by itself was, frankly, not awesome at replicating the index across several hosts. ElasticSearch is designed to handle that exact issue, providing excellent scaling across multiple nodes, not just a single node with more resources. It’s fast, lightweight, and error resistant.

What I really want to look in to though is that while ElasticSearch supports traditional Lucene syntax, it also supports JSON based queries as well. I’m not sure if this is exposed in 2.0, but the implications are pretty big, including the possibility for regular expression based queries, result scoring, and more. While it may not be readily accessible in dotCMS 2.0, it is a part of ElasticSearch, so it’s conceivable that we’d see it exposed in a future release.

6:) Custom Workflows

Default Workflows in dotCMS 2.0

Default Workflows in dotCMS 2.0

Workflows have always been a feature I’ve scoffed at. This is mainly because I see them as a feature that is more for marketing than actual use. It demos well, as I say. Ultimately, I’m not sure I’ve ever seen an organization implement a workflow within a CMS particularly well or consistently, whether in dotCMS or any other system. That said, the addition of custom workflows (for enterprise users) is a vast improvement over the prior implementation. Pre-2.0, workflows were little more than a system of tag for users – sending rough messages back and forth, possibly with a link to what you were supposed to do. Nothing else, and nothing about it was binding within the business logic.

Now, there is an actual rule system that allows you to create a process through which a contentlet or item must travel, and it’s tied to this workflow logic so that you can enforce the process. But, this is by no means a particularly simple system to set up, as the power brought with it the tradeoff of the complexity necessary to create all the rules and conditions content can go through at different steps.

Is it really a good enough improvement that I think people will flock to it and use them across their sites? No, probably not. That’s not because it’s a bad feature, but rather the result of the problem of meshing programmatic workflows with human workflows. But still, you should know what it does and how to leverage it, as there is a lot of upside if you can make it work within your people infrastructure. Even if it’s just forcing something like a proofreading step by a content strategist.

7:) System Host

Like being able to store files on the root of a host, this is a seemingly simple thing that just makes life happier for everyone. If you host multiple websites in one instance of dotCMS, you’ve no doubt played with how content lives on different hosts to silo it. Other folks have ran in to issues where they want to share things like VTL files across domains (which was possible pre-2.0 by doing something like a #dotParse('//someotherhost.com/common/vtl/shared.vtl')). But obviously this meant that your VTL had to live on one of your hosts, and that if you needed a shared resource pool, you had to permission accordingly – even if it didn’t make sense on the host where the pool was. Normally, where you saw the SYSTEM_HOST was in content queries. In 2.0 though, it’s an actual thing. This makes it a great tool for building a resource repository for all your other sites. You access it like any other host from the Website Browser – just click on the “Change Host” dropdown and select “shared.”

8:) Content Locking

Locking panel and content actions.

Locking panel and content actions.

Prior to dotCMS 2.0, opening content for editing caused the content to lock. The problem was, this was little more than window dressing, as a single click allowed you to override a lock, regardless of who you were. So really, locked content was just more of a warning, than a lock. The other problem was that users could easily click in to a piece of content, but use the back button instead of the cancel button, thereby leaving a lock in place for days, weeks, or longer.

Now, you cannot edit a piece of content without taking the next step of locking the contentlet. You must do this as an actual action. Then, once locked, it is truly locked. Another using stumbling across it can’t accidentally open it while you have it open and edit and save it if you have it locked.

It’s all about helping to maintain integrity of the data in environments where multiple people might try to edit the same thing. While I think this is a good improvement, I hope the UI is improved. I can’t tell you how many times in testing I’ve clicked right on the content form out of habit expecting to update something, but instead get the red flash of the “Lock for Editing” button. I’d like to see the content form not look like a form when it isn’t locked (e.g. no borders on text fields, or a red shade to fields, or a light gray overlay – something that provides immediate, obvious visual feedback so you don’t forget). Sort of like the new category selector from 1.9, if you’re upgrading you can expect this feature to take some getting used to while users new to dotCMS in 2.0 will probably take it in stride. Personally, I don’t mind the trade off for the extra reinforcement within the data model.

9:) Spring MVC

I won’t dive too deeply into this, mainly because Will over at dotCMS has already done a good job explaining it. But the gist of it is that it allows you to create functional plugins with only the use of a single class that gets mapped to a page in the /application/spring path on your site. This is somewhat similar to what you may have chosen to do in the past with Struts, but with less overhead.

Ultimately, this is just another option for folks that want to extend dotCMS. It’s somewhat less intimidating that Struts, and needs less configuration, which is nice. However, I’ve always felt one of the biggest barriers to the community extending the system wasn’t the framework, but simple availability of open source Java devs interested in helping out a project like this. Spring has the advantage of being easy in the right places though, which may spur some folks to start taking a serious look at new plugins.

10:) Social Integration

Twitter update box from asset.

Twitter update box from asset.

I said this was a list of ten things. Really it’s nine plus this bonus. I almost don’t want to count this because it’s a toy, in a way. When editing assets in 2.0, you’ll notice in the action sidebar where you lock, save, and publish assets, there’s now an option to “Tweet This!” It’ll generate a bit.ly link for you, and allow you to announce the publishing of your asset. The bit.ly link isn’t automatically inserted in the text field, which is a little frustrating, and it doesn’t appear to support broadcasting from multiple Twitter accounts a la Hootsuite. It’s just a simple addition to the system that is nice to see, if only to know that some thought is being given to how content in dotCMS is being spread, and how that may be facilitated as time goes on. There’s a lot of room for improvement and expansion on something like this: additional services (Facebook, Tumblr, LinkedIn, Google+, etc), using it on other elements (for instance, why isn’t this on pages in Edit Mode?), and maybe even serve as a way of getting some lightweight social analytics for the item you’re looking at (click tracking, RTs, etc).

So there you have it, ten things in dotCMS 2.0 that will likely make a few waves. Keep track of JIRA and now the Github issue tracker page for all the details regarding changes in the system, because there’s still a lot more that I haven’t talked about. Also, if you’re upgrading, make sure to take some time testing before launching live, as several of these new features will involve a lot of changes on the data model side of things. Plus, now that it’s on Github, be sure to take some time to contribute pull requests for things that you might be able to fix or improve. I think overall that’s a good move for them, as it exposes the platform to the overall open source community in a new way that SVN simply wasn’t capable of.

One Response to “10 Things To See in dotCMS 2.0”

  1. Will Ezell says:

    Great article! There is 1 biggie baked into 2.0 that did not get mentioned here and was really the original crux of the 2.0 release. I am talking about the underlying data model changes. In dotCMS < 2.0 all page, folder, content and asset relations were stored in a single table called the "tree" table. This table could get huge, had no referential integrity and made asset lookups slow and unreliable (help, my page disappeared!). In the 2.0 series, an asset's path is stored in the identifier table, and has referential integrity to parent paths and is just generally more robust. This is a big, albeit under the covers, change to how dotCMS stores content and data and will really help dotCMS scale into huge data sets.

    Another item of interest in the Workflow piece – the ability for a developer to create actionlets, or little pieces of functionality or integration that can be fired from the UI when the user performs an action. The twitter piece is an example of an actionlet but as a developer, the integration opportunities are really endless. You will see many new features manifest themselves as actionlets.

    Thank you so much for your support of our system – believe it or not, we are already 3/4 done with 2.5 with help from our great partner, ENG.it. 2.5 will have things like:

    – Dynamically loaded actionlets and viewtools with no restart, using OSGi. Just upload and "activate"
    – 508 compliance checking
    – Link checking
    – Visual Template designer
    – Revamped Elastic Search based Site search
    – Static Site Publishing


Leave a Reply