Wordpress should allow input of XHTML/HTML via Atompub

[mcepl]

One of the intended purposes of Atom standard was to allow better way of including XHTML in the feed than with “escaping it” (see this ​article by Norman Walsh in xml.com with followup at ​1, ​2, and ​3, there is also ​an interesting discussion under this blogpost and ​Tim Bray’s essay on the same theme) Even though even ​Norm agrees that he lost this fight, at least Atom provides opportunity for conscious authors to use namespaced XML properly.

Now, of course, the problem is that all this beauty is not supported by any known-to-me Atompub-accepting blog server. Particularly when this perfectly valid Atom 1.0 feed (take a look at ​validator if you don’t believe me):

<?xml version="1.0" encoding="utf-8"?>
<atom:feed xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/" xml:lang="en">
  <atom:title>Late Night Thoughts on Listening to Mahler’s Ninth Symphony</atom:title>
  <atom:updated>2009-04-08T00:13:32+02:00</atom:updated>
  <atom:link rel="alternate" type="text/html" href="http://matejcepltest.wordpress.com/"/>
  <atom:link rel="self" type="application/atom+xml" href="http://matejcepltest.wordpress.com/feed/"/>
  <atom:author>
    <atom:name>Matěj Cepl</atom:name>
    <atom:email>ceplm@seznam.cz</atom:email>
  </atom:author>
  <atom:id>http://matejcepltest.wordpress.com/</atom:id>
  <atom:rights>Copyright 2007 Matej Cepl</atom:rights>
  <atom:entry>
    <atom:title>John 3:17 or The Golden Middle Ground Between Grace and Sanctification?</atom:title>
    <atom:link rel="alternate" type="text/html" href="$url"/>
    <atom:id>urn:mc:ceplovi.cz:atom1:blog:jan-3_17-2008-07-10</atom:id>
    <atom:updated>2008-07-13T00:00:00+02:00</atom:updated>
    <dc:subject>John 3:17 or The Golden Middle Ground Between Grace and Sanctification?</dc:subject>
    <atom:content type="xhtml" xml:lang="en">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>There is a couple of things, which make for me sense together
  	(and I am not sure, of course, whether they will make sense to you
  	as well), and which I would like to record here.</p>
        <p>“<span class="scripture">For God sent not his
  	Son into the world to condemn the world; but that the world
  	through him might be saved.</span>” (J. 3:17)  In some aspects and for some
  	people (like me) and in certain moments, this is even more important
  	than the previous verse, and yet it is quite rarely mentioned in the
  	Church. Maybe because it so clear, that nobody gets much fame to explain
  	(and there is not much to explain here?). For all of us, who live with
  	the idea of God-policeman, following our doings to punish severely any
  	small misstep, this is the good news.</p>
        <p>There is quite certainly something significantly wrong about preaching,
  	that we always quote only  (John 3:16)  and
  	we don’t continue one verse further. As if we are still more interested in what’s
  	there in gospel for me, and we don’t understand, that we are not the central figures
  	in whole Bible. Not that there wouldn’t be anything there for us, but … that’s another long
  	discussion I would like to have with Dave.</p>
      </div>
    </atom:content>
  </atom:entry>
</atom:feed>

is sent to Wordpress.com I get ​rather disasterous result.

According to ​Peter Westwood wordpress treats all content delivered by different modes of remote publishing as the same dummy plain text.

OK, so the request of this ticket (and hopefully place of further discsussion if necessary) is to fix this and make <atom:content type="xhtml"> considererd and delivered so that wordpress would just accept the nodetree inside of such element as a body of the blogpost without much further changes.

Also #6128 might be caused by this.

[mcepl]

After reading this again next day, I found that I have totally confused two issues into one and making pretty big mess by that:

1. Wordpress should allow input of XHTML/HTML via Atompub. Whether it is escaped HTML mess, namespace-based XML (which I would prefer), or anything including pigeons, doesn't matter that much.
2. Having satisfied 1., I would prefer is proper namespace-based atom:content[@type='xhtml'] was used, but it is certainly less priority.

[mcepl]

Fixing the title with hope that somebody will finally take a notice.

[josephscott]

Have you tested this against WordPress.org -trunk? That would be more helpful than testing against WordPress.com, which has other restrictions in place.

[dturvene]

The type="xhtml" attribute seems to retain the XHTML tags for me. Using a CDATA section did not (though I think it should but that's a problem with the PHP xml parser.) I documented my progress at ​http://www.turvene.net

I just sent the posting given above to my test system and the XHTML tags in the content element were retained (even the UTF-8 characters were retained!)

One note:

If you use <feed xmlns="​http://www.w3.org/2005/Atom">, then the default namespace is "atom", you don't need to add it to each element name. It saves a lot of typing, especially if you want to change name spaces (e.g. I used to use Dublin Core a lot.)

[rmccue]

I believe #7652 should fix this, as it'll be using SimplePie for the parser, which does support this.

[mcepl]

Replying to josephscott:

Have you tested this against WordPress.org -trunk? That would be more helpful than testing against WordPress.com, which has other restrictions in place.

I don't have my own instance of wordpress (among other things because of this issue) ... is there anywhere a testing instance I could use?

[nacin]

As AtomPub was removed from core in 2012, see #21866. There is a plugin for it here: ​http://wordpress.org/plugins/atom-publishing-protocol/.

I doubt anyone really interfaces with WordPress via AtomPub anymore. Did anyone ever truly use it? I heard that when WordPress.com had it enabled, a few dozen posts came through it a day, all from few clients.

So realistically, AtomPub is essentially considered "end of life" to us. This plugin was merely done for backwards compatibility.

Closing this ticket as wontfix.