XMLRPC, Ecto 2, and linebreaks

Short answer: No. There’s no setting or plugin to make WordPress not modify your post to at least some degree. And any setting along these lines would be universal, the XML entry point is simply passing it along to the rest of the system normally.

Long answer: You could dive into the guts of the code and probably make it happen. I’ve traced through some of that code, but it’s hideously complicated.

Hmmm: thanks Otto42. But that seems like somewhat poor design: if the API says “don’t filter this to add further formatting like <br /> tags”, you would expect WordPress to respect that.

The strange thing, to me at least- I can go into the WordPress post editor itself and remove those extraneous <br />‘s, and that works (I.E.: It doesn’t try to stick them back in). So what part of the filtering process is putting them there in the first place?

Make a new post in WordPress. Type some stuff, press enter. Type some more stuff, press enter. Post it. Go look again. See the br’s?

Single newline’s become br’s. Double newlines get the previous paragraph wrapped in a p and /p.

Otto, I’m looking at a post I created in WordPress 2.0.1 right now. There are no <br /> tags in the source post when I edit it. None. Zip. Nada.

I can edit it all I want- the only breaks occur when I create a paragraph break.

The <br /> tags I am describing in this post are added by WordPress to the body of a post when that post is created and submitted (without linefeeds). WordPress adds them. I delete them manually with the WordPress editor. They are gone forever. I can edit the post fifty times and move text around whereever I want, and they won’t reappear unless I manually insert them.

Since WordPress 2.01 seems to feel no compunction to add linefeeds (<br /> tags) to my posts when I edit them within WordPress itself, why does it do so when the exact same content is posted via the API?

Upon further examination of the WordPress behavior, it is filtering/parsing ASCII newlines sent via the API into <BR /> tags. I think I sort of see your point, Otto: basically, WordPress is treating content received via the API as if it were identical to content *typed* in via the WordPress editor. What it *should* be doing it treating content via the API as raw HTML- the same as using the WordPress editor and clicking on the “HTML view” icon. At least when the API attribute “mt_convert_breaks” is set to false/no value.

I wouldn’t want to alter the behavior of the WordPress editor UI, but Wwitespace such as newlines should be ignored by the API. If this behavior is deep within the WordPress code, then I guess it needs to be fixed by “experts”.

Hi Otto,

I’ve found out what you mean, as I’ve been wondering about the same thing too. (It was an link with linebreaks, which didn’t worked)

In the webpage I have found these <br />‘s, but not
in the editor. I’ve been curios and had a look into the
database table, if the text is stored with <br />
element
It’s not.

Then I have a looked into the output functions and, yes I think I’ve found it. In ‘functions-formatting.php’. I
theorize that the breaks will be added in this file.

Did you try <pre> tags? XHTML uses preserve white space characters and avoids insertion of <br /> tags.

Did you try <pre> tags? XHTML uses these to preserve white space characters and avoids insertion of <br /> tags.