Hi! Copy / Move / Rename in XWiki 11.0.x series caused pages to be misnamed and fall out of the viewable XWiki namespace. A few screenshots will explain this more clearly.
Notice that the operation flattened the hierarchy into “Committess/Group Process/Minutes/2019”. This is represented in the navigator:
The 11.1 code path seems to have fixed this issue. However, I am now left with pages that are incorrectly indexed, in a way that XWiki cannot render, so I cannot rescue those pages by moving them or delete them.
I am guessing I am going to have to do some raw SQL to fix this, could you please point me in the right direction as to how to remediate this issue? Thanks!
Hmm I don’t recall any problem in XWiki about this but I could have missed it. Would you have a jira issue to point to? I’m curious to see it because it seems like a very important issue if one exists that can break page locations.
The only related problem I know is when Tomcat is misconfigured and not supporting the / and \ characters in URLs.
No, you should never do that or you have a very very high chance of breaking XWiki
The pages you mentioned exist locally and can be accessed. You just need to find their names/URLs to rename them.
You could check the Index page to see all pages in your wiki, for example.
I do not have a JIRA issue, I only have empirical observations. I tested the operation at 11.0.3 (? I think) and it still existed; I tested again after upgrading to 11.1 and the issue was gone.
These are the listings on the Page Index screen. Clicking the page title or the actions for these pages leads to a completely blank screen; no in-app operation seems possible. Any thoughts or suggestions?
Well, since I did not get any assistance on this issue, this is the route I took. I noticed this issue right away when it started happening, so I only really had one “lost” page. I was able to delete entries in xwikispace and xwikidoc tables that had “/” instead of “.” as a separator in the XWD_FULLNAME or XWS_REFERENCE. I copied the content from the “lost” page and re-created it, I was not able to figure out how to recover pages that we affected by this bug.
Hopefully no one else encountered this issue, but if so, this was my fix. I hope it works for others.
Interesting, that would have been a helpful reference earlier.
Tomcat completely freaks out when there’s a %2F or %5C in URLs and it’s not something that can be changed in XWiki.
So just to be clear: even though XWiki consistently uses “.” as space / page name separators, if Tomcat is set to “not freak out” over slashes, XWiki will use slashes as the separator? Why did it start saving pages with slashes as the separator to begin with? Now I am confused if what I encountered was a bug or expected behavior that is meant to be solved by this Tomcat config change.
