No, I’m not passing a handle, My node contains a text version of the name to link to so I’m wanting to handle-ize it. But it doesn’t work. The handle-ize function isn’t returning errors, but it also isn’t populating the field in the db with any info other than ‘0’.

I don’t know if this is a bug? Has anyone else done this??

I can (and have) worked a long route round to output xml via Symphony, using dynamic ds and content from the db to get the relevant IDs, but that takes a very very long time.

Any help would be appreciated in getting this to work with the Lang::createHandle method.

Talk about a massive extension - this thing saved me days of monotonous work. HUGE thanks!!!


Oh, and if anyone is in need of a macro to turn Excel tables into XML, you can find a solid one here:

Is the extension mentioned in the first comment the latest available?

It returned a lot of errors, and did not save on 2.08. (fixed most of the errors locally, but I think I downloaded an old version?)

@creativedutchmen the best one to use is the integration branch, I couldn’t get the other branches to work…

Hope this helps?!

Ah, I see.

I was indeed trying to use the master branch, thanks!

I’m trying to get this to work with an XML export from blogger and failing. I started out by using some complex selecters and in an attempt to just get it to work I’m now using very simple expressions. When I run the importer I receive a message:

Import Failed
No entries to import.

I was using the main branch but that wouldn’t even save my field definitions so I switched to the unstable branch at the suggestion of someone here, my screen is:

And a samle of the XML that I’m using is:

   <feed xmlns:thr="" xmlns:gd="" xmlns:georss="" xmlns:openSearch="" xmlns="">
    <title type="text">Brands and Reputation</title>
    <link rel="" type="application/atom+xml" href=""/>
    <link rel="self" type="application/atom+xml" href=""/>
    <link rel="" type="application/atom+xml" href=""/>
    <link rel="alternate" type="text/html" href=""/>
        <name>Elliot Schreiber</name>
    <generator version="7.00" uri="">Blogger</generator>
        <category scheme="" term=""/>
        <title type="text">Template: Brands and Reputation</title>
        . . .
    . . .

You won’t need the ./ before title/text().

You’ll need the namespaces on for atom. This thread or this one may be of assistance. I believe it’s been discussed in this thread before as well.

Sadly that didn’t fix the problem, see:

When I run that it outputs:

Try adding Atom as a namespace (Atom,, and changing the path to be atom:feed/atom:entry and then your xpaths to atom:title/text() etc

Ahh thanks a lot brendo that was exactly the problem!

Glad I could help :)

Any updates for this extension? Does this work in 2.1.0 or 2.1.1?

I have no problems so far in 2.1.1

Could I make a suggestion? Well, first, I installed it and ran some test data through it and it worked fine, but my data was relatively shallow, and I could see a situation where a node or node sequence would need to be massaged a little bit before it gets put into a field. Right now selecting field content by XPath means it’s sort of all or nothing unless the user wants to start writing PHP code. Since XSLT knowledge is already a requirement for working with Symphony, maybe put a place for a stylesheet at the beginning of the pipeline? An example might be importing a DocBook <article> into an Article in the default workspace. I don’t think there’s a way right now to grab all the child <sect1> elements and turn them into xhtml <p> or the Markdown equivalent in the body of the Article. A stylesheet at the start of the import could flatten and transform the incoming XML into easily digestible transitional XML that the XPath statements could then chop up into fields. Thoughts?

Since XSLT knowledge is already a requirement for working with Symphony, maybe put a place for a stylesheet at the beginning of the pipeline?

I’ve been dreaming about that for both the Importer as well as the Dynamic XML DS too! :-)

@toman - would you mind posting your XML? And would you mind posting the details about the section you want to import the data into?

@bzerangue: I’ve attached a DocBook article which I’ve hacked up a bit to make the point, but it still should be valid. It has multiple <sect1> that should be collected into one and also has mixed content. The section I was referring to is the Article in the default workspace. All the <sect1> should be collected into the body field, and their (mixed) content should be transformed accordingly. XPath is wicked cool, but it can’t get there on it’s own. That’s why XSLT and XQuery were invented. Certainly I could do this transformation before sending the data to xmlimporter, but that assumes I have control over both ends and doesn’t improve symphony. Running the data through an optional stylesheet before chopping it up with XPath(s) should have minimal impact on the code, while maximizing the flexibility of the extension. Also, that could be the place to do the namespace stripping/mangling.


@phoque : That’s an interesting idea about the dynamic XML DS, though in that case you could argue that any stylesheet required could be applied prior to presentation, as it is now. An argument in favor of your idea would be that if you replace the namespace declaration part with a more general stylesheet, that’s one less “extra” thing a potential Symphony user would need to know, given they have a working knowledge of the XML technologies in use.

This reminds me of another question I had about dynamic XML DS, which is also applicable to xmlimporter so I’ll mention it here: Since the Internet is unreliable, is there any way to do error handling for a dynamic XML DS? For instance, if a dynamic XML DS is unavailable then switch to a static XML DS, or an alternate dynamic XML DS?

If I have a hard time with importing xml, I just Dynamic datasource it, apply it to a page where I rebuild it slightly, then import that into the sections.

It made it easier to handle a nightly feed of updates from another system!

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details