Burning XHTML bridges to WordPress

Three months ago, in a November post, I explored the “top 3 most-popular and most-reliable WordPress.org security plugins” at the time. Although some might blame the WordPress.org community for any security vulnerabilities, it is also the responsibility of the user to “actively maintain and update the software”. In other words, “your blog is only as strong as its weakest plugin”.

Later, in a December post and January post, I investigated the possible “downfall of topic-based XML authoring and topic-based information architecture” and the “growing impact of WordPress as an enterprise CMS and enterprise SaaS”. If XML CMSs mean extinction, I also wondered whether “XML-oriented integrations… will forever be incompatible with PHP-based CMSs like WordPress.”

Madcap Flare: Topic XML view and text view

Hi, my name is Jay, and I’m an IBM TRIRIGA information developer at IBM. In my ongoing journey to explore topic-based DITA-XML authoring and its relationship to social-based WordPress strategies, I stumbled across a fascinating five-year-old solution that allows you to import your DITA-authored XHTML output into your WordPress.org installation.

Why import XHTML into WordPress?

More than five years ago, WordPress co-founder Mike Little developed the DITA-to-WordPress import tool to overcome output limitations in the DITA Open Toolkit transformation types.

DITA to WordPress Import Tool (07 Feb 2009)

This ‘plugin’ is a DITA to WordPress importer. Specifically it is a WordPress import module which will take the two-pane ‘Web Help’ output from the DITA Open Toolkit and import the hierarchy of XHTML pages into WordPress. It will import images too, though not as WordPress attachments.

Although the definitions of “plugin” and “webhelp” might’ve evolved in the last five years, Tom Johnson elaborated on the DITA-OT output limitations and the benefits of the WordPress platform.

WordPress Tip: Merging Worlds: DITA and WordPress (08 Feb 2009)

The DITA-to-WordPress tool fills a major gap with the existing DITA outputs. Currently, the DITA Open Toolkit doesn’t have a webhelp output. The XHTML output provides an index of files in a left pane with the topics in the right, but it is so plain and unattractive that I can’t imagine anyone actually using it.

With the DITA-to-WordPress importer, you can use WordPress as your online help format. This approach provides unique advantages over other help tools on the market. Basically, WordPress taps into all the juicy features of Web 2.0 and gives you them for free…

Additionally, WordPress provides an attractive website format that can change the way users feel about help. The standard help file, such as a .chm or tripane webhelp, has lost much of its appeal with users. WordPress can rejuvenate your users’ attitude about using help by providing a new, contemporary look.

Last year, four years after his initial post, Tom Johnson revisited Mike Little’s DITA-to-WordPress import tool and emphasized the idea that you don’t need to sacrifice your XML authoring tool.

Import DITA Webhelp Output into WordPress (21 Jan 2013)

I have toyed off and on with the idea of publishing help to WordPress for years. I’ve had two main reasons for not moving forward sooner. First, if you want an online platform for documentation, Mediawiki works pretty well. Second, my organization’s security department has frowned on WordPress due to security concerns…

[Y]ou actually don’t have to decide whether to use WordPress OR a help authoring tool. You can use both. You can author your content in Flare, Robohelp, DITA, or whatever other tool/method you use to generate an webhelp output, and then import the webhelp into WordPress through an import tool. Essentially your help authoring tool becomes your source repository, and you publish out to WordPress…

If you want to use this [import] tool, you have to do a bit of hopscotch to get it to work. The developer created it many WordPress moons ago, and now it’s no longer compatible with the latest version of WordPress as a plugin.

While this aging import solution might still be impressive today, I’m also wondering whether the required “hopscotch” configurations and subsequent cleanup issues might be too much trouble.

Why maintain DITA, XML, or XHTML at all?

Like I’ve noted in previous posts, it’s difficult to ignore the limitations of an XML-oriented CMS.

Killing XML and IA with social media (23 Dec 2013)

Once again, it’s rather unfortunate that IBM didn’t choose to migrate its infocenters to a more-immediate more-social experience like IBM Connections, WordPress, or MediaWiki, where there is a deeper potential for not only community commenting, but also community writing, editing, and architecting.

Shifting DITA-XML editors into SaaS (20 Jan 2014)

After sifting through the major XML-oriented, CMS-supported, and web-based pieces, it’s difficult to ignore the global momentum toward free-hosted and enterprise-level SaaS solutions. But it’s also difficult to ignore the growing impact of WordPress as an enterprise CMS and enterprise SaaS.

However, if you must maintain massive amounts of technical content in an XML-oriented CMS, I can understand how you might not have the option of fully migrating to an enterprise WordPress CMS.

Why maintain both an XML CMS and WordPress CMS?

Here’s where the XHTML import scenario seems to get tricky. Assuming you must maintain an XML CMS and depending on the scale, complexity, and cleanup of your XHTML imports, you’re effectively maintaining a second CMS in WordPress. In this case, I question the need for dual CMSs, especially dual enterprise CMSs, and challenge the notion that you “don’t have to decide”.

Taking the scenario further, if you’re faced with an inflexible XML CMS and a vibrant WordPress community, you might be forced to burn your XHTML bridges to fully migrate to WordPress. On the other hand, if you’re satisfied with a consistent XML CMS and worried by an unpredictable WordPress evolution, you might be tempted to burn your XHTML bridges to avoid WordPress.

Looking beyond this aging XHTML import tool, these dual-CMS issues would still arise with any similar topic-based XML-to-WordPress tools or plugins in the future. In fact, on Mike Little’s aforementioned blog post, one of his comments struck me. When a reader asked Mike about “any new developments or new insights” in using his import tool, Mike crystallized the central point.

[I] haven’t worked on it for years. I don’t work with DITA any more, so the need is not there.

What are my final thoughts?

For put things into perspective, the DITA Open Toolkit was released only 9 years ago while WordPress was released only 11 years ago. Yet, as time flies, software technologies rise and fall.

Naturally, as an IBM information developer, my wandering thoughts on these XHTML-import approaches and XML-to-WordPress possibilities gravitated toward the implications for IBM and its own DITA-based IBM Knowledge Center strategy. Unless IBM is already planning a WordPress strategy, I still can’t escape the cold evolutionary conclusion that I made in my December post.

The IBM Knowledge Center is a monumental first step, but it’s far from the final step. I’ll go so far as to predict that depending on the rapid evolution of social-media and socio-mobile technology within the next 5-to-10 years, IBM will be forced to migrate its product information once again — to a more-flexible ”social documentation” platform.