Thousands of undefined pages from prior use of camelcase option

[Dave Drexler]

Hi folks - we used to use the old Confluence CamelCase option, but turned it off a couple of years ago. The CamelCase option created thousands of Undefined Pages in our instance, and those remained even after we turned off the feature.

Now we're upgrading from v3.5 to v5.5, and reviewing what's being brought across. I was surprised to see that the thousands of Undefined Pages are still there; I figured (hoped?) this would be something that was cleaned up in the migration scripts.

Has anyone else faced this issue? Any clever ways of cleaning up this mess?

[Ryan Goodwin]

What type of upgrade have you tried? I'd be interested to see if it brought over the pages in an XML backup/restore upgrade path.

If yes, I'd be inclined to say they are going to stick around. The best option is probably going to be a manual solution...

[Dave Drexler]

Hi - the upgrade is being handled for us by our hosting company (Contegix), so I'm not sure how to answer your question. I assume they're going through the best practices established for the jumps from v3 to v4 to v5.

[Ryan Goodwin]

I imagine they are doing in place upgrades then. There are likely a couple options to clean up the undefined pages - manually via database queries or manually via modifying an xml backup.

When you say "undefined pages" - can you elaborate? How are you identifying these pages? In the UI? or in the database? What constitutes a page being undefined?

[Dave Drexler]

I'm referring to all the pages shown in each space, via

<wikiURL>/pages/listundefinedpages.action?key=<xyz>

In the GUI space admin screens.