SuperSatellite

dotCMS 1.9 Upgrade Preview

// October 23rd, 2009 // 7 Comments » // Software, Tech, Web

The upcoming dotCMS 1.9 update is still at least about a couple months away from release (give or take), but the current SVN trunk code is already starting to shape up with a lot of the upcoming enhancements.  After testing out some of the new code, I thought it’d be worthwhile to share some screenshots and descriptions of what to expect, because it’s not a little change by any means.  The current release of dotCMS is 1.7a, with a 1.7b maintenance patch currently on the roadmap sometime soon.  1.8 is not being skipped, but instead, because of the number of changes that were slated for 1.8 and how they tied to 1.9, they’ve just rolled the whole series of updates into one big 1.9 upgrade rather than have two important updates come close together.  1.9 is likely to be the final big update before 2.0 (at least according to JIRA currently).  So, the future currently looks like 1.7a -> 1.7b -> 1.9 -> 2.0.

If you want to try out what I’m describing below, the code is available in SVN (linked above, username and password both dotCMSUser).  I recommend using it with a PostgreSQL database, as that’s what they develop on, and other databases might not be fully tested yet.  I want to serve up an initial warning too, that this code is absolutely not ready for a live environment.  I don’t mean that from a casual, you might hit an esoteric bug here and there way – I mean it in a you can’t run a web site on this code yet way.  There are a number of features coming that I couldn’t preview yet (like binary content fields in structures and some permissions options), because they flat out aren’t working yet.  I hit a number of areas with those kinds of problems, so keep that in mind if you want to try it out; still very alpha and still very under construction.  But, it doesn’t hurt to familiarize yourself with upcoming changes, since if you’re like me and running a huge site in it, it can be helpful for planning your upgrade path.

One of the big, less visible changes was moving to the Dojo framework for all the Javascript stuff done in the back end.  This is readily visible when you go to log in, as the login block is now a modal window, and you get a nice login progress bar as the back end loads.  This is just shouting for the addition of Google Gears support (a  la Wordpress. I actually started work trying to build in Gears to an earlier release, but had trouble with the amount of Javascript used in the back end).  Even lacking Gears, the back end is noticeably faster and more responsive to the user.  This may have other repercussions if you’re a heavy Scriptaculous user, but I don’t know yet, so just be aware that they are moving on to a different framework for the future.  But more to the point…

…holy crap it’s different!  Indeed, the whole admin interface has been redesigned and also made i18n compliant (that should make you international folks really happy).  This is similar to the change that took place when the page preview area was redesigned for 1.6.5.  Navigation wise, everything is still very much the same, so you don’t have to anticipate relearning everything luckily.  Basically it’s just got a new skin over the top to make everything look nicer and navigate better.  But, if you have a lot of lower level users, you’ll certainly want to brace them for the change, since just looking different might confuse them, even if stuff is relatively in the same place.

The content search page is a good example of the updated look, but it’s still very much familiar when compared to the old layout.  Same search boxes, same basic results table.  Some things like the “Show Query” button have moved to a more useful location.

So,  you can add content the same old way, and the familiar TinyMCE interface is there.  But gone are the Text and WYSIWYG tabs at the bottom edge of the field, replaced by a WYSIWYG toggle button.  Click it.  Do it.  I DARE you.  Yes, that is just what you think it is, the old, plain “text” mode has been updated to include a syntax highlighter and line numbers.  I think I’m crying right now, I’m so happy.  This definitely ramps up the usefulness of the text editor several degrees, and will make editing VTL files so much nicer.  Hopefully this is implemented everywhere you have code editing fields.

One of the most substantial changes was to the permissions system.  Gone are groups.  Instead, roles now control everything, and they are hierarchical.  The role manager has been completely updated to reflect the changes, and allows you to list users by role (yes!).  You’ll also see improvements to how permissions work related to different parts of the system.  The 3 factor (view/modify/publish) permissions have been dropped in favor of task specific permissions, and also user specific permissions as well.  One thing that I’ll be interested to see is how the upgrade process handles converting groups into roles and maintaining things coming from 1.7a sites, especially large, complex ones.  I envision this being an opportunity though to redo permissions in a much more efficient way.  It’ll be a lot of work I expect, but well worth it.  Be sure you keep this change in mind when upgrading, since it will have probably the most profound and widespread impacts to how you work in the CMS (Content Management System).

One of the other big changes is the addition of a form manager.  Instead of the complicated, inflexible form submission process used currently, a new structure type has been added that combines with front end content submission.  That makes three different structure types (content, widgets, forms) to choose from now, and greatly enhances the collection of data from users to repurpose elsewhere.  Now you also can leverage all the power of structures for data collection.  Like permissions, converting to the new system will involve a lot of work, especially if you have a lot of forms, but it will likely be well worth it, since it makes nearly every process of form use easier and more powerful.

That’s your initial look at the system.  I’ll do a more thorough review once the code gets closer to a beta release and is more functional.  For now though, I think it’s clear that this coming update is one of the biggest, if not the biggest update that we’ve seen for dotCMS to date.

dotCMS Cheat Sheet Released

// September 16th, 2009 // 4 Comments » // Software, Web

Hey everyone.  Just a quick hello to let you know that I’ve put some work into releasing a dotCMS Cheat Sheet for everyone to print off and use as a quick reference for a lot of basic tasks and variables.  This is up to date with the latest 1.7a open source release.  I hope to do a more advanced cheat sheet later to follow up this one.

If you like the cheat sheet and want to say thanks, please consider buying me something from my Amazon Wishlist or making a donation via PayPal below. Thank you very much those of you who have been supporting the effort I put in to dotCMS!

Download v1.0 of the sheet here

Follow me on Twitter for more updates! Also feel free to leave comments and suggestions for modifications to the sheet. I’m already working on revisions to the current sheet, and a more advanced sheet.

Running Multiple Blogs in dotCMS

// August 5th, 2009 // 4 Comments » // Software, Tech, Web

Earlier today, a question was raised on Twitter about how one handles multiple blogs using dotCMS.  Out of the box, dotCMS comes with a rather decent blogging system.  And with some tweaking, that decent system can pretty much kick the ass of anything Wordpress driven any day of the week.  That’s so long as you’re only running ONE blog.  When you get into a position where you want to run more than one, things can get icky real fast.  I want to share some of the reasons why, and what you can do to help solve the issues.

First, if you’re going to run multiple blogs, basically commit to abandoning most everything built in.  The Starter Site blog is single purpose, and won’t scale how you want.  This is sort of like the calendar that’s built into dotCMS.  Good calendar, but you discover if you run 12 domains out of one dotCMS instance, they’re all tied to the single calendar.  That’s a little rough.  Once you’ve realized that issue, then you get to learn the other two reasons why multiuser blogs are hard: permissions and relationships. dotCMS currently lacks true user level permissions, so every blog you make will have to have a role associated to it (more on this later), and relationships are just too hard.

Let me start with relationships.  Don’t use them.  Period.  It seems at face value to be the logical choice – make a blog structure, and relate posts to a blog.  The problem is that while the instinct to use them makes sense, and they’re powerful and great tools for someone writing complex apps in dotCMS, the average grade blog user has no clue why they have to set them up, especially when they only use one blog.  Ideally, dotCMS itself should handle it like this: If a structure requires a relationship, and via permission restrictions a user only has one piece of content to relate it to, it should just force that relationship by default (I suspect using the pre-content hook you could write a plugin to do that, but I don’t think it’d be easy).  But it doesn’t, so users just get hit with a needless extra layer of work to get a blog post out.  And besides, it’s just not needed for this.  Leave relationships for more programatically useful tasks.

The solution to the relationship issue is categories.  This is actually the crux of the entire multiuser issue.  Categories are where you can segment blogs, and control their display.  Like I mentioned, you’re going to have to create a role for each blog anyway.  No way around it.  The benefit of that is that you can run all the blog entries from one structure, and by controlling user access to categories, you control the blogs they post to.  Each blog/role gets a category, like:

Blogs
  + My First Blog
    + Category 1
    + Category 2
  + Someone Else's Blog
    + Category 3
    + Category 87

Someone permissioned on “My First Blog” wouldn’t even see “Someone Else’s Blog” under the blog entry categories, and like magic, you’ve now segmented everything (additional advantage, one person could have roles for several blogs, and post to them all at the same time.  This goes further and is true really for any kind of content that you need to do “access control” on.  If you can tie it with category permissions, it’s a great, simple way to have several people working in one structure without getting into each other’s stuff).  Now, when you build out the blog page, you build based on parent categories, rather than relationships.  Combine all this with a login protected page on the front end using the Front End Content Submission plugin, and users never even need to log in to /c.

My suggestion is two structures, a blog entry content structure (which comes with the starter site, so you could just modify it), and a blog page widget structure.  The widget would let you turn any page into a blog, by covering all the listing and displaying functionality, and allow you to define the category it should pull, and all that extra bloggy stuff.  In ours, you can add Feedburner links, decide to show excerpts or full posts, control global commenting and rating settings, and even upload custom CSS (Cascading Style Sheets) files.  If you have two dozen templates, the widget route would let you turn any of those templates into a blog.  Here’s an example setup.

The smart thing to do in the widget code for the actual blog widget would be to just have it dotParse() an appropriate .vtl file for single view or an archive view (normal, date, category, etc).  You could break that down as far as you’d want, but that’d keep the code segments less in the widget, and more in actual files.

Another area that dotCMS hurts in right out of the gates is commenting.  The commenting system itself works, but the design is just bad.  The markup isn’t good, and the layout is ugly.  Luckily for you, you can override that.  If you look at the code that drives the Comment macro, you’ll see that it calls in a template file from the file system.  Also, if you look at that code, you’ll notice there’s a variable you can set that isn’t mentioned in the documentation: $commentSourceCode.  This lets you control how your comments are marked up, which is a major deal.  You can actually go in, copy that source file, edit it to meet your needs, and add some good semantic markup to both the form and the comments – making them both easier to manipulate and style.  You could even integrate Gravatar support with the help of some Javascript MD5 code.  Here’s an example of some massaged comments:

The form there is easier to read and use, and the comments look nicer and are easier to change with better XHTML markup.  You can even go further into the HTML to do threaded commenting, just like in Wordpress.  Combine that with some jQuery, and you can get real fancy.  Alternative, you could just go outside with a commenting system like Disqus if you want more functionality, which you can embed in your blog post view template.  There’s one gotcha to commenting I haven’t solved yet (at least, not without editing some field data in the database).  If you delete comments, the comment count doesn’t change.  So if you got 6 spam comments on a blog and deleted them all, the blog still says it has 6.  The field the count is stored in isn’t user editable (as mentioned, you could change this in the database itself), and there’s no hook to subtract from it when comments are deleted.  A workaround would be to count the size of the actual list from the comment relationship pull rather than trusting that field.

Everything’s not all roses and puppies and sunshine though.  The way I do things, it scales better, but not great.  This isn’t bad for a couple dozen blogs, but I still wouldn’t do it for hundreds until there’s a better way to attach permissions at the user level, and automate it.  The major limit is that role issue, and I’m happy to entertain ideas as to how to get around it (ultimately, it could be done with a CMS (Content Management System) Owner role, which is in the system now, but not quite used “right” enough for this purpose).  You could make pretty much make everything 100% dynamic, and from an infrastructure point of view, it’d just scale and scale and scale, so long as you’re willing to make a role manually each and every time.

Additionally, there’s no easy route into creating categories for the user.  You can give them access in the back end to add their own, but it’s not as easy as in other systems.  That’s not really a fault in dotCMS, since categories can do so much in the system, they just need to be in their own portlet.  So, you either end up manually maintaining categories for them, forcing everyone to use a common set, or hope they’re savvy enough to use the category manager (keep in mind, if they have to log in to /c to edit categories and whatnot, it sort of kills the reason to do a front end page mentioned above). Your environment will pretty much entirely dictate your approach, so this could be a non-issue for you, or maybe not.

I’ll present our web office blog at PSU as an example of this sort of system in use, and then a test blog, using the same system in a different place.  Different paths, different categories and RSS feeds, but using the same system.  I’m also working with another client on a very similar implementation, but with some differences, such as how the actual blog pages are built out (for about 2 dozen blogs).  Naturally, pulling this off takes a little time, and you’re going to need to be comfortable working with Velocity to pull it off, but I’ll tell you, in one page of Velocity I can duplicate almost all the core Wordpress display functionality (single, archive, category, tag, and author views), and have most of it done in under a day.

I’ll close by saying that if anyone has the skill and time to tackle the idea of doing a multiuser blog portlet plugin for the back end, I know it’d be well received in the community.  This could help get around every single deficiency that exists now, though I think within the next two releases, we’ll see some of the modifications needed to really implement this well natively inside dotCMS.

Two dotCMS Plugins Released

// March 11th, 2009 // 5 Comments » // Software, Web

With the plugin architecture in dotCMS launched with the release of the version 1.7 release candidates, several of us are getting started testing out the water.  To get things started, I’ve released two plugins this week you can download and install.  Nothing huge, but hopefully helpful to some folks.

XMLTool Plugin

Example of the reCAPTCHA

The XMLTool plugin creates a view tool that gives you access to the Apache XMLTool class so that you can import and parse XML data into an HTML page.  This allows behavior similar to XSLT (eXtensible Stylesheet Language Transformation), so that you can manipulate and transform the data in an XML document into XHTML.  All you have to do is drop it in and deploy it to get access.  Full details, download, and an example can be found in the forums.

reCAPTCHA Form Verification Plugin

The second plugin is integration of the reCAPTCHA API (Application Program Interface) into the form handler so that if you don’t like the built in captcha generator, or prefer reCAPTCHA’s, you can use it with this.  It creates a new Struts action and macro, combined with a modified version of the submitWebFormAction class.  As with the XMLTool, download, example, etc at the forums.  This takes just a couple changes to a form to use: you need to point the form action to /dotCMS/submitFormRecaptcha and drop the recaptcha() macro somewhere inside the <form> tag.  Additional documentation is in Macro Help after you deploy it.

If you’re using dotCMS, give the plugins a download and try, and let me know what you think.  Also let me know if you have problems.  I am aware that the XMLTool complains about its scope at startup.  It will run normally though, but I am trying to see what’s up with the scope to correct that warning.

dotCMS Plugin Joyfulness

// February 6th, 2009 // 2 Comments » // Software, Tech, Web

After some trouble fighting wih OpenJDK vs the Sun JDK, I’m ready to get my brain soaked with information on the upcoming plugin architecture in the 1.6.5c patch here at dotCMS Boot Camp.  Note on the previous comment: don’t use Open JDK, save yourself some trouble.  If you are interested in plugin development, be sure you’ve taken some time to familiarize yourself with Eclipse, and obviously you need to be familiar with coding in Java.  Plugins in dotCMS finally allow customization of the codebase without having to go in and edit core files for your system.  This will help make updates in the future substantially easier, as the core engine never has to be changed.  This is the same model most other open source systems use (think Wordpress, Joomla, Drupal, etc).  These other systems can be extended through plugins without ever doing anything to the system itself, so when you update, you don’t have to worry about needing to merge hundreds of lines of different code.

If you want to get started until the C patch is out, just grab the codebase from the testing branch on SVN.  Also, if you use Ant in Linux, make sure you get the ant-optional package as well.  The Ant tasks are smart with the new setup, allowing you to completely override default actions in the system, like if you want to create your own form action that uses /dotCMS/submitWebForm, the process of building out the plugin will override the default actions in that Struts path.  If you want information on all the Ant tasks available within dotCMS, just run ant -p.

So, what can you extend with the plugins? Plan on being able to mess with macros, Struts actions, viewtools, language files, web.xml, Hibernate, and property files.  Create tables, add fields to structures, and allow for plugin version checking.  Basically all in all, a tool that’s gonna see a ton of use.  You’ll also be able to tie into hooks for content.  Right now that’s the only one, but more will be added as needed.  Something else that will be very useful is deploying all your server settings as a plugin, instead of changing config files and having to update the settings every time you do an upgrade.  Or, if you were moving servers, or going from a test to a live server, you can just lift the settings plugin you create and drop it right where you need it.

Plugin functionality can be downloaded over SVN from https://svn.dotcms.org/branches/releases/1.6.5 if you want to get in and start playing with it.

AJAX (Asynchronous Javascript And XML).  There was a session on using AJAX with dotCMS involving DWR and EXTjs.  Really, the most important thing I came away with is that I’m not doing AJAX that way.  It’s simply too involved and I don’t personally have the time for it.  But that’s just my opinion.  Chris Falzone of Edinboro had a pretty simple solution involving jQuery tied to a page that just processed queries with the SQL macro.  That is a pretty painless, and easy method of essentially accomplishing the same functionality, and do so with far less JavaScript.

Okay, everything gets rounded out today with a talk on the future plans for dotCMS.   Some of the 2008 milestones: 1.6.0 and 1.6.5, the calendar, widgets, eCommerce, low level optimizations, simplified install, starter site, and the documentation site.  For 2009, some of the goals are: release of enterprise vs. open source branches, plugins, and release 1.7 (which will debut the plugin architecture and officially fork the enterprise and OS branches) and 1.8 (another note, dotMarketing is aiming on 2-3 version updates a year, with 6 months being the longest they plan on having between releases). 1.8 will introduce binary content for structures, improve functionality of the owner field, automatic content saving/drafting (in case your computer crashes in the middle of editing, etc).  Another goal: permission simplification.  It will, of course, retain the power and granularity, but adds in the power to group edit and improve the UI for working with them.  Look for improvements to multi-site hosting, mostly in terms of UI for people who might be hosting hundreds of sites in one instance of dotCMS.  They are working on push publishing, which will add the ability to send rendered pages off to other servers, as well as do things like clone one dotCMS server to another.  There are plans for several improvements to forms: new handling options, action chaining, etc.  Expect improvements to web services to extend the system.