Just a reminder that all published and linked subject guides on libguides will have what they call a “Friendly url”, which should be used when referring by url to all libguide homepages. This friendly url consists of our base libguides url – http://canterbury.libguides.com/ followed by the the course code letters eg http://canterbury.libguides.com/educ. This should be easy for users to remember and relatively easy to deduce what the url of another subject guide would be.
Where there isn’t an obvious course code, or there could be more than one course code used we’ve tried to assign intuitive “friendly urls” eg http://canterbury.libguides.com/esol.
Unfortunately these only seem to work for the homepage – any other tabs require the use of the more complex url in the format http://canterbury.libguides.com/content.php?pid=[number]&sid=[number].
Please be aware that published subject guides will always have the string “content.php” in the url and not aecontent.php which is the url of the author’s edit screen. You should never give out a url containing the string “aecontent.php”. Conversely, if the guide isn’t published, a url containing “content.php” will return an error message to the user.
If you’ve got any questions about the url to use, please contact Library IT.
Catherine
Catherine, when linking between pages on our LibGuides I’d been copying and pasting the link from inside the edit mode – which means that all (or at least most) of the internal links in the guide will have "aecontent.php". (Eg on http://canterbury.libguides… )
We can watch out for that in future but is there any way to automate fixing that for stuff that’s already published?
Deborah
If you use the aecontent.php as a link, libguides will send the link to the correct page and the url it displays will have content.php in it, so you don’t need to worry about existing links. Just don’t advertise links with the aecontent.php part in the url.
Libguides have found and fixed links across our site in the past, but I’m not sure if they can distinguish between published and unpublished sites for this purpose. I’ll ask.
I think that the publishing process should convert links with aecontent, so I’ll suggest that as well.
Catherine
What was wrong with the old URLs?
e.g.
http://library.canterbury.a…
Seemed a bit more obvious to me and our users have been told them for more than a year now.
Also why should the URL change just because the tool we use to create the same content does?
I was going to say the old urls redirected but it looks like they’re still redirecting to ezproxy. Can Library IT fix this?
Deborah
This should now be fixed – but you may need to clear your cache.
Thanks for noticing this, Peter
The "old URLs" have been redirected as Deborah pointed out – at the homepage level. Which is why the above posting was made in the first place to remind people about the friendly urls, so that the redirects would work, and so users won’t need to learn a new url.
So http://library.canterbury.a… will redirect to http://canterbury.libguides…
But the libguides "friendly urls" only work at the homepage level, which means you can’t link to a specific tab within a libguide using the friendly url. An internal link within libguides has to use the more complex url.
Catherine