format_xml_elements() does not allow unencoded values

@maciej.zgadzaj thanks, I like your solution. I'm attaching the patch for drupal 7.x in case anyone finds it useful.

I've been using this for 5 months now, and it works perfectly. I'm still re-applying it after every core update for D7, so it would be nice if it could be committed.

#2 works for me

We killed that in the meantime.

how and when was this solved for d7?

Reopening for 7.x, someone should upload #2 as a .patch file for it to be tested.

Here's the patch from #2.

Successfully skip item value encoding by using the encoded property!

The patch looks good, but I think the new option definitely needs to be mentioned in the function documentation. (Especially since it has security implications - we need to be really clear in the documentation when it should/shouldn't be used.)

Here's the patch with updated funcion documentation.

This has been out there for a year and a half, and it now has function documentation as well as a test. Can we please get this committed so that I don't have to manually re-add this patch after every update?

+++ b/includes/common.inc
@@ -1767,9 +1767,13 @@ function format_rss_item($title, $link, $description, $args = array()) {
+ * entity-encoded or CDATA-escaped (see issue #2393461).

We usually don't reference issues in code in D7 - except for @todo's.

Lets also add something like:

"Only use this option if you have already escaped the data as not doing so has security implications."

Removed the issue reference as it's not a common use in drupal 7 (see #16) and added the comment suggestion by Fabianx.

RTBC, Stefan will need to commit this.

David, are you happy with docs here?

Mostly looks good, but the new sentence should be part of the previous paragraph - otherwise it's not clear what it refers to.

Also, if you CDATA-escape untrusted input, that doesn't make it safe (at least not when done naively, and I'm not aware of any function in Drupal or PHP that helps you do CDATA-escaping safely).

So thinking about this a bit more... maybe we should be safe and always just recommend entity-encoding in the case where you're working with untrusted user input? (My understanding is that they are basically interchangeable anyway.)

Like the attached, in other words.

Saving issue credits - I think there is a bug on drupal.org that sometimes makes them get out of whack.

I think the current wording makes sense...

Committed and pushed to 7.x, thanks!

Wrong changelog.

Thanks @nevergone

@stefan just noticed a small typo in the above patch, there are two "a":

+- Added a a new option to format_xml_elements() to allow for already encoded

Thanks for getting this done and committed, everyone. This will be a huge headache saver for me.