And by "dingo" I mean "SharePoint's PRIME API via stsadm -o import/export", and by "baby", I mean "links to as-yet-nonexistent pages in a wiki library."
So, running that back, after using SharePoint's stsadm -o import/export, you'll notice broken links in your wiki library.
Wow, that sounded much more exciting with dingoes and babies.
Let's do this by example. Say, you're filling in content in a team knowledgebase, the one I like to call "the 2008 edition". You get a new one every year, but that's another topic, let's not get distracted.
So you're filling in the Widget page, and as you go, you realize you will also need to come back later and write up everything you know about Sprockets. So, in your page, as you are typing the word "Sprocket" you surround it with the standard wiki tags [[Sprocket]].
Up to this point everything is fine. You finish what you're doing on the Widget page, you log off, you go home. Tomorrow comes and you've forgotten about the poor lonely Sprocket page. And the day after arrives, and the day after, and so on, and poor [[Sprocket]] remains a link to an as-yet-nonexistent page.
So that's what they are.
I'll be honest, you'll probably never encounter this problem. But: if you're migrating content using SharePoint's stsadm -o export and then stsadm -o import, your "babies" will be "stolen" from you. Your [[Sprocket]] link will be stolen and replaced with some abominable hardcoded anchor tag that points to an error page.
So be on the lookout: wikis don't move nicely via stsadm -o import/export.
b, blockquote@cite, em, i, strike, strong, sub, sup, u
Powered by: newtelligence dasBlog 2.2.8279.16125
The opinions expressed herein are my own personal opinions and do not represent
my employer's view in any way.
© Copyright 2013, Peter Seale