Atom feed contradicts itself

[link92]

<summary type="text/plain" mode="escaped">

From a parser POV, what does this mean? Normally you only escape the content when you have HTML content, yet what we're given in the type attribute says it's text/plain. Since both are MAY [RFC2119] in Atom 0.3, many (if not all parsers) will just take one attribute and ignore the other. Fx 2.0 just treats it as unescaped plain text.

[shorty114]

It would make sense that once it's escaped, it can be used as text/plain. But maybe do type="text/html" instead?

[shorty114]

I would be glad to do a patch but any devs have an opinion?

[matt]

Since our feeds currently work everywhere, I'm not inclined to change this.

[link92]

Replying to matt:

Since our feeds currently work everywhere, I'm not inclined to change this.

Huh? As I said in the report, it breaks in Fx 2.0.

[link92]

<summary type="text/plain" mode="escaped"><![CDATA[This &amp;amp; this]]></summary>

Will come out of almost every parser as meaning a summary with contents of "This & this" which is plain text.

<summary type="text/plain" mode="escaped">This &amp;amp; this</summary>

Will come out of almost every parser as meaning a summary with contents of "This & this" which is plain text.

The real issue is that we have text content which is escaped (which under the Atom 0.3 spec means nothing more than just follow the normal XML rules (eg. remove entities in PCDATA, but not CDATA)), and that it is plain text and therefore the data is the raw content after being escaped. The two options for this are to:

1. Remove the CDATA section, so the entities are decoded by the parser,
2. Change the MIME type to text/html, so it's parsed by an HTML parser.

[link92]

Replying to matt:

Since our feeds currently work everywhere, I'm not inclined to change this.

Also, what feed parsers does it work in (most feed parsers just show the content, not the summary, so it's futile naming any like that)? Anything that it works in is horribly broken.

[link92]

I'm reopening this on grounds that nobody has questioned what I said above (and that therefore it still exists).

[link92]

Change the MIME type of the <summary> to bloginfo('html_type') - patch should apply against 2.1 and 2.0

[matt]

(In [4688]) Summaries in Atom should properly describe their content, fixes #3377. Hat tip: link92.

[markjaquith]

Let's let this sit in 2.1 for a bit

[link92]

This is now broken again in trunk: <summary> isn't allowed to have a MIME type on @type (in Atom 1.0 only <atom:content>'s @type allows a MIME type). The best thing to do is probably just hardcode @type="html".

[link92]

I might add that due to it being a MIME type, it now defaults to "text", which brings us back to where this bug started.

[foolswisdom]

link92, the patch above if applied for 2.0.8 would not have the problems you describe in the two comments above? 2.1 currently is broken in this way or only trunk?

For my brains sake would it makes sense to split off new bugs based on the modified implimentation in 2.1 or trunk? Please.

[link92]

2.1 fixes this bug. 2.0 still has this bug. 2.2 has the problems in my last two comments.

[markjaquith]

link92, please open a separate ticket for the issue in 2.2 (which now has Atom 1.0)

2.1 just came out, so this needs to sit there until 2.0.9

[Nazgul]

2.0.9 is out, so bumping the milestone to 2.0.10.

[link92]

Surely this has sat in 2.1 for long enough?

[rubys]

This defect was fixed in WordPress 2.2, as a byproduct of supporting Atom 1.0.

[foolswisdom]

Re-opening as this ticket was/is targetted at the long term maintenance 2.0.x branch.

[rubys]

re: re-opening, fair enough; though as one of the authors of that spec, the problem isn't that Wordpress produced an invalid feed, it is that that version of the spec itself was ambiguous.

[markjaquith]

In that case, we have even less reason to change this. It's fairly hard for us to get changes like this into the 2.0.x branch because of pressure from the Debian side to limit it to security/stability issues.

_This PR is a refresh of #3377 to improve the tests prior to 6.2 Beta 1_

Adds a word_count_type property, so that it does not need to be translated separately across multiple projects.

• New property: WP_Locale::word_count_type.
• New method: WP_Locale::get_word_count_type().
• New function: wp_get_word_count_type() as a wrapper for WP_Locale::get_word_count_type().
• All _x( 'words', 'Word count type. Do not translate!' ) strings have been replaced with a call to wp_get_word_count_type().

committed in https://core.trac.wordpress.org/changeset/55279