Posted:June 20, 2005

Early in the development and testing of my blog I realized that a lack of WYSIWYG editing was severely limiting my effectiveness.  I practically live within Word in my normal work life, and have become totally dependent on efficient word processing tools.

I thus set out to investigate and then settle upon an editor for WordPress.  This post presents the results of my investigations.  BTW, the editor I chose to use is Xinha, which is not necessarily the best, but became the one I was most comfortable with and confident that continued development will occur.  I discuss more about Xinha below.

Starting Points

Among many, here are some useful references to other editor listings and comparisons, some with specific reference to WordPress-compatible ones:

  • The original HTMLArea project now retains a list of dozens of editors
  • The Content Managment System review site, which is useful in general for CMS reviews, also has links to about 20 editors, 14 of which are open source (but not including Xinha)
  • The Primate Brow Flash blog has a pretty nice wrtie-up on editors, with specific attention to FCKEditor
  • The TWiki site has a pretty good listing of editors and reviews.

There are also editor and plugin references on the WordPress site, but I found them to be disjointed and less useful than the ones mentioned above.

Design and Use Objectives

Prior to any downloads or evaluations, I wrote out some of my objectives and criteria for eventually selecting an editor:

  • Basicially, ignored it if did not have strong cross-browser support
  • Preferred open source with active support
  • Also, wanted to be able to use with Wiki
  • Cut-and-pasted as source, rather than HTML (also method of transfer)
  • Rendering of non-supported HTML
  • Also, wanted to be able to insert styles, consistent with my site CSS styesheet
  • Also, very much like the idea of being able to cut-and-paste from
    existing Word documents, with extraneous MS-generated HTML (it’s ugly!) then removed (will try this
    with the one HTMLarea example)

Some Editor Comparisons

The table below compares some of the major editors that I investigated:

Editor and URL Link Notes
Spaw
  • like small footprint
  • seems to be fresh, with support "legs"
  • like configurability
  • not current WordPress plugin

FCKEditor
  • acronym leads to bad thoughts
  • most full featured of all investigated
  • code looks clean, complete; documentation is another matter
  • installation appeared very difficult
  • very strong multi-language, multi-environment support
  • not current WordPress plugin

HTMLArea
  • many versions of this, but older open source appear largely not to be supported
  • the zhuo.org site is the most modern, but updates have been nearly one year ago
  • very much like the idea of copying from Word and removing extraneous codes
  • See also http://www.zhuo.org/htmlarea/ for an example with an image editor and manager; Zhuo appears to have taken the lead in continuing to support the HTMLArea open source project

WYSI-Wordpress
  •  did not test due to install questions and issues

 

Cross-browser, Rich Text Editor
  • learned of late; did not fully investigate
  • demo screen looks interesting, with most features desired
  • looks very clean

TinyMCE
  • small footprinthas multiple language packs
  • like many of these other editors, inserts manual line breaks that can wreck havoc on edited code
  • based on Javascript

WYSIWYGII
  •  Another based on HTMLArea
  • Concerned about number of bug reports
  • Non-English site; concerned about the quality of documentation and support
  • As a result, did not test; used Xinha instead as the HTMLArea branch
Kupu
  •  looks quite intriguing
  • written in Javascript
  • uses CSS in preference to HTML; could be conversion issues
  • extensible, but also with limited initial functionality
  • not yet a WordPress plugint

 

 

The Choice of Xinha

Xinha is a  free WYSIWYG editor replacement for <textarea> fields.  Use of Xinha is granted by the terms of the htmlArea License (based on BSD license).

Xinha was originally based on work by Mihai Bazon which is copyrighted 2003-2004 by dynarch.com and copyrighted 2002-2003 by interactivetools.com, inc. Xinha stands for "Xinha is not HTMLArea," referring to Xinha’s fork from the earlier open source HTMLArea editor.  The HTMLArea editor received much attention, had many plugins, and had advanced to the full version 3.0 when its standard developers ceased supporting it.

A great demo of Xinha and its various plugins is available.  This site will allow you to test out the editor without going through the pain of installing it.

As the screen shot below shows, there is significant functionality within Xinha and a robust set of plugins.  The screen shot includes all available plugins.

 

As you can see, there is quite a bit of format, style, image and table support, plus other important functionality like search-and-replace, etc.  The other aspect of the system that is helpful is the ability to toggle to source.

The combination of these features, the earlier legacy from HTMLArea, and the appearance that James Sleeman intends on actively supporting this project caused me to select it for this site’s use.

Gaps and Wishes

In daily use I have come to have both a love and hate relationship with Xinha.  On the positive side, it does most of what I need it to do and has not crashed too frequently.  On the negative side, it does have quirky behavior and some of the other problems noted below.  My specific gaps and wishes are for:

  • Better documentation
  • Search and replace when in code view
  • Suppress forced line breaks when importing code
  • More stable behavior when moving from full to partial screen editing
  • Easier integration and standard plugin packaging for WordPress

Nonethless, that being said, I’d like to thank Interactive Tools and Mihai Bazon, the entities responsible for the initial HTMLArea versions, and James Sleeman, who has taken up the charge for the new Xinha fork.  May you remain committed to this project!

 

Author’s Note:  I actually decided to commit to a blog on April 27, 2005, and began recording soon thereafter my steps in doing so.  Because of work demands and other delays, the actual site was not released until July 18, 2005.  To give my ‘Prepare to Blog …’ postings a more contemporaneous feel, I arbitrarily changed posting dates on this series one month forward, which means some aspects of the actual blog were better developed than some of these earlier posts indicate.  However, the sequence and the content remain unchanged.  A re-factored complete guide will be posted at the conclusion of the ‘Prepare to Blog …’ series, targeted for release about August 18, 2005.  mkb

Posted by AI3's author, Mike Bergman Posted on June 20, 2005 at 5:53 pm in Blogs and Blogging, Open Source, Site-related | Comments (0)
The URI link reference to this post is: https://www.mkbergman.com/18/preparing-to-blog-editor-comparisons/
The URI to trackback this post is: https://www.mkbergman.com/18/preparing-to-blog-editor-comparisons/trackback/

Though I’m impressed with how quickly a blog can initially be set up and released, I guess I have more of a game plan like Patton invading Sicily prior to releasing my site. There’s a whole culture, language and set of technologies with which I’m not yet familar. Since once a site goes "live" it’s hard to hide stupidity, I guess I’m trying to understand things better to lessen the inevitable IQ decrement. I’m also sure that in a few weeks time I will look over this list with wonderment as to how much of a newbie I really was!

Some of the major items and specific tasks, none in particular order, that must be done and learned to getting this blog running on a routine, easily maintaned basis are:

  • Posting and comments formatting, utilities
  • Completion of Blog Web page content
  • Figuring out navigation and external link references (the general blososphere connectivity)
  • Longer-term functionality and its integration
  • Efficient (?) update and maintenance procedures.

As items get completed and may reference other posts, I’ll return and add the internal links.

General Editing

  1. Generalize the CSS style sheet, with more objectification and logical class names
  2. Create more consistent, minor style sheet classes and see if they can be referenced through a WYSIWYG editor (below)
  3. Learn how to have more WYSIWYG editing
  4. Learn how to enter standard HTML formatting into new post entries (incl. using bullets and numbered lists; when this displays OK that has been accomplished)
  5. Distinguish between list types
  6. Add a standard WYSIWYG editor
  7. Figure out procedures for moving existing and developing Word content for posting to the site.

Posts and Comments

  1. Decide about use of email address on site and for author posting comments –> do others have concerns about email capture for spam and does that suggest some captcha capability?
  2. Figure out how to split long posts — such as some of the main articles and white papers I intend to post — into multi-part segments
  3. Figure out if there is a slick way to use classes or styles for HTML insertions
  4. Add mechanisms for emailing a post, printing a post or downloading a PDF (where that makes sense)
  5. Add a standard Next – Back set of links at the bottom of every post for easier internal navigation between posts
  6. Work out the kinks in the entire Comments to posts area, specifically whether minor WYSIWYG editing should be provided and how to preview comments before posting.

Site Pages

Major templating of a few page types has already been done. However, text and templates for "standard" internal pages are needed for:

  1. 404 error
  2. Copyright
  3. About me
  4. About me (detailed and bibiography)
  5. About site (mission)
  6. BrightPlanet page
  7. DiDia page
  8. Masthead picture reference
  9. Chronology listing (work out formatting, plugin and PHP)

Navigation and External Links

  1. Add external links, GIFs where necessary, and do the registrations as appropriate for:
    • RSS (XML)
    • BrightPlanet
    • Blogstreet
    • Site Meter
    • Technorati
    • WordPress
    • The selected Wiki
    • Creative Commons stuff
  2. Limit some pages from appearing on site navigation
  3. Reserve, but don’t yet implement, the entire advanced feature anticipated for detailed categorization and placement
  4. Replace the current footer section; the queries stuff seems silly
  5. Separate out the calendar and archive sections

Wiki Integration

Find a Wiki tool that:

  • "Plays nice" with the WordPress environment
  • Can use the same style sheet
  • Can use the same editor
  • Has posted content that is seamless with the site for such things as site searching, categorization, etc.

Other General

  1. Research and better understand some of the spam and privacy protection concerns, especially in comments, emails, robots interactions and others
  2. Figure out the email return thing where the title line requires the sender to do clever replacements
  3. igure out the Permalink think
  4. Figure out the Trackback thing
  5. Figure out the Blogroll thing and decide if I want to use that feature or not
  6. Get a better search function and box
  7. Figure out procedures, icons, etc., for allowing PDF download capabilities
  8. Figure out how to archive and get formatted posts and pages from the MySQL database.
  9. Add shortcut icon (favicon.ico) for appearing in the browser address bar.

Final Release

  1. Clean up all entries
  2. Add date stamps/updated dates to all main pages
  3. Fix all broker links
  4. Finalize all styles, sizings, positions
  5. Complete and update this start-up checklist
  6. Write up an document best practices for starting and then running a blog.

Stuff to Defer Until After Initial Release

[Note:  these items were added just prior to initial release.]

  • Defer improved search function
  • Defer Wiki integration
  • Defer adding advanced categorization.

 

Author’s Note:  I actually decided to commit to a blog on April 27, 2005, and began recording soon thereafter my steps in doing so.  Because of work demands and other delays, the actual site was not released until July 18, 2005.  To give my ‘Prepare to Blog …’ postings a more contemporaneous feel, I arbitrarily changed posting dates on this series one month forward, which means some aspects of the actual blog were better developed than some of these earlier posts indicate.  However, the sequence and the content remain unchanged.  A re-factored complete guide will be posted at the conclusion of the ‘Prepare to Blog …’ series, targeted for release about August 18, 2005.  mkb

Posted by AI3's author, Mike Bergman Posted on June 20, 2005 at 9:38 am in Blogs and Blogging, Site-related | Comments (0)
The URI link reference to this post is: https://www.mkbergman.com/9/preparing-to-blog-master-to-do-list/
The URI to trackback this post is: https://www.mkbergman.com/9/preparing-to-blog-master-to-do-list/trackback/
Posted:June 18, 2005

I began adding content to the site. I’ll be working on a master to do list for all site readiness functions. My plan at this point is to work on the AI3 site daily, work out an acceptable time-of-day/effort routine, and get all baseline functionality and content in place prior to an "official" release.

My hope is that the site can go "live" in the next 2-3 weeks.

 

Author’s Note:  I actually decided to commit to a blog on April 27, 2005, and began recording soon thereafter my steps in doing so.  Because of work demands and other delays, the actual site was not released until July 18, 2005.  To give my ‘Prepare to Blog …’ postings a more contemporaneous feel, I arbitrarily changed posting dates on this series one month forward, which means some aspects of the actual blog were better developed than some of these earlier posts indicate.  However, the sequence and the content remain unchanged.  A re-factored complete guide will be posted at the conclusion of the ‘Prepare to Blog …’ series, targeted for release about August 18, 2005.  mkb

Posted by AI3's author, Mike Bergman Posted on June 18, 2005 at 11:23 am in Site-related | Comments (0)
The URI link reference to this post is: https://www.mkbergman.com/8/preparing-to-blog-begin-content/
The URI to trackback this post is: https://www.mkbergman.com/8/preparing-to-blog-begin-content/trackback/
Posted:June 17, 2005

Kevin Klawonn, BrightPlanet’s sys admin, got the basic blog package I had set up on my local machine transferred and installed on commercial servers. His report on this transfer follows:

Like most sysadmins out there, my plate is always full. So when I was asked to install WordPress I was hoping that it would be a simple installation taking less than 30 minutes to review the installation procedure, install the software, and then make the necessary configuration changes. Upon visiting the WordPress website, I saw the "5 Minute Installation" page and started laughing because my karma isn’t good enough that I should actually be able to have WordPress installed in 5 minutes.

I perused the requirements:

  • PHP v4.1 or greater. I had installed PHP before and this is a simple install
  • MySQL v3.23.23 or greater. I have MySQL installed on another server so this requirement was already met
  • Apache module mod_rewrite support. This was going to be the most difficult part of the installation.

The server identified to host WordPress already has IIS running on it and therefore did not have mod_rewrite support built in. Instead of finding a 3rd party option for this requirement, I decided to install Apache 2.0 on the same server. To accomplish this, I needed to force IIS to bind only to the IP Addresses which it actually uses. By default IIS binds to all IP Addresses of the server whether they are used or not. A Microsoft support topicI had used before explains how to accomplish this task; in my previous experience I had no side effects so I felt comfortable doing the same thing in this situation. http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q238/1/31.ASP&NoWebContent=1

Once done configuring IIS, I added another IP address to the server, opened port 80 in the firewall to the new IP Address and installed Apache 2.0 configuring it to use the new IP Address. I then installed PHP, and configured Apache to use PHP.

The final step before installing WordPress was to setup a database on MySQL. Although MySQL resided on a different server, this did not matter to the configuration of WordPress. I created a new database and user for WordPress to use.

Finally, I was ready to install the actual WordPress software. I uploaded the zip file to the webserver and unzipped it. I edited the wp-config-sample.php file per the "5 Minute Installation" instructions. Once the database information was configured, I opened my web browser and ran the http://{website}/wp-admin/install.php script. And in just that quick the blog website was setup.

Great work, Kevin, and other than some minor file references, I am now in a position to begin transfering what I had been prototyping locally.

 

Author’s Note:  I actually decided to commit to a blog on April 27, 2005, and began recording soon thereafter my steps in doing so.  Because of work demands and other delays, the actual site was not released until July 18, 2005.  To give my ‘Prepare to Blog …’ postings a more contemporaneous feel, I arbitrarily changed posting dates on this series one month forward, which means some aspects of the actual blog were better developed than some of these earlier posts indicate.  However, the sequence and the content remain unchanged.  A re-factored complete guide will be posted at the conclusion of the ‘Prepare to Blog …’ series, targeted for release about August 18, 2005.  mkb

Posted by AI3's author, Mike Bergman Posted on June 17, 2005 at 9:09 am in Site-related | Comments (0)
The URI link reference to this post is: https://www.mkbergman.com/7/preparing-to-blog-site-transfer/
The URI to trackback this post is: https://www.mkbergman.com/7/preparing-to-blog-site-transfer/trackback/
Posted:June 9, 2005

I have completed general design and functionality specifications for how I’d like the Wiki portions of my site and the dynamic placement (deep categories) aspect of my site to work.

I’ll use a later post to parse the Wiki specs against available open source packages to pick a final candidate.

In addition, I have also been assembling much prior content and deciding how much of it, if any, I will convert and use to "prime the pump" for the initial release of AI3.

 

Author’s Note:  I actually decided to commit to a blog on April 27, 2005, and began recording soon thereafter my steps in doing so.  Because of work demands and other delays, the actual site was not released until July 18, 2005.  To give my ‘Prepare to Blog …’ postings a more contemporaneous feel, I arbitrarily changed posting dates on this series one month forward, which means some aspects of the actual blog were better developed than some of these earlier posts indicate.  However, the sequence and the content remain unchanged.  A re-factored complete guide will be posted at the conclusion of the ‘Prepare to Blog …’ series, targeted for release about August 18, 2005.  mkb

Posted by AI3's author, Mike Bergman Posted on June 9, 2005 at 6:40 pm in Site-related | Comments (0)
The URI link reference to this post is: https://www.mkbergman.com/35/preparing-to-blog-advanced-functionality/
The URI to trackback this post is: https://www.mkbergman.com/35/preparing-to-blog-advanced-functionality/trackback/