Skip navigation
All Places > Alfresco Content Services (ECM) > Blog > 2010 > December
Alfresco 3.4.c Community release has just been released, and there are a few enhancements to Web Quick Start that are worth a mention.

Word-to-HTML conversion

A new rendering engine has been plugged in that takes .docx files and renders them into nice clean XHTML suitable for styling with CSS, and extracting images with appropriate embedded references to them. For example, if I specify a new rendition configuration named 'docxToHtml':

<bean class='org.alfresco.module.org_alfresco_module_wcmquickstart.rendition.BootstrapRenditionDefinition'>

<property name='name' value='docxToHtml' />

<property name='renderingEngineName' value='htmlRenderingEngine' />

<property name='parameters'>


<entry key='runAs' value='System' />

<entry key='destination-path-template' value='${cwd}/${name}.html' />

<entry key='bodyContentsOnly' value='true' />

<entry key='imagesSameFolder' value='true' />




and then specify that that rendition should be triggered on the blog section of the WQS website whenever a docx file is uploaded by setting the 'Rendition Config' property on that section (note the ridiculously long MIME type):

If I then upload a Word document into the blog section of the website then it will be converted automatically into XHTML. As an example I uploaded the original Word version of one of Ben Hagan's blog posts, one page of which looks like this in Word:

Once uploaded into the blog section of the WQS site, browsing to the generated HTML rendition in Firefox looks like this:

No manual processing required - as soon as the upload of the original Word doc finished this HTML version was available to look at on the website. The markup's nice and clean too.

Asset-by-asset template override

Previously, it was possible to specify which page template to use on a type-by-type and section-by-section basis. That is to say that you define rules such as 'when rendering an article from the blog section use the 'articlepage2' template' or 'when rendering the landing page of the news section use the 'sectionpage3' template'. That remains the case in 3.4.c, but we have also added the ability to specify the template to be used for an individual asset. This is quite handy if you want most assets in a particular section to be rendered in a particular way but need one or two to look different.

We use it in the case of the homepage of the WQS website, as we want the default landing page template for sections to be 'sectionpage1', but for the landing page of the root section (the homepage of the website) we want to override this to use the template called 'homepage'. Therefore we set a template mapping on the root section for the normal case ('ws:indexPage=sectionpage1') and override the template on the index.html asset in the root section to be 'homepage':

Support for multiple WQS web apps in a single web container

In 3.4.b the logic that the WQS API used to determine which website was being addressed made use of the requested host name and port number but not the context of the addressed web application (the part of the URL that is 'wcmqs' in an out-of-the-box installation). This has been resolved in 3.4.c so that all three components are used to look up the correct website in the repository. The effect of this is to make it much simpler to deploy multiple websites that have differing functionality, since they can now all be deployed in a single instance of Tomcat, for example, without having to define multiple host names.

And some bug fixes, of course...

In addition to these things we have also fixed up some WQS bugs that we and members of the Alfresco community found in 3.4.b. As always, we're keen to hear your thoughts and ideas for future enhancements. If you have questions about or ideas for Web Quick Start then please visit the Web Quick Start forum and let us know. If you'd like to find out more about the Web Quick Start then take a look on the wiki.
I managed to get a bit of time on my flight to Lisbon the other day to make a few last changes to a tool I've been working on on and off for the last few weeks, to provide a standard way of loading (and dumping) the contents of Share sites for demonstration content.

I'd considered ways of doing this in the past, mostly when I've got frustrated with setting up sample content in the new Share instances I usually create for demos. Bootstrapping content via ACP files is the usual method of loading content that's employed by Alfresco's own patches, but that didn't really feel flexible enough and in any case, isn't able to package up some of the data which makes up a Share site, such as configuration stored in the sitestore AVM store.

I also wanted a tool which allowed content to be imported into an Alfresco instance running on a local machine, but also on remote machines as well. Sometimes I demo locally but other times I fire up one of my Amazon images instead. So it seemed like an external process was required.

Then we started discussing a few weeks ago what additional tutorials and sample content we could provide to partners to coincide with the upcoming Enterprise 3.4 release, and the possibility of reusing some of the great demo content from the Alfresco Cloud Trial. There seemed some overlap.

The result is this project, which I'm tentatively naming Share Import-Export, and which provides a set of Python scripts that can export site-based content and user information from Alfresco  Share, and import that content into another Alfresco Share server. Some sample content is also provided from the Cloud Trial  environment, kindly supplied by Paul Hampton.

The package is intended to help set up demonstration environments quickly, reliably and consistently. The scripts are not suitable for importing or exporting large volumes of content or for any general production use such as system backups.

The scripts work with versions 3.3 and 3.4 of Alfresco, and can work against 3.2 with a couple of small tweaks. No additional customisations are needed in Alfresco or Share, so you can export data from existing systems without any fuss.

What can be imported/exported?

For sites

  • Site configurations

  • Site members (users only at present)

  • Site dashboards, including dashlet configuration

  • All content held within the site (manual export via ACP)

  • Records Management sites (must have RM installed)

  • Web Quick Start sites (must have WQS installed)

For users

  • All profile information, including profile images

  • User dashboard configurations

  • User preferences

  • User groups and group memberships

What is not imported/exported?

  • Document categories and tags (not currently supported by ACP format)

  • User passwords and account enabled flags (all accounts enabled)

  • Activity feed entries

  • File system-level customisations (e.g. custom dashlets) and configuration

How does it work?

The scripts mimic a web browser logging into the Share web  application, then invoke a number of mostly JSON-based web scripts to  read and write data to and from the application. JSON is also used as  the format for storing exported metadata and user information, since it  is well-structured, human readable and lightweight. Python has strong  support for JSON data via the json module. ACP format is used to package  up site content.

Download and Usage

Downloads and more information can now be found on the Share Import-Export project page.


You can help by testing the scripts against your own test data and  posting feedback, either by adding a basic comment below or (even better) by posting feedback in the Issues section.

You are welcome to redistribute the tools under an Apache 2.0 license and encouraged to submit any enhancements you make.

Filter Blog

By date: By tag: