One of the very common questions customers ask is "Why does EditLive insert an empty paragraph tag with non-breaking space (  or  ) in code view?".  This article addresses the reasons behind this behavior of EditLive!. 

When

1. When you first load EditLive! without any content in its body
2. Pressing "Enter" key in the design view of EditLive!

Why

1. EditLive! assumes user will start typing after the initial load and prepares the editor by placing an empty paragraph at the start of the empty document. This provides a place in the document to actually position the caret and allow the user to start entering text. If the user chooses to insert a heading tag instead of a normal paragraph, EditLive! simply replaces the paragraph with the relevant heading.
2. Most browsers ignore empty paragraph tags, so to ensure the page displays as the user intended, a non-breaking space is inserted into empty paragraphs.

Bookmarks (also known as Anchors) are a normal part of any web content.  As well as linking to an external document section, they can be used to navigate within sections of the current document.  We have a feature in EditLive! to generate these links easily, but the feature is so well integrated into our UI that I recently discovered even some of the Ephox employees don't know about it.

When creating bookmarks, most people follow a five step process:

1. Find the text to bookmark
2. Insert a bookmark at that location
3. Find the place that will link to the bookmark
4. Open the Hyperlink dialog
5. Find the bookmark that has just been created and link to it

When building EditLive! we realized that the majority of these links will be to document headings, so we shortened it to a two step process:

1. Open the Hyperlink dialog
2. Find the heading you want to link to, and link to it

Any time you open the Hyperlink dialog, we find all heading tags in the document (H1 to H6) and list them under "Places in Document".  For example, the following HTML:

<h1>First Heading</h1>
<h2>Sub Heading</h2>

Looks like this in the Dialog:

Notice that spaces are removed from the bookmark address.  You don't have to worry about the dialog generating bookmarks you'll never use - they are only created when you actually link to them.  They're also inserted around the entire heading text so that it renders the heading with a blue underline and ensures the bookmark is not empty (which has caused problems on some integrations).

Combine this with easy linking to clipboard URLs and you have some cool tricks to improve your productivity.

EditLive! provides a rich, full featured and user friendly editing experience, but sometimes you need to roll a system out to users that may not have Java installed and that can sometimes cause deployment headaches. In the past the only option was to give up much of the functionality and ease of use that EditLive! provides and use a JavaScript based editor instead - great for users without Java but limiting and often frustrating for everyone else. So we've come up with a solution that gives you the best of both worlds and we call it Express Edit.

To get as many users up and running as fast as possible, Express Edit adds a JavaScript based editor to EditLive! with a subset of EditLive's functionality yet providing a quick and easy way for users to switch over to the full editor. The best part is that both the JavaScript and the full editor use the same configuration and provide nearly identical interfaces to the user. In fact, taking advantage of Express Edit only requires two minor changes to your existing EditLive! setup.

1. Include the Express Edit JavaScript file. Do this immediately after you include the standard editlivejava.js file, for example:
   <script language="JavaScript" type="text/javascript" src="/editlivejava/editlivejava.js"></script>
<script language="JavaScript" type="text/javascript" src="/editlivejava/expressEdit/expressEdit.js"></script>
2. Instruct the instance of EditLive! to enable Express Edit.
   editlive.setExpressEdit("true");

We think Express Edit is a huge benefit for both users and system administrators. For users, the single configuration for both editors means that the interface is familiar whether they are using the JavaScript editor or the full editor so upgrading to the full editor is painless and just lets them keep working. For administrators and developers, having a single configuration file reduces maintenance costs and dramatically simplifies development and deployment - we've taken care of it all for you.

Since this functionality is so new, you'll need to be using one of the early access builds from version 6.2.7.73 and above. Also, on OS X Java is always installed and available so we always load the full editor. Otherwise, initially the JavaScript editor loads and the user can chose to switch over to the full editor if they desire. Once as user has switched to the full editor, it will load by default to give them the best experience possible by default in future.

Express Edit will be a part of the EditLive! Productivity Pack but feel free to try it out even if your license doesn't include the productivity pack. Over the next few weeks we'll look more in depth at Express Edit and what it can and can't do.

Have you ever put a piece of content through your system only to find that when you get it back some characters aren't quite right?  If this sounds like something you've seen recently chances are you are seeing a character encoding problem.

Unfortunately, characters aren't characters aren't characters when it comes to putting text through an application.  You need to make sure all the layers of your application from the database through to the text editing solution are all encoding using the same character set.  If this is not the case, you're likely to see character corruption, particularly for special characters i.e. characters from the extended character set.

Spotting the Issue

So how do you spot a character encoding problem?  It's usually pretty obvious but here are some key pointers:

• The symbol ? appears on entering text. This means character encoding has been corrupted.
• The curved quote characters “ and ” or apostrophe character ’ - typically present in content imported from Word - are corrupted
• Special characters you insert using EditLive!'s symbol dialog insert correctly but are incorrect once the content has been submitted through the system.

This is not to be confused with situations where you get the □ character in the document.  If you see the box character this signals that the character cannot be displayed because the system doesn't have the required font installed (more info).  This is typically seen when trying to render Asian characters on an English system.

Fixing the Problem

The good news is that this problem is pretty easy to fix.  All you need to do is change the character encoding used in EditLive! to match that of your web application.  All you need to do is open up the configuration file for EditLive! and add a <meta> tag.  Your configuration file(s) can be found in:

• IBM/PortalServer/installedApps/WCM_Authoring_UI__PA_XXXXXX.ear/PA_XXXXXX.war/ephox/editlivejava for ILWCM 5.1.0.x
• IBM/PortalServer/installedApps/WCM_Authoring_UI__PA_XXXXXX.ear/res/editlivejava for ILWCM 6.0 or above

We've found that setting the character encoding to UTF-8 usually does the trick:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

However, if that still doesn't work you'll have to investigate your ILWCM settings to determine the character set correctly. Note that fixing the character set won't restore characters that have previously been corrupted.

If this doesn't solve your character encoding issue then chances are the issue is something else masquerading as a character encoding issue and you should get in touch with Ephox support.