I’ve linked to observations here from my blog. I had been using the truncated form of the link - i.e. with the observation number, but without the text on the end. WordPress had been rendering these as struckthrough. I investigated this morning, and found that WordPress was classifying these as broken links (even though they work); with that understanding I’ve discovered by adding the text at the end of the link WordPress treats them as working links.
My guess is that the server returns a different status when it performs a redirect than for a direct link to a page, and WordPress treats that as indication of a broken link. I don’t know whether to point the finger at iSpot, at WordPress, or at myself, but I’m mentioning the issue so that people know that it exists.
If you take the title off the end of the URL you must leave the trailing slash in place after the number - or the link will no longer work.
The trailing slash was in place, and the links were working; the issue was that WordPress was rendering them as broken links.
Interesting - wonder why?
It a long time since I looked at how the HTTP protocol worked, but if my memory serves me correctly a client can either ask for the page (HTTP not HTML) headers, or for both the headers and body. For what WordPress is doing the sensible thing would be to ask for the headers. If iSpot is returning a response code in the 300 (redirection) range then I’d look sideways at WordPress. If iSpot is returning a reponse in the 400 or 500 range I’d wonder why it is doing that. There’s also the possibility that CloudFlare is putting its oar in.
But I guess that youall have more serious issues to worry about.
