12. When I moved the pages from incubator to 
 I mostly used
scripts. But I had some problems for pages that contain lots of
attachments, like
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) <
valicac(a)gmail.com> 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/FlamingoAddMenuLocationIter…
 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:Skin4xMenus@menusMenuAnnotations.png", 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 <
 gdelhumeau(a)xwiki.com> 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 (gdelhumeau(a)xwiki.com)
 Research & Development Engineer at XWiki SAS
 Committer on the 
XWiki.org project
 _______________________________________________
 devs mailing list
 devs(a)xwiki.org
 
http://lists.xwiki.org/mailman/listinfo/devs