12. When I moved the pages from incubator to design.xwiki.org I mostly used scripts. But I had some problems for pages that contain lots of attachments, like http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4x#Attachments Those pages I needed to import with Large import or something, and some even recreated manually. To be honest I don't quite remember, but just be careful that the migrator needs to consider cases when pages cannot be renamed / deleted / etc.
Thanks, Caty On Tue, Jan 12, 2016 at 7:26 PM, Ecaterina Moraru (Valica) < [email protected]> wrote: > Hi, > > The following ideas are about the Parent/Children relation (UC1): > > For example a copy of design.xwiki.org could be used as a test example > for this kind of migration. design.xwiki.org is using a very basic > application > http://extensions.xwiki.org/xwiki/bin/view/Extension/Proposal+Application > that at its core uses the Parent/Child relation in order to list in a > livetable the children of a particular proposal. > > The hierarchy contains pages from 2 spaces: Improvements (from the old > application from incubator.myxwiki.org) and Proposal. > > Sometimes the hierarchy can go to more than 6 levels, examples: > http://design.xwiki.org/xwiki/bin/view/Proposal/FlamingoAddMenuLocationIterations > or http://design.xwiki.org/xwiki/bin/view/Proposal/XWiki+Icon+Set > > But sometimes the hierarchy mixes pages from the different spaces, > example: > http://design.xwiki.org/xwiki/bin/view/Proposal/PanelsImprovements (where > Flamingo comes from Improvements space, while the others are from Proposal > space). > > User expectations: > 1. I would really like that after the migration the hierarchy to remain > the same a.k.a the breadcrumb to be unchanged. The breadcrumb navigation > stays at the core of this application. I give more importance to the Page > Title than the Page Name, so I would be ok for the new pages to be copied / > created using the title and discard the page name. > 2. But I sometimes referenciate in the content of some proposals other > pages using the page name references. So what will happen to those links? > Can we auto-update them inside the content with the new pages (backlinks)? > 3. in your UC7: Bookmarks should not be broken after the migration: how > can we achieve this? Are the page aliases a solution? Everywhere on jira > there are references with links towards the design.xwiki.org proposals. > For example, when I moved the app from incubator.myxwiki.org to > design.xwiki.org I replaced the content of the page with a Moved type > message, example > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrg . This > could be a solution if we don't provide page aliases or redirects, although > might not be very efficient. > 4. In order to achieve the hierarchy this means that terminal pages need > to be transformed into spaces? > 5. In my proposals I use the {{gallery}} macro that uses references like > "image:loginDesktopSnapshotAnnotations.png" or > "image:[email protected]", etc. How will the images be > affected? > 6. Those long URL will look kind of ugly - so again page aliases would be > great. But not sure how we will manage them. Do we allow multiple aliases > to be created and used, or just 1? > 7. What is the complexity of the changes I need to add to the Proposal App > in order to continue working as before? Do we provide such documentation > for the users? > 8. The livetable was using this in order to list the children > #set ($discard = $options.put('extraParams', "& > parent=${doc.fullName}")) > and > #set ($importPages = $xwiki.queryManager.xwql("where > doc.parent='$doc'").execute()) > 9. If the user might start and finish the migration but then he will > discover that everything looks bad, what can he do? A best practice would > be for him to make a backup before doing the migration, but can't we make > one automatically? > 10. After the migration what will happen if an user goes to the 'Recycle > Bin' and restores a page from "Deleted Documents" or "Deleted Attachments"? > 11. Currently there are 1246 pages on the Design wiki. Improvements space > contains 317 pages, while Proposal space contains 256 pages. Apparently > there are other spaces that contain user generated content like Design, > Tech, Standard, etc spaces. It would be great if the migrator could list > user created pages when the migrator ask what pages needs to be migrated > (UC3). But that list should eliminate default pages and applications pages > (technical). Also maybe the user wants to migrate the hierarchy just for > some pages (just the spaces Proposal and Improvements). > > I know maybe the design.xwiki.org is not the best or the most complex > example, but as an user I am quite concerned with what will happen to the > hierarchy we've created over the years and I'm sure every user thinks the > same about their content. > > Thanks, > Caty > > > > On Tue, Jan 12, 2016 at 6:37 PM, Guillaume "Louis-Marie" Delhumeau < > [email protected]> wrote: > >> Hello everyone. >> >> I am working on a tool to help the user migrating from an XWiki instance >> without the Nested Pages feature to a new version (7.4.x) handling it. >> >> This tool would be an extension that the administrator can install and >> execute *after* the XWiki upgrade have been done. After its execution, >> users should be able to create children to every existing pages (that was >> previously terminal, obviously). But the old hierarchy based on the >> parent/child relationship, and all the preferences and rights, should be >> preserved. The URL should not be broken neither. >> >> I have started a design document with the use-cases I had in mind. I've >> also suggested some implementations and drew some mock-ups. The results is >> here: >> http://design.xwiki.org/xwiki/bin/view/Proposal/UpgradeToNestedPages >> >> I've started this document before talking here in order to not come with >> nothing, but feel free to add other use-cases, ideas, and edge-cases that >> I >> haven't listed. We should also identify any blocking point from XWiki >> Enterprise that we could fix in a 7.4.x version. >> >> Do you have any question in mind that we should discuss here? Do you have >> an opinion on this? >> >> You help is warmly welcome, >> >> Thanks, >> -- >> Guillaume Delhumeau ([email protected]) >> Research & Development Engineer at XWiki SAS >> Committer on the XWiki.org project >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
