The blog link of 17th July has been updated  with a change of anchor name to make it reflect the current title of the blog post:

"HackerSpace Challenge - Final Blog Post" [Leeds]

Note that the actual URL of the post remains unchanged, and preserves the previous (apparently incorrect) title:

"hackerspace-challenge--leeds-only-pru-can-make-the-leds-bright"

Judging by the final comments on that blog post, it's possible that there was a change of post title on 4th September, although it's hard to tell.

The blog link of 17th July has been updated  with a change of anchor name to make it reflect the current title of the blog post:

"HackerSpace Challenge - Final Blog Post" [Leeds]

Note that the actual URL of the post remains unchanged, and preserves the previous (apparently incorrect) title:

"hackerspace-challenge--leeds-only-pru-can-make-the-leds-bright"

Judging by the final comments on that blog post, it's possible that there was a change of post title on 4th September, although it's hard to tell.

both those URLs in the above post get 404 due to missing "/community", although the main blog has it right.

Thank coder27, it's some kind of Jive bug that modifies the link URLs after they are pasted in correctly.  (I don't modify any URLs by hand, but merely paste them from the address field of another tab that I've opened on the blog post.)

The bug is very wierd, in that I've only managed to defeat it in post #38 by enclosing the 2nd anchor text in quotes.  Without those quotes, the second link always ends up pointing to an invalid page no matter how many times I paste the correct URL into the URL box.

you should probably "open a ticket" in the Feedback & Support group if you

can consistently make it fail.  I've seen it happen a lot, but not to myself AFAIK.

After the imminent Jive upgrade, I'll try removing the quotes and seeing if the bug remains.  If it's still with us then, I'll raise an F&S ticket, since it's totally repeatable in #38.

(I don't modify any URLs by hand, but merely paste them from the address field of another tab that I've opened on the blog post.)

The anchor text and the URL used as a hyperlink are two different things, as you know.

In my list of links opening article, I normally paste the actual URL of the blog post once into the article, remove everything but the trailing post's filename to leave just a readable title line of plain text, and then use that plain text as an anchor for the same URL pasted a second time into the URL box provided by the editor (not into the article form).  As a result, I never have to type in nor adjust blog URLs manually, nor do I have to type in the title of each blog post.

In post #38, because I was explaining the manual edit that I made retrospectively to the anchor text in the leading article, I intentionally broke the exact correspondance between the anchor text and the trailing part of the blog post's URL:

1. In the leading article, the anchor text is now "hackerspace-challenge--leeds-final-blog-post", which bears no resemblance to the actual URL of that blog post but does usefully reflect its current visible title.
2. In #38, the first link has the anchor text "HackerSpace Challenge - Final Blog Post" which does not reflect the structure of the URL but is the current visible title of the blog post mentioned in point 1.
3. In #38, the second link has the anchor text "hackerspace-challenge--leeds-only-pru-can-make-the-leds-bright" which is the original anchor text mentioned in point 1, now modified in the leading article.

Fortunately none of this messing around is usually needed, as blog URLs usually reflect blog post titles.  I'm not entirely sure what happened to break this correspondance for the post of 17 July.  Perhaps a poor  choice of blog post name was made initially, and was subsequently corrected by the author on 4th September?  Or was this some kind of blog admin fault?

====

PS.  The key to success for all matters related to pasting on Element14 is to always paste text first into a plain ASCII window of some kind (eg. to the xterm command line or into vi), then re-select this plain text so that all the original formatting is lost, and only then to paste this into an Element14 form.  When this workflow is not used, E14 forum posts look like "Desktop Publishing" from the late 80's or like ransom notes assembled by cutting out and glueing down words from miscellaneous paper sources, with typefaces and font sizes all over the place.  The most generous adjective for the resulting mess is "funny", but I can think of several less generous terms that are highly appropriate.

(Ideally the "Remove formatting" button in the E14 editor should toggle ON/OFF rather than only operating on a selection.  Pasting marked up text would then be impossible unless you specifically want to emulate a ransom note, which in my case would be never.  Maybe the Jive upgrade will feature this.)