Where is the “!– technorati tags start –” section generated?

A little more information would assist:

1) What version of WordPress?
2) Which theme are you using?
3) Are you using any plugins?

A link to your site would be helpful. The one linked from your name seems to be a Movable Type blog, which the W3C validator doesn’t seem to like at all….

I’m in the process of switching from Moveable Type; the WordPress blog I’m working on is here.

WordPress 2.0.2, default, Akismet

Ah, this also involves the ecto 2.4.1 client that I’m using to post. Here’s what’s failing to validate:

<p><!-- technorati tags start --><br />
<p style="text-align:right;font-size:10px;">Technorati Tags: <a href="https://www.technorati.com/tag/blog" rel="tag">blog</a></p>
<p><!-- technorati tags end -->
</p>

Clearly this is broken HTML as what’s expected is something along the lines of:

<!-- technorati tags start -->
<p style="text-align:right;font-size:10px;">Technorati Tags: <$TAGS$></p>
<!-- technorati tags end -->

At first I was inclined to blame ecto, but then again maybe WordPress is generating the <p> tags. More investigation required…

Watching the XML-RPC via tcpdump, ecto seems to be sending the right thing. The leading <p> (and <br />) along with the trailing <p> and </p> combo are apparently being added by WordPress.

Is this perhaps a result of the API I chose in the XML-RPC config?
I’m using the Moveable Type API, for no particular reason.

I am having the exact same problem. MarsEdit doesn’t have this problem at all, but it has a specific WordPress setting for the posting interface.

I can’t find the right combination of settings to make WordPress stop putting in the
but if MarsEdit can do it, it seems to me to be an ecto ‘feature’.

From watching the RPC sent by both MarsEdit and ecto, I’m pretty sure it’s mostly something that should be fixed on the WordPress side. Both MarsEdit and ecto are sending valid HTML via XML-RPC, but something’s causing WordPress to emit a <br /> instead of a </p> when it gets the post from ecto.

I’m a big fan of ‘be conservative in what you send and liberal in what you accept’. Which is to say that if you’re a server and if at all possible, you shouldn’t be depending on the client side to get it right.

As an experiment, I tried changing MarsEdit to use the Moveable Type API and it still works, so I don’t think the choice of API matters. In a similar vein, I tried the other APIs with ecto and they all fail too.

I have a workaround though. If I modify the template definition for ‘tags’ in ecto (“Weblog” > “Edit Templates…”) to be:

</p><p style="text-align:right;font-size:10px;">Technorati Tags: $tags$</p>

…which is to say, I force the </p> that I can see is missing when I do a View Source, I then get similar HTML and it passes the validator.

But the real problem remains in that what ecto is sending:

<!-- technorati tags start --><p style="text-align:right;font-size:10px;">Technorati Tags: <a href="https://www.technorati.com/tag/blog" rel="tag">blog</a></p><!-- technorati tags end -->

…ends up being served back as:

<p><!-- technorati tags start --><br />
<p style="text-align:right;font-size:10px;">Technorati Tags: <a href="https://www.technorati.com/tag/blog" rel="tag">blog</a></p>
<p><!-- technorati tags end -->
</p>

Perhaps I need to move this question to a different forum…

Ok. I had given up here and had written an AppleScript to do the tag code for me, but ecto sees this code and screws around with the categories list. I hate that.

So, I got the 5lb sledgehammer out and I now have code that will do this thing. derrell’s solution above doesn’t work for me for some reason.

If I use

</p><p style="text-align:right;font-size:10px;">Technorati Tags: $tags$</p>

as above, there is no change in what WordPress serves back.

However, if we use

</p>
<p style="text-align:right;font-size:10px;">Technorati Tags: $tags$</p>

all is well.

I get this as code served back from WP:

<p><!-- technorati tags start --></p>
<p style="text-align:right;font-size:10px;">Technorati Tags: <a href="https://www.technorati.com/tag/commercials" rel="tag">commercials</a>, <a href="https://www.technorati.com/tag/idiocy" rel="tag">idiocy</a>, <a href="https://www.technorati.com/tag/Mark Cuban" rel="tag">Mark Cuban</a>, <a href="https://www.technorati.com/tag/popular culture" rel="tag">popular culture</a>, <a href="https://www.technorati.com/tag/television" rel="tag">television</a></div>

<p><!-- technorati tags end -->
</p>'

and this is <strong>exactly</strong> right.

I still don't know why WP is dumping that
` in there, but it is gone now and the code is perfect.

Derell do you use flock as your blogging client by any chance? I used to have this problem with flock.

gall,

I think the bug is related to how WordPress is deciding when to omit <br />, <p>, and </p> tags when processing text. I’ve noticed it terminates the last paragraph differently, depending on whether you press return on the last line (in ecto) or not. If you don’t, you get a trailing <br />; if you do, you get a trailing </p>. Of course what’s following this is only ever an HTML comment and another <p>, so there’s a dangling open paragraph which the modified template closes. So what I see is either:

<br /> (WP) <!-- </p> (template)

…if I don’t press return before clicking ‘Publish’, or:

</p> (WP) <p> (WP) <!-- </p> (template)

…if I do press return before clicking ‘Publish’. I note that MarsEdit, in showing you the HTML explicitly in your edit buffer, essentially reformats the end of your text ensuring, by default, that WordPress will terminate the last paragraph with a </p>.

I think the bug is essentially that WordPress is not smart enough to ignore the HTML comment that forms the Technorati start tag. It’s acting like the comment might be more paragraph content. Are HTML comments part of an existing paragraph or are they just pragma? Beat’s me, but WordPress is clearly treating them as if they were potential paragraph content, and that’s what’s seemingly getting it into trouble: both because it’s emitting opening <p> tags it shouldn’t and because it’s leaving the comment open with a <br />.

bdsays,

No, this is all either ‘ecto’ or ‘MarsEdit’. I’m only vaguely aware of ‘flock’. But I think any client might run into this depending on the exact sequence they send to WordPress, since the extra tags which mess up the validator are being generated on the WordPress side. The HTML stream the clients are sending is valid.