Posts tagged "cms"

60cycleCMS 2.5.0 released!

Wednesday, December 2, 2009

At long last I've found some time to work on 60cycleCMS, and version 2.5.0 is the result. A major change in 2.5.0 is the addition of a new visitor comment system. I've integrated RECAPTCHA and HTML Purifier to thwart spammers and XSS, respectively. I've also allowed for email notifications of new comments. Of course, the comment system is both optional and configurable, meaning you can enable or disable it and its features at will.

As always, you can see the latest version in action on this very website. I've also notified the admins at opensourceCMS, and hopefully a demo of the new version will be available soon.

Download the new version from the project page or SourceForge.

1024 CMS News


Upgrading:

New update will be released February 9th 2010.
Please note upgrade for version 2.0.0 will not be available new upadte will only be for version v2.0.1.

New version will be V2.1.1

Removing the Joomla Generator Tag

A common request from Joomla web masters is the ability to remove the generator meta tag from the source output of the site.  This is usually for security reasons to make it less obvious that the site is running Joomla.  The generator value is really easy to modify and remove with one line of PHP code.

Fire up your favourite editor and load the index.php file of the default template on your site.  Most templates should have a block of PHP at the top of the file starting with and closing with ?>.  Find this block and just before the closing PHP brace, insert the following lines of code:

// Remove the generator meta tag
$this->setGenerator(null);
?>

What we have done here is told the template (that's what $this is) to set the value of the meta generator tag (that's what setGenerator does) to nothing (that's what null means).  When you do this, refresh your web page and view the source of the output.  Scan down from the top of the file to find the meta generator tag.

  <meta name="generator" content="" />

You can see it's obviously still there but the value is empty, giving you no clues as to what CMS is running the web site.  Nothing is probably the safest value, but you could set it to anything you like if you really wanted to.

There are several other files that could be loaded by Joomla in the template.  You will also need to do this to the component.php (that supports the Joomla Print View) and if you have a custom Error or Offline page, you will need to add the line of code to error.php and offline.php respectively.  You can find out more about these additional template files in the Template section of the Art of Joomla Developer Reference.

This is just another example of how flexible the Joomla templating engine is and why it's a makes Joomla a great choice to power your web site ... anonymously.

Joomla's hidden feature - hiding Intro Text

Joomla Web sites typically use the "Intro Text" and the "Read more button" and just continue the story from the Frontpage Blog view, or a Newsflash module - but it doesn't have to be that way.  You can actually hide the Intro Text when displaying the full article.

To do this, edit the article in the Joomla Administrator.

Click on the "Parameters (Advanced)" pane to the right of the text of the article.

Find the parameter called "Intro Text" and change the select list to "Hide".  Your article might look something like the following screenshot (click it to enlarge):

Screenshot

(You will note that I've fixed up some of the typo's since I took this shot.)

Save the article.

Now have a look at the article as it appears in a blog view, or a module, and then look at the full article.

The effects can be dramatic, such as in this article, or they could be more subtle.  You could make small adjustments such as you might see at spacedaily.com (this is not a Joomla site, but it's a site that inspired many of the early features I built into Mambo, the project from which Joomla was born) where the introduction on the frontpage changes slightly and the image includes a caption in the full article.

I hope you enjoy this useful, yet overlooked, feature of Joomla - hiding Intro Text.

Joomla Caching Explained

Any dynamic content management system makes the web server work and Joomla is no exception. However, most Web sites have content that does not change frequently where caching techniques can be employed to reduce reinventing the wheel (or the content as it may be) each time a page is visited. This article looks at the three levels of caching available to a Joomla 1.5 web site.

The idea behind caching is that once you’ve gone to the trouble of running a component, a module, or even building a whole page, it makes sense to take a copy and reuse that if possible. By default, Joomla does not cache any content. This means that every time someone visits your page, all the computations that it took to build the page are done over and over again even it there is actually no change in what the visitor sees. To overcome this, Joomla provides three levels of caching:

  1. Page caching
  2. View caching
  3. Module caching

Page Caching

Page caching is where Joomla takes a copy of the whole page when it is first displayed. If that page is then visited again, it takes that copy it saved and just displays the output, bypassing much of the code and many of the database queries that were required to build it.

Page caching is supported by the System Cache Plugin that comes with Joomla. To enable this, log into the Joomla Administator and choose Extensions -> Plugin Manager from the menu. Change the type filter to "system" so that the plugin is easier to find (or just search for "cache" in the filter box).

Screenshot

Click the icon in the enabled column to activate the plugin.

If you edit the System Cache plugin you will see that it has two options:

Screenshot

Use browser caching

The help text for this is a bit cryptic:

"If yes, use mechanism for storing page cache in the browser”

What this actually means is if you enable this option, Joomla will send a "304 Not Modiifed" header to the browser if the page has previously been cached. This will tell your browser that the page has not changed since you last saw it and saves another request to the server to actually get the contents of the page (assuming the browser stored a local copy). This is really only needed if visitors would return to pages while browsing your site. In this case, when they go back to a page they have previously visited, it can make the site feel a little more responsive. If your site visitors generally do not visit any page more than once during their browsing session, this option is of no real advantage.

Cache Lifetime

This is the time, in minutes, to store a copy of the page before a full refresh is done. The choice of time depends on how frequently content is updated. If you have news coming out every few minutes, then you will want to keep this setting low, even as low as one minute. If you only update your content once a day, then several hours may be appropriate. When adjusting the cache time, you need to consider dynamic modules and the content they display. While you may only update your content once a day, or even once a week, you you have a comments system linked to a "Latest Comments" module, and those comments are made, on average, once every 10 minutes, then you may need to set your cache time as low as 3 to 5 minutes so those changes are reflected in a timely fashion.

Page Caching Performance Testing

The following results are from testing a Joomla 1.5.14 site on a local development laptop (Macbook Pro 2.1.6 GHz Core Duo with 2 Gb of ram, PHP 5.2.6, MySQL 5.0.41).  The results where complied by turning on the System Debug plugin (and a little hacking to make the results show under cache due to a bug in the plugin).

SEF Off, System Cache Plugin Off

Application afterLoad:       0.000 seconds, 0.24 MB
Application afterInitialise: 0.072 seconds, 3.72 MB
Application afterRoute: 0.114 seconds, 5.46 MB
Application afterDispatch: 0.165 seconds, 6.86 MB
Application afterRender: 0.667 seconds, 7.98 MB

SEF Off, System Cache Plugin On

Application afterLoad:       0.000 seconds, 0.24 MB
Application afterInitialise: 0.077 seconds, 3.79 MB
Application afterCache: 0.080 seconds, 3.97 MB

The improvement is significant where caching delivers the same content about eight (8) times faster and uses half the memory.  This effectively constitutes a no-load test (in other words, ideal conditions) so it demonstrates the best possible performance you can get from turning caching on.  You will generally not see the same magnitude on a production server and probably even less in a shared hosting environment but the effect should still be noticable (although, if your pages are module heavy, you might see a greater increase).

Things to Watch When Using Page Caching

There are a number of things that you should watch when using the page caching plugin.  These include:

  • It does not apply to the Administrator.
  • It only applies to guest visitors (not logged in).
  • It does not apply to posted forms (which is a good thing).
  • It replaces security token with the correct value if required (another good thing).
  • It adds a profiling mark called afterCache (but due to a bug, you will never see it).
  • It stores a copy of the whole page after it is rendered based on the URL, so it will work for any unique URL regardless of the component.
  • Articles hits will not increase when page caching is turned on (making any sorting options on hits ineffective).
  • Javascript based dynamic content, such as Google Analytics or Google Adsense, still work.
  • Page caching does not work if Debug Site in Global Configuration is set to Yes.

The cached pages are stored in the /cache/page/ folder.  If your have a very large site on shared hosting you may need to watch your disk quota.

Clearing the Page Cache

Sometimes you need to clear the page cache so that you can see recent changes you have made to the site.  To clear the page cache, select Tools -> Clean Cache from the Administator menu.  Check the box next to the Cache Group called "page" and then click Delete in the toolbar.

View and Module Caching

View and module caching is different to page caching because it only stores copies of parts of the page.  Joomla still analyses and renders the template but you receive a performance boost because parts of the page can be retrieved very quickly.

View and Module caching is controlled by the Cache Setting section under the System tab in Global Configuration.

Screenshot

This allows you to enable caching and set the cache time (in minutes) and the handler (usually just file unless you have some fancy software installed on your server).

View Caching

View caching is only supported in components that enable it within their MVC architecture.  The only component that enables it in the Joomla 1.5 stack is the Articles component but only for guests (visitors that are not logged in) and only if you are not looking at a Category Blog page (the reason why this view is singled out escapes me).  Several JXtended extensions also support view caching.

View caching captures a copy of the output of the component before it is handed off to the template for rendering.  This can be useful if the amount of work to generate a page is processor intensive (that is, it makes the web server work hard).

Like page caching, the view caching is linked to the URL.

Module Caching

All modules (should) have a Caching option, usually in the Advanced Parameters pane and (should) have a Cache Time option which is the time, in minutes, to keep the copy of the module output.  The Caching option allows you to either Use Global, in which case use the setting in Global Configuration, or No Caching.  This means that you have three combinations to work with on your site:

1. Global configuration Caching is Off, so no modules cache their output.
2. Global configuration Caching is On, so all modules using Use Global will be cached.
3. Global configuration Caching is On but modules can individually opt out of caching by selecting No Caching.

It is important to note that this caching setting is different from the caching that the System Cache plugin does.  Actually, they are completely unrelated except that the Cache Plugin takes precedence.  In other words, when the System Cache plugin is page caching, a copy of the whole page, including the modules, is stored.  When the page is pulled out of cache, there is no processing to check whether any modules were set the No Caching.

There are several modules where you should choose the No Caching option.

The menu module generally should not be cached unless it is set not to expand (in other words, it stays open all the time).  Depending on how they are set up, split menu modules should not be cached.  If you do cache an expanding or split menu, it is going to get stuck and confuse your visitor.

Rotating content modules, such as the banners module, should not be cached.  If they are cached, then they will stay on the same content until the cache expires.  One exception is advertising modules that use javascript to display the content (such as Google Adsense).  This is not affected by caching.

The Polls module should not be cached otheriwise you risk getting an "Invalid Token" message when someone votes.

Highly dynamic content modules should either use No Caching or set a very low value for the Cache Time (one or several minutes).

Module caching will work regardless of whether the visitor is a guest or logged in.

Notes for Module Developers

Module developers need to be aware that module caching is handled by the module renderer in the JDocumentRendererModule class.  If the cache parameter is not provided, the module will never be cached regardless of the setting in Global Configuration.  To allow a module to be cached, you must include the following parameter in the module's XML file:

        
            name="cache"
            type="list"
            default="1"
            label="Caching"
            description="Select whether to cache the content of this module">
           
                value="1">Use global
           
                value="0">No caching
       
Introducing the new permissions in Joomla 1.6

Joomla 1.6 already demonstrates the ability to add your own user groups and access levels.  Mark Dexter has done a very good tutorial on this at http://docs.joomla.org/ACL_Tutorial_for_Joomla_1.6 which shows some of the supporting user interface under development.  Thanks also go to Mark for developing the design of the inheritance diagrams that you will see in this article.

This article presents the theory behind how the completed permissions management system, a part of the Joomla access control system, will work in Joomla as it currently stands to for Version 1.6 Alpha 2.  Screenshots of the user interface that allow you to set permissions will follow in other articles when the design of the appropriate pages becomes more stable.  This article also includes material presented by Andrew Eddie during his keynote address to the Sydney Joomla Day in October 2009.

Four Levels of Permissions Management

There are four levels of permissions management in Joomla 1.6 and these are set against the user groups defined in the User Manager.  Permissions can be set:

  1. in Global Configuration,
  2. then in each component,
  3. then in each category, and
  4. then in each article.

Each level allows you to choose more granularity for which to set the permissions.  For example, permissions set in Global Configuration will apply to the site as a whole without any additional work.  At the other end of the scale, you can customise the permissions of each article if that level of detail suits your business processes.  Obviously there is a trade-off.  As you apply specific permissions at deeper layers, the administration increases because you are micro-managing permissions on more and more objects.

Actions and Permission Rules

There are eight base actions that you can perform in Joomla 1.6.  These are:

  1. Login Site
  2. Login Admin
  3. Manage
  4. Admin
  5. Create
  6. Delete
  7. Edit
  8. Edit state

A component developer can add more, but most things that you want to restrict a user to do (based on the user groups they reside in) can be mapped to those eight actions.  However, each level of the permissions management system unlocks different abilities for each of the actions (sounds a bit like a computer game, doesn't it)

The rules for the permissions on these actions are quite easy because there are only three possible values as follows:

  1. You can leave a permission unset (in the case of Global Configuration), or you can set it to inherit the permissions from the levels above.
  2. You can set a permission to allow an action to be performed.
  3. You can set a permission to deny an action from being performed.

With that in mind, there are four simple rules by which Joomla evaluates whether you can perform an action.

  1. By default, you can't do anything.  We call this an implicit or soft deny.
  2. You can allow an action, and we call this an explicit or hard allow.
  3. You can deny an action, and we call this an explicit or hard deny.
  4. An explicit or hard deny always wins regardless of whether a soft or hard allow is also available.

There is one exception to these rules concerning the Admin action which will be discussed later.

Permission Inheritance

Permissions are always inherited, in order, down the levels and also down the user group tree.  For this reason, the user groups have been rearranged slightly in Joomla 1.6.

Screenshot

The Public Frontend and Public Backend groups have been merged together to form a single, top-level group.  Both the frontend and backend user group trees hang off the Public group.

The Super Administrator group is now called Super Users (to reduce confusion with the Adminstrator group).

With those things in mind, it's best to look at this with some diagrams that explain each action individually.  In each diagram as a number of symbols that represent the state of the permission that has been set for the action relative to both the user group and the permission level.  The following table explains the meaning of each symbol:

Screenshot An unset permission (which really means deny).
Screenshot An explicit, or hard, allow.
Screenshot An explicit, or hard, deny.
Screenshot An inherited allow.
Screenshot An inherited deny.

 

The Login Site Action

The Login Site action simply allows you to login to the frontend of the web site.  It has no effect at the component, category or article level (symbols shown dashed).

Screenshot

The Registered user group is set to Allow and, as you can see, this inherits down the tree through to the Publisher group.  Likewise, the backend groups are also given Login Site through the Manager group (set to Allow) and this inherits down the backend groups tree to the Super User group.

The Login Admin Action

The Login Site action simply allows you to login to the backend of the web site.  It has no effect at the component, category or article level (symbols shown dashed).

Screenshot

The Manager user group is set to Allow and, as you can see, this inherits down the tree through to the Super User group.

The Admin Action

Admin is a very special action.  When set at the Global Configuration level, it allows users in that group to perform any action regardless of any other allow or deny permissions (this is the one exception to the rule).  The default installation of Joomla will assign this permission to the Super Users group.

At the Component level, the Admin permission allows a user to change the component options (these are accessed via the Toolbar button called Preferences or Parameters in Joomla 1.5) which also includes the ability to change the component permissions.

Screenshot

Because the component options allow you to change the component permissions, you need to be careful how this is assigned.  The diagram above shows that in Global Configuration we have not assigned Admin to any user groups.  This is because that would also make an Adminstrator into a super user (and then they would be able to do anything).  However, in each component we have set Allow for the Administrator Group.  This means that users in the Administrator group are able change component options, but users in the Manager group will not because we have left the action unset.  In fact, users in the Manager group will not even see the Toolbar button for the options.

One thing to note is that if you install a new component (represented by the "New" component in the diagram) the Administrator group will not automatically have the Admin action.  Providing the component supports options and permissions, you will need to go into the component options and manually add the Admin action to the Administrator group.  In summary, this means that only your Super Users are allowed to assign who else can have access to change permissions.

The Admin permission has no effect at the Category or Article level.

The Manager Action

At the Global Configuration level, the Manage action has no effect (but can still be set).

At the Component level, the Manage action allows the user group to actually access the repsective component.

Screenshot

The diagram above shows that at the Global Configuration level we have set Allow for the Administrator group.  Unlike the Admin action, setting the Manage action globally means that any user in the Administator group can access any component, even new ones that are installed by the site master.

At the component level we can see that the Administrator group inherits Allow for all components.  However, Manager group has allow set individually for each component.  You can see that users in the Manager group will not have access to extension installation or languages because the action has not been set (therefore the implicit deny rule applies).

The Manage action has no effect at the Category and Articles levels.

The Create Action

The Create action allows a user to create categories and content in categories in components.

Screenshot

The diagrams shows that only the Manager groups has set this action to Allow in Global Configuration and the Author group has been set to Allow at the component level (specifically, only in the Article Manager and Web Links Manager).  The Administator, Editor and Publisher groups also inherit the Allow setting at their respective levels.  This means that a users in the backend user groups are able to create content in any component and any category, and also create categories.  Users in the author, editor and publisher group are able to create articles in any category from the frontend.

The Create action obviously does not apply for articles (because if they exist, you've already created them).

The Delete Action

The Delete action allows a user to delete categories and content in categories in components.

Screenshot

The diagrams shows that only the Manager group has been set to Allow.  The Administrator group also inherit the Allow setting.  This means that only users in the Manager and Administrator groups can delete categories and content in any category in any component.

The Edit Action

The Edit action allows a user to modify categories and content in categories in components.

Screenshot

The diagrams shows that the Manager group has been set to Allow in Global Configuration.  The Editor group has also been set to Allow but only at the Component level (specifically in the Articles and Web Links components).

The Administrator group inherits the ability to edit categories and content from the Manager group at the Global Configuration level.

The Publisher group inherits the ability to edit categories and content from the Editor group at the Component level.

However, we have not set the Author group at the Component level.  This prevents a user in the Author group from editing any content or any categories (note that the ability for users in the Author group to edit their own content has not been implemented yet). 

The Edit State Action

The Edit State action allows a user to modify secondary information, such as the published state, of categories and content in categories in components.

Screenshot

The diagrams shows that only the Manager group has been set to Allow in Global Configuration.  The Publisher has also been set to Allow but only at the Component level (specifically in the Articles and Web Links components).

The Administrator group inherits the ability to edit categories and content from the Manager group at the Global Configuration level.

The Author and Editor group have not been set.  This prevents a user in the Author or Editor groups from changing the published state of categories and content in the respective component.

Conclusion

This article provides an introduction to interpretting the new permissions management system in Joomla 1.6.  The key points to remember are:

  1. Permissions inherit down the user group tree in order, and down the four levels in order.
  2. By default, a soft deny applies until you Allow an action but then an explicit, or hard, Deny completely prevents access to the action.

We'll look at the effects of adding users to multiple groups and placing permissions on specific categories in future articles.

OmniUpdate Reports Strong 2009 with CMS for Higher Education

Crisis, what crisis? Almost every Web CMS vendor who has to or chooses to publicize their 2009 financials is reporting growth and bright future. Some are even going public. OmniUpdate (site) joins this joyous bunch and says 2009 was a success in its higher education focused web content management segment.

Last year was marked for OU as a year of record sales revenues. Other 2009 highlights include:

  • 28 new clients
  • Existing customers increasing/renewing their service levels/terms
  • 12 product releases with 16 additional capabilities and feature enhancements (e.g. multi-language preview, global find and replace, garbage can, Serena Collage conversion tool, Live Delivery Platform and others)
  • Onboarding of integration partners
  • Ability to deploy OmniUpdate's CMS — OU Campus — either traditionally or as SaaS

As with all privately-held companies, the amount of financial information being released is limited. For buyers looking to evaluate Web CMS products for higher ed verticals, record sales is probably a little too ambiguous to indicate the overall viability and stability of the company.

While growing revenue is good news, we’ll continue to watch OmniUpdate and update you on where these folks are headed.

Nuxeo Adds SaaS Visual Developer Tools to Enterprise CMS

Open source Enterprise CMS and Document Management vendor Nuxeo ( site) is extending the value of its Nuxeo Connect support and maintenance service with a new product named Nuxeo Studio.

Nuxeo Connect: The Core Support Service

Nuxeo Connect is a subscription service delivered to Nuxeo's customers, providing maintenance and support for Nuxeo's Enterprise CMS software.

The Nuxeo Services Offering for Paying Customers

 

It includes such usuals as service level agreements, access to certified patches, configuration, monitoring and management tools, as well as product updates. Like most vendors, open source or not, Nuxeo offers premium 24/7 support levels as part of Nuxeo Connect.

Introducing Nuxeo Studio

Nuxeo Studio is a new configuration and customization environment for the Nuxeo open source Enterprise CMS. It is being made available as a part of the Nuxeo Connect subscription service. The company asserts that Studio is all about trimming the development time associated with implementing a Nuxeo-based document management application.

The new offering also clearly serves as an additional carrot, luring non-paying users of Nuxeo's open source software into the fold of paying customers. This game of carrots and sticks is one of the most important aspects of the commercial open source business model. Nuxeo uses a single repository model for managing their source code. So paying and non-paying customers all have access to the same source code. By offering ancillary tools via a subscription SaaS model,  commercial open source vendors can increase both the perceived and real value of their commercial support offerings.

Highlights of Nuxeo Studio

In essence, Nuxeo Studio is a web-based administrative tool for Nuxeo Enterprise Platform (Nuxeo EP) and packaged applications, such as Nuxeo Document Management (Nuxeo DM). It can be used for easier customizations of Nuxeo ECM and DM platforms without much developer involvement.

Current features of Nuxeo Studio include:

  • Content Model Definition
  • Content Views and Forms Design
  • Definition of Content Lifecycles
  • Search Form Design
  • Controlled Vocabulary Definition
  • Rapid Application Branding (logo, colors, etc.)
  • Rapid application prototyping

 

Nuxeo Studio — Content Type Presentation Design

 

The company has promised to continually improve and expand Nuxeo Studio and to work closely with the community when prioritizing new features. Items on the current roadmap include:

  • Graphical Workflow Design and Modeling
  • Business Rules Definition
  • Content Actions Definition
  • Application Version Management
  • Eclipse and Source Control Integration

You can participate in the software development process via the Nuxeo Studio bug tracker and/or the Nuxeo Studio support forum. Studio is available as part of the Connect Support package or on a per application basis. The per application pricing runs between US$ 5,000 and 15,000 depending on the number of authorized developers.

A Busy Start to 2010

Paris-based Nuxeo had a strong finish to 2009 and has so far had a good start to 2010. They recently added a Digital Asset Management product to their offering, they are benefiting from one of their partner's efforts, delivering an IBM-to-Nuxeo migration tool, and just a few days ago they released an updated version of their Apache Chemistry CMIS implementation.

Stay tuned here, the company's product roadmap is a busy place these days — additional promises for 2010 include a unified enterprise correspondence manager, a structured documentation server and work towards DoD 5015.2 records management capabilities.


Day CQ 5.3 Aims to Brighten the Days of Techies and Marketers Alike

Continuing to build up on the bright developments that we saw in CQ 5.1 and 5.2, Day Software (site) released the newest version of their Communiqué Web CMS/DAM/Social Collaboration product.

Day’s CTO David Nüscheler and CMO Kevin Cochrane gave us a tour of the top new features in CQ 5.3.

Day’s latest minor release includes more than 600 enhancements over CQ 5.2.0 code base. Changes start right from the welcome screen that now has descriptive buttons for both previously existed and new functionalities.

 

CQ 5.3 Welcome Screen

 

The UI is mostly unchanged from CQ 5.2 with the exception of some tweaks and additional columns.

CQ 5.3 Personalization, Segmentation and Targeting

CQ Targeting is a brand new module that allows marketers to create, manage and measure their online marketing efforts (campaigns, landing pages, etc.) and customer targeting and segmentation.

Day Software has built a segmentation engine that allows users to adjust segmentation rules by referral keywords or general surfing patterns.

 

CQ 5.3 Segmentation Editing

 

Developers can create specific custom traits to provide marketeers with more specific targeting. Those traits are managed using the Clickstream Cloud, which shows a specific user profile.

CQ 5.3 Clickstream Cloud

Navigation and click stream behaviors and patterns can be captured, measured and analyzed even for anonymous users to tune in targeting. All profile information that is captured is stored in the central repository.

Personalization is not easy to do well. Many Web CMS vendors have tried it in a variety of approaches. According to Day, they wanted to make personalization more dynamic and scalable with all the action happening on the client side vs. server side. Personalization comes as part of CQ Social Collaboration module.

Privacy concerns? Forget about it, privacy is more dead than ever. Day’s CQ 5.3 can capture external browser history and geo location. Just like the links you click on in a browser turn different color and your browser knows that next time they’re displayed, CQ 5.3 knows which website you came from and which websites you visited in the past. Knowing browser history and mouse cursor movement is possible thanks to the dynamic, client-side nature of Day’s personalization.

This approach also is more friendly to horizontal scalability, as there’s no need to add more hardware. Cherry on top is what Nüscheler calls “a completely revolutionary approach” to personalization caching. Personalization in combination with multivariate testing and voila: get the impressions, click-through rates, etc. and simulate the best performing version of your page.

One of the nice features in CQ 5.3 is built-in support for A/B and MVT for optimization of content, so that marketeers can not only attract visitors, get insights into their behaviors, but also get a higher chance of converting them.

 

CQ 5.3 MVT

 

 

The most interesting part, says Nüscheler, is the combination of segmentation and MVT, which allows marketeers to see results of which content would be attractive to different populations. As we mentioned above, many of these functionalities are possible due to all of that data being stored in the content repository (CRX) as opposed to disparate data sources.

Speaking of CRX, the CQ 5.3 release is already JCR 2.0/JSR-283 compliant; with CRX 2.1 release expected later this year.

Social Calendaring

Social calendaring is an improved feature that initially appeared under the CQ5 Social Collaboration umbrella. In CQ 5.3, you can promote events more effectively with the ability to subscribe or import events from a site to your calendar of choice.

CQ 5.3 Social Calendaring

 

 

The events you add to your calendar are stored in the content repository, thus allowing for bidirectional management of content (in personal and corporate, internal and external calendars) and synchronization of changes. The calendar component has been enhanced to include automatic RSS feeds and iCal event subscription.

CQ 5.3 DAM Updates

Adding some external coolness, Day went ahead and integrated with CoolIris to provide 3D visualization and fly-over navigation of digital asset libraries.

CQ 5.3 DAM with CoolIris Integration

Other new Digital Asset Management features include MediaRSS support, easier management of metadata, new lightbox for building pick lists of assets, and new drag-and-drop components for uploading, tagging, commenting, and rating assets in the spirit of user-generated content.

CQ 5.3 DAM

CRXDE Lite

And to the developers’ delight, Day introduced browser-based IDE called CRXDE lite. While those hardcore Eclipse fans may not completely switch over to CRXDE lite, it’s a nice mechanism to provide them with a nearly full-fledged IDE experience in the browser.

CRXDE Lite In-browser IDE

Developers can make changes to .jsp files (which are then recompiled behind the scenes), take advantage of the integrated check-out from a centralized subversion environment and the ability to commit back to the SVN, creation and compliation of OSGi bundles – as a replacement for Apache Maven.

All in all, it’s a much faster way to make smaller changes, or a quick look at the code.

Site Importer is one of the tools in CRXDE Lite that is designed to do exactly that: import non-CQ sites into CQ 5.3 (i.e. downloading all CSS, HTML elements into the repository). The CMS then creates a blueprint for that site, and developers can “translate” the import — component by component — into CQ5 templates and editable content components.

CQ 5.3 Site Importer Tool

 

Upgrading to CQ 5.3

Day says it’s a breeze and cites their own experience of upgrading the corporate site, which now runs on 5.3. There are two ways to upgrade for those on 5.x:

  1. Go to Package share and download the upgrade package, which contains the entire 5.3 install and migration bits. Restart CQ twice and you should be good to go.
  2. Using the familiar Quickstart .jar file with an upgrade mechanism built in to replace a prior version with the 5.3 binary and run migration scripts.

Depending on the complexity, you may expect various upgrade efforts and timeframes. According to Day, the upgrade of their http://dev.day.com site, which they consider to be an upgrade of medium complexity, took 14 hours. An optimistic outlook, isn't it?

Note that if you’re upgrading a CQ 5.2.1 instance with Hotfix 23673 installed, you may need to do some manual migration of user content, as CQ specific user content is lost in the upgrade to 5.3.

And a bit of trivia to wrap it all up, CQ 5.3 release cycle started April 1, 2009, went through 19 iterations of QA and bug fixing, before it was ready to go GA today. Oh, and MS Internet Explorer 6, while supported in CQ 5.3, is officially finita la comedia.