Serendipity Forums

I'm having trouble with trackbacks. I've never gone far into that realm, but I'm starting to get dragged into the '90s.

Anyway, nobody can make a trackback to me, even with the Spam Protector controls set to nothing bigger than "moderate". Trackbacks to archive entries work fine; trackbacks to permalink entries fail.

A little debugging shows that the the permalink entries fail because the URI doesn't match: it's looking for the RDF-supplied, archive URI, while it's actually using the permalink URI.

I can't duplicate the error because s9y (rightly) won't try to trackback after a failure (or success). How can I force that?

It seems to me that s9y should use both the archive and permalink in the RDF block, but I don't even know if that's possible.

Opinions?

Hi!

Are you talking about trackbacks from s9y to s9y? In the end only the real trackback URL matters, that comment.php?type=trackback&id=XXX link, which is unrelated to the permalink completely.

Permalinks only matter when trackbacking from serendipity, and that one needs to match the RDF permalink, that is true.

You can force resending trackbacks by setting your article to draft and then publish again.

It seems to me that s9y should use both the archive and permalink in the RDF block, but I don't even know if that's possible.

We can only have one RDF link there, this should be the URL that s9y uses in the overview to link to articles?

Regards,
Garvin

garvinhicking wrote:Are you talking about trackbacks from s9y to s9y? In the end only the real trackback URL matters, that comment.php?type=trackback&id=XXX link, which is unrelated to the permalink completely.

Permalinks only matter when trackbacking from serendipity, and that one needs to match the RDF permalink, that is true.

I'm not popular enough to have trackbacks outside the Serendipity world.

So when some non-s9y blog tries to trackback -- like if I pissed off some other blog's dev team of something -- they'll just use the RDF "trackback:ping" URL, and they won't do the same check against "dc:identifier" that s9y does? In that case, why do we do that check?

garvinhicking wrote:You can force resending trackbacks by setting your article to draft and then publish again.

I now remember you telling others about that. Sorry to make you repeat yourself, and thanks for the reminder.

garvinhicking wrote:We can only have one RDF link there, this should be the URL that s9y uses in the overview to link to articles?

My template uses the permalinks when they're available. I understand that's more SEO-friendly, and it'll save me trouble if I ever have to take the site static or something. I suppose I could modify the template to use the permalink in the "dc:identifier", too.

Hi!

So when some non-s9y blog tries to trackback -- like if I pissed off some other blog's dev team of something -- they'll just use the RDF "trackback:ping" URL, and they won't do the same check against "dc:identifier" that s9y does? In that case, why do we do that check?

Right. Or they use thelink "Unique trackback URI" that you see above your comment section.

s9y does that as a nice addon for the user so that links are autodetectefd and he does not need to search the links manually.

Regards,
Garvin

Sorry to reopen this; I hope I'm not being a pest, but I think we're considering two different questions, and some of my posts still can't be trackbacked.

I think s9y's ability to detect trackback URIs in an entry's text is an awesome thing, and I see why we would need it.

However, I wonder why we bother checking the trackback URL supplied in the referencing entry ($loc in serendipity_trackback_discover) against the RDF-supplied URL (parsed out of trackback target entry).

In my case, entries.tpl is setting the RDF dc:indentifier to $entry.rdf_ident. But in the overview page, it uses $entry.link as the href for the title link to the extended body. So when I use the $entry.link (the custom permalink) to reference the target entry, we compare the permalink to $entry.rdf_ident, then refuse to trackback because they don't match.

This explanation is rather convoluted, so here's a concrete example. Check out http://judebert.com/wasted_youth/permal ... ating.html. You'll see that the entry's title link is different from its RDF dc:identifier. I reference that entry from http://judebert.com/wasted_youth/permal ... lugin.html. So, when I save the Improved Karma Plugin, I'm expecting it to trackback to CSS Star Rating. That doesn't happen, because the link I used doesn't match the RDF link.

I'm assuming other blogs don't bother to perform this check (whether or not they scan the target article for an RDF URI) and complete the trackback even if the RDF URI doesn't match the permalink. (That may be an invalid assumption.)

I'm also assuming people are going to reference my entries by the links on the overview page, or in the browser location box when they read the entry. (These wind up being the same thing anyway.)

I expected the trackback to work from both s9y and other blogs.

I could modify the entries.tpl so the dc:identifier uses $entry.link instead, thus making the RDF and title link match. But I don't know how that will affect other blogs or trackbacking itself. I'm just not experienced in this social-networking stuff.

I could remove the check from the Serendipity code, but again, I'm just not all that familiar with what it's doing.

Suggestions?

garvinhicking wrote: You can force resending trackbacks by setting your article to draft and then publish again.

This didn't work for me; it resent the pings to ping services, though! I had to remove the trackbacks from the 'references' database table to get it to attempt a second time.

Hi!

Checking the RDF location against the URL is part of the Trackback API specification. It is used for blogs which contain multiple RDF parts where none of it matches, because trackbacks might have been sent to overview pages. There are blogs that do not have individual entry pages and trackbacking is only posssible when the posting's still on the overview page. Sounds wicked, but the check for validity is really there to ensure that trackbacks are not added to "bad" postings.

In your case, we would simply need to make sure that the RDF dc:identifier is set to the manual permalink that you set. I believe that this would need to be added to the custom_permalinks plugin, did you maybe have the time to check if it can set the required RDF-variable?

This didn't work for me; it resent the pings to ping services, though! I had to remove the trackbacks from the 'references' database table to get it to attempt a second time.

Actually, saving the article as draft should basically also dump the references table, I thought? Hm. Might be I confused that with sending pings. In your case it would then only be possible to modify/remove the trackbacks links from the posting, save it, then re-add the TB links to the posting adn save again...

Maybe also the "Manual Trackback" plugin allows to force resending trackbacks, I don't know?

Regards,
Garvin

garvinhicking wrote:Checking the RDF location against the URL is part of the Trackback API specification.

Well, then, that makes perfect sense.

garvinhicking wrote:In your case, we would simply need to make sure that the RDF dc:identifier is set to the manual permalink that you set. I believe that this would need to be added to the custom_permalinks plugin, did you maybe have the time to check if it can set the required RDF-variable?

So, just have the custom_permalinks plugin set the dc:identifier along with $entry.link? Sure, I can do that.

garvinhicking wrote:Actually, saving the article as draft should basically also dump the references table, I thought? Hm. Might be I confused that with sending pings. In your case it would then only be possible to modify/remove the trackbacks links from the posting, save it, then re-add the TB links to the posting adn save again...

Yeah, something weird is going on with previous trackbacks. It keeps all the trackbacks in the references table, and won't retry one -- even if I delete it, save the entry, and add it again. Very odd.

I just remove the entry from the table manually. Thank $DEITY for phpMyAdmin!

Thanks for the assistance, Garvin! I'll get that plugin fixed as soon as I have the time.

Ahh, crap. The permalink is an HTML absolute path; not an entire URL. I used parse_url on $serendipity['baseURL'] to prepend the scheme and hostname.

Tested, checked in, and ready to go.