Several of our EditLive! for IWWCM clients have asked me recently how they can get hold of EditLive! 6.4 so they can try out the new styling capabilities in the release.  This article will give you the information that you need to install EditLive! 6.4 in IWWCM.

The steps in this article require you to customize an EditLive! for IWWCM installer.  Before making changes to your IWWCM installer I'd recommend that you check out the series of articles I wrote previously on Custom IWWCM installers.  

1. Get a copy of the EditLive! for IWWCM installer - You can obtain a copy from either the Ephox website, or you can use a copy of an existing EditLive! for IWWCM 6.0 installer that you have.  
   • The advantage of using your own installer is that you will be able to install any customizations you've done along with EditLive! 6.4.
   • If you're downloading a new copy of the installer, unzip it to a location on your server so it's ready to be installed.
2. Backup - If you're using an existing installer that you've customized then you'll want to back it up before working with EditLive! 6.4.  EditLive! 6.4 is currently a beta and there are bugs, so you will want to make sure you back up your EditLive! for IWWCM installer with EditLive! 6.3 before starting this process.  If you need to go back to using EditLive! 6.3 then having that backup will be important.
3. Get a copy of EditLive! 6.4 - EditLive! 6.4 beta is available right now from the LiveWorks! web site in the Early Access section, you'll find a link to the EditLive! 6.4 downloads there.  In order to update EditLive! for IWWCM all you will need to download is the update package (the third download link in the list for EditLive! 6.4).  Unzip this package to a separate location on the machine with the EditLive! for IWWCM installer.
4. Add EditLive! 6.4 to the IWWCM installer
   1. Open the EditLive! update package you downloaded and select all the files except the sample_eljconfig.xml file (we don't want to overwrite this in case you've made customizations).  
   2. Copy these files into the EDITLILVE_IWWCM/web/res/editlivejava folder and overwrite the existing files when prompted, where EDITLIVE_IWWCM folder is the root directory of your IWWCM installer.
5. Run the installer - The installer is now ready to run.  Set the IBM Portal directory in the build.properties file in the installer's root directory if necessary and then run the install script.

You can find more information about what's in EditLive! 6.4 in the changelog.

If you have any questions or issues with the EditLive! 6.4 beta please let us know.  You can get in contact with us and the EditLive! community via the LiveWorks! mailing list.

There is a common misconception that EditLive's track changes functionality is intended to be a substitute for the version history built into most content management systems. In reality, the two systems work together to achieve different aims.

Version history is the corporate compliance that you need, track changes is the collaboration that you want.

So where version history precisely tracks every change so that you can ensure accountability, track changes puts users in control, giving them a tool they can use to highlight important changes that need review. One of the common problems people have with version history is that when you make formatting changes to a large section of the document, that entire section shows up as a change and smaller changes to the actual content are often missed. With track changes, the author making the change can leave track changes off while making the formatting changes and then turn it on so just the important content changes are marked as changed. This ensures the reviewer can see the important changes and consider them appropriately.

Track changes also handles multiple people collaborating on a single document at once, with each person's changes being shown in a separate color it's easy to see who changed what. While version history can reveal this information by looking at what changed in each individual revision, but track changes allows you to see that information altogether in one place. When documents go through an extended collaboration process this can be extremely useful. You can also accept and reject track changes during the collaboration process as consensus is formed and the document takes shape, again focusing authors on just the changes that really matter, regardless of which version the change was made in.

Finally, the track changes data is shown right in the editing interface so users don't have to flip between editing the document and reviewing the previous changes.

So how does track changes work with version history at the technical level? Seamlessly usually. The track changes data is stored right in the HTML so it's versioned along with the content without any changes to the CMS. Additionally, the track changes mark up is designed to be completely hidden when viewed in a browser so you can see what the intended final version of the document was without the track changes markup getting in the way. We've also documented the track changes format so you can parse it and manipulate it in any way you want (it's based on the open document format's track changes but modified to work with HTML instead of ODF).

If you want to see track changes in action, try out our demos or watch the recording of our recent quarterly product update webinar which steps through a common use case for track changes.

A new SmartQuotes plugin is now available which automatically converts double and single quotes to curly or smart quotes. It also converts three periods (.) to an actual ellipses character.

Most people don't realize it, but URL encoding is actually different depending on which character set is used at the time. Characters can be corrupted if a string is URL encoded using one character set and decoded using a different character set.

Take for example the Ä character. Using the default character encoding for Windows in the US (cp1252) it's encoded as %C4, however using UTF-8 it's encoded as %C3%86. If you encode it with UTF-8 and decode it with cp1252 you actually wind up with two characters instead of one.

Most URL encoding functions unfortunately don't require a specific character set to use but instead use the character encoding for the page. JavaScript. PHP and ASP all act this way so make sure that the page's encoding is set to the same encoding as the document you're encoding. As always, check that EditLive! is using the same encoding either by specifying it in your configuration file or with a meta tag in the head of the document.

Related documents: Specifying Character Sets For Internationalization

As you're probably aware, you can customize which menu items and toolbar buttons appear in EditLive! by editing your configuration file. However, most people don't realize they can also customize how those items appear while preserving the underlying functionality.

For example, if you wanted to replace the icons so they better matched your particular application's look and feel, you could do so by specifying the imageURL attribute on any or all of the item entries in your config file. So to change the "cut" menu item to use the image file "http://example.com/myCut.gif" the configuration file element would be:

<menuItem name="cut" imageURL="http://example.com/myCut.gif" />

Similarly the toolbarButton element would be:

<toolbarButton name="cut" imageURL="http://example.com/myCut.gif" />

When the user selected one of these the standard Cut routine would still be executed and the default text for the menu item and toolbar button tooltip would still be used. For best results, make sure the image you specify is 16×16 pixels and has a transparent background.

If you wanted to change the text or tooltip, just add a text="My New Cut Text" to the menuItem and toolbarButton element respectively. It's just the same as if you were using a custom menu item or custom toolbar button except that the behaviour is already implemented for you.