Probably the major impediment for the widespread adoption of Symphony as a content management system, besides the fear factor of XSLT, is probably the changes to the core database management code and structure. This has prevented a smooth transition from version 1.6 to 1.7 and from 1.7 to 2.0. However, Symphony 2.0 can import XML, it just takes a little bit of set up.
The first step would be to grab some XML to import. I have a blog I set up just for this purpose. I combined two learning opportunities into a WordPress blog. I had a long neglected account on WordPress.com, so I figured I would revive it to store ActionScript 3.0 / Flex 3.0 SDK code snippets as I learned how to build open source ActionScript code to build SWF files with nothing more than a command line terminal and a text editor. I also thought it would be a good exercise in getting to know WordPress, plus a means to build up a library of blog entries to use as an XML import data source for Symphony. People are asking for working examples of the ActionScript experiments, but WordPress.com doesn’t seem to allow uploading of SWF files, so I figured it’s time to decommission WordPress and import data into Symphony.
Grabbing the XML is as easy as navigating to Tools : Export and clicking on the “Download Export File” button in WordPress. Kudos to the WordPress crew for implementing this feature. I ended up with this XML file, which amounts to 5515 lines of XML.
We could do this a few different ways. We could import the RSS feed as a Dynamic XML data source. We could paste the code into Symphony and save it as a Static XML data source. Or we could use the
document() function to import the XML file and save the XML as a node-set in an XSL variable. I decided on the latter.
So, I first created a page called “Import” with a page type of “admin” and modified the navigation utility to exclude this page from the navigation:
<xsl:for-each select="/data/navigation/page[not(types/type = 'admin')]">
The “admin” page type is a special type of page that cannot be viewed on the front end by anyone who is not logged in as an admin user. This is very handy for pages that will require some front end forms that could otherwise be content spammed by unauthorized users. It works as a nice safeguard for any pages that might be in development. Just remove the “admin” page type when you are ready to go live.
Then, I took a look at the XML file generated by the WordPress Export and found several different XML namespaces being used. To avoid undeclared namespace errors, I added the namespace declarations to the XSL style sheet by copying them from the XML file generated by the WordPress export, which is actually a RSS file.
<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:excerpt="http://wordpress.org/export/1.0/excerpt/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:wp="http://wordpress.org/export/1.0/">
Then, the document is imported into the XSLT page template for the Import page as an XSL parameter:
<xsl:param name="wordpress-xml" select="document('../assets/xml/wordpress.2009-05-11.xml')"/>
Now, any contents of the document are accessible to Symphony by using the appropriate XPath expressions:
<xsl:for-each select="$wordpress-xml/rss/channel"> <h3><xsl:value-of select="title"/></h3> <p>WordPress Base Blog URL: <xsl:value-of select="wp:base_blog_url"/></p> </xsl:for-each>
To save entries in Symphony, we’ll need to create some events and some front end forms.
DesignProjectX | The digital sandbox of Stephen Bau