Wiki source code of Migration Guide To Nested Pages
Version 8.1 by Guillaume Delhumeau on 2016/03/10
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
 |
5.1 | 1 | {{toc/}} |
| |
3.1 | 2 | |
| |
3.5 | 3 | = A bit of history = |
| 4 | |||
| 5 | Before the introduction of the Nested Pages concept (in 7.2), the content in a wiki was organized like this: | ||
| |
5.1 | 6 | |
| |
3.5 | 7 | * we had some **Spaces**, that you can see as "folder" |
| 8 | * inside these spaces, we had **Pages**, where you were able to write some texts or store applications entries. | ||
| 9 | |||
| 10 | In that time, we cannot have spaces inside spaces, so all pages were placed inside a one-level space. The pages were identified like this: ##NameOfTheSpace.NameOfThePage##. | ||
| 11 | |||
| |
3.6 | 12 | Some pages were a bit special. They were the "home" page of a space. Every time a user wanted to reach a space without specifying a precise page name, she was redirected to that space home page. These pages were called "WebHome" (because at the very beginning of XWiki, "spaces" were called "web"). |
| |
3.5 | 13 | |
| 14 | == Parent/Child relationship == | ||
| 15 | |||
| |
3.7 | 16 | The user was able to specify a **parent** page for each page she had created. This parent could have been any page, for example the page ##Movies.ItsAWonderfulLife## could have ##Directors.FrankCapra## as parent. Then ##ItsAWonderfulLife## was listed as ##Child## of ##FrankCapra##. This relationship was displayed in the //breadcrumb// at the top of each page. The user was able to navigate through this //hierarchy//. |
| |
3.6 | 17 | |
| |
3.7 | 18 | Some applications used this parent/child relationship to organized their data. For them, this relationship is crucial. |
| 19 | |||
| |
3.8 | 20 | == The introduction of the Nested Pages concept == |
| 21 | |||
| 22 | In XWiki 7.2, due to frequent users demands, we have introduced the ability to create spaces under some other spaces. It's the **Nested Spaces** concept. We suddenly had the ability to create a hierarchy of spaces to organize our content. | ||
| 23 | |||
| 24 | But we have also found some issues. What if a space hold the same name then a page? Which entry should we render to the user when she reach an URL where 2 entities are matching? Moreover, does it make sense to have a difference between a space and a page? Why the pages cannot have sub-pages inside of them? | ||
| 25 | |||
| 26 | Then we have decided to switch to the **Nested Pages** concept. In theory, a page should now be able to have some sub-pages, because we don't need to have a distinct between a page and a space like we have between a file and a folder. | ||
| 27 | |||
| 28 | But this change was not possible to make on the API side because it would have required too much work that we could not afford at this time. So the decision was made to stick on the **Nested Spaces** implementation on the API (for now), but to propose **Nested Pages** in the UI. | ||
| 29 | |||
| 30 | How does it work? | ||
| 31 | |||
| 32 | Each time a user creates a page from the XWiki UI, she now actually creates a space (without knowing it ;)) with its ##WebHome## page. It means that any user-created page is called ##WebHome##. | ||
| 33 | |||
| 34 | Then, when the user wants to create a sub-page ##FrankCapra##Â in the page ##Directors.WebHome##, she actually creates a new space inside the space ##Directors## with its ##WebHome## page: ##Directors.FrankCapra.WebHome##. **That's the trick!** | ||
| 35 | |||
| 36 | The notion of space have been removed from the UI. It's not mentioned anywhere, anymore. Everything seems to work as if we were really creating sub-pages, even if we have created sub-spaces behind the scene. | ||
| 37 | |||
| 38 | {{info}} | ||
| 39 | That tricks should be temporary. When we will able the opportunity to rewrite the core model of XWiki, we will really implement the Nested Pages concept in the API. | ||
| 40 | {{/info}} | ||
| 41 | |||
| |
3.9 | 42 | Note that the user has still the ability to create pages that does not have the ##WebHome## name. As a consequence, such pages (that are not the WebHome of their space) cannot have sub-pages. That is why we call them **Terminal Pages**. |
| 43 | |||
| 44 | == Issue with the Parent/Child relationship == | ||
| 45 | |||
| |
3.11 | 46 | Now, it is clear that we have 2 different hierarchies in the wiki. One, made of sub-pages (sub-spaces in the reality), and one made with the old parent/child relationship. Then, clearly, it becomes confusing for the user. Which hierarchy should be displayed in the breadcrumb? What is the parent of page, the "container" page or the parent set in the field? |
| |
3.9 | 47 | |
| 48 | The choice have been made to drop the notion of parent/child relationship, since we can now really have children pages, implemented as sub-pages (with inherited rights, preferences, etc...). | ||
| 49 | |||
| 50 | It means that when the user wants to change the parent of a page, she actually needs to **move** this page under the new parent. | ||
| 51 | |||
| 52 | This concept are good in theory. But, how can we handle existing content when an XWiki upgrade is made? | ||
| 53 | |||
| |
3.1 | 54 | = Principle = |
| 55 | |||
| |
3.12 | 56 | The idea is not convert existing pages (which most of them are terminal) to ##WebHome## pages under their own space. We call this "convert terminal pages to nested pages". This allows you to create sub-pages under any converted pages, which is impossible while they were terminal. |
| |
1.2 | 57 | |
| |
3.12 | 58 | But that would be a shame to lose the parent/child relationships that the user have created between its pages. The user might want to preserve its hierarchies. She might still want to have ##FrankCapra## as parent of ##ItsAWonderfulLife##. |
| |
1.3 | 59 | |
| |
3.12 | 60 | To keep this information, the principle is to **move all the pages under their parents**, so the parent/child links **becomes a real hierarchy between pages**. |
| 61 | |||
| |
6.1 | 62 | {{image reference="example.svg" width="600"/}} |
| |
5.1 | 63 | |
| |
3.12 | 64 | To perform this conversion, we have developed an application called [[Nested Pages Migrator Application>>extensions:Extension.Nested Pages Migrator Application]]. |
| 65 | |||
| |
1.2 | 66 | = Fix the hierarchy = |
| 67 | |||
| |
7.1 | 68 | However, the current hierarchy may be messy. For example, some pages inside the space ##Proposal## could have ##Main.WebHome## as parent instead of ##Proposal.WebHome## which would be more logical. It happens when the user is invited to create pages in the space ##Proposal## directly from the main page (ex: http://design.xwiki.org/). |
| |
1.3 | 69 | |
| |
1.4 | 70 | It's important to identify such a case before applying the migration tool, because the tool won't be able to detect this kind of unwanted hierarchies. |
| 71 | |||
| 72 | In the previous example, the solution was to put manually the parent of all pages of the ##Proposal## space that had ##Main.WebHome## as parent, to ##Proposal.WebHome##. The following script have been used to migrate (ex: http://design.xwiki.org/): | ||
| 73 | |||
| 74 | {{code language="velocity"}} | ||
| |
2.1 | 75 | #set ($xwql = "where doc.space in ('Proposal', 'Design', 'Improvements') and doc.parent = 'Main.WebHome'") |
| 76 | #foreach($r in $services.query.xwql($xwql).execute()) | ||
| 77 | #set ($d = $xwiki.getDocument($r)) | ||
| 78 | #set ($discard = $d.setParent('Proposal.WebHome')) | ||
| 79 | #set ($discard = $d.save()) | ||
| 80 | * $r updated | ||
| 81 | #end | ||
| |
1.4 | 82 | {{/code}} |
| 83 | |||
| |
3.1 | 84 | = Install Nested Pages Migrator Application = |
| 85 | |||
| |
8.1 | 86 | To use the migrator application, you first need to upgrade your XWiki instance to a recent version (7.4.2+). Indeed, the migrator cannot create nested pages in an old XWiki instance where this concept did not exist! |
| 87 | |||
| 88 | {{warning}} | ||
| 89 | Then, we hardly recommend to make a backup of your instance and of your databases. The migrator will modify a lot of existing pages and these changes can not be reverted. If something goes wrong, the only solution will be to re-install your back-up. | ||
| 90 | {{/warning}} | ||
| 91 | |||
| 92 | {{warning}} | ||
| 93 | Users should be invited to not change the wiki content during the use of the migrator. How the migrator could convert pages that are currently edited? | ||
| 94 | {{/warning}} | ||
| 95 | |||
| 96 | {{warning}} | ||
| 97 | Nothing prevents an other administrator to run the migrator in the same time than you, which could have bad consequences (collisions of actions, etc...). You should make sure that you are the only person using this tool during all the time of the process. | ||
| 98 | {{/warning}} | ||
| 99 | |||
| |
3.1 | 100 | Go to the Extension Manager, and install [[Nested Pages Migrator Application>>extensions:Extension.Nested Pages Migrator Application]]. Then go to the page ##NestedPagesMigration.WebHome##. |
| |
8.1 | 101 | |
| 102 | You will find the following page: | ||
| 103 | |||
| 104 | image:Migrator1.png | ||
| 105 | |||
| 106 | There is 2 actions: | ||
| 107 | |||
| 108 | * **compute a plan**: the migration first generate a plan of actions to perform. You can see what the migrator proposes to do and disable some actions, or modify the options, for example. | ||
| 109 | * **execute the plan**: when a plan has been computed and if you agree with its content, you can execute the plan: the pages will be moved as proposed. | ||
| 110 | |||
| 111 | == Options == | ||
| 112 | |||
| 113 | But first, let's talk about the options. | ||
| 114 | |||
| 115 | |=Option|=Description|=Default value (recommended) | ||
| 116 | |**Exclude hidden pages**|Check this option if you want to exclude hidden pages, that usually contain technical data, from the migration.|**true** | ||
| 117 | |**Exclude pages having a class**|Check this option to not convert pages holding a class, because it can break applications based on these classes.|**true** | ||
| 118 | |**Do not move children**|Convert pages into Nested Pages (so they can have children) without moving them under their parent. The old hierarchy will not be preserved, but the rights and the preferences will remain the same.|**false** | ||
| 119 | |**Add redirection**|Add a redirection in the old location. So when the user will reach the old URL, she will be automatically redirected to the new one. It's good if you don't want to break bookmarks, for example.|**true** | ||
| 120 | |**Convert preferences**|By moving pages under their parents, the inherited preferences might change. If this option is enabled, the migrator will copy the old inherited preferences to the new location.|**true** | ||
| 121 | |**Convert rights**|By moving pages under their parents, the inherited rights might change. If this option is enabled, the migrator will try to set the same rights in the new location. | ||
| 122 | \\{{error}}Unfortunately, this operation is complex, and the current algorithm is buggy. This option should be used for debug reasons.{{/error}} | ||
| 123 | \\{{info}}You can still compute a plan with this option without executing it: the plan will list the locations were some rights will be modified, and then you should be able to find a solution for them manually.{{/info}} | ||
| 124 | \\|**false** | ||
| 125 | |**Exclude classes**|Exclude pages holding some objects.|A list of classes that we have identified to be excluded. It's not complete, you should add classes of your own applications! | ||
| 126 | |**Exclude pages**|Exclude a list of pages.|A list of pages that we have identified to be excluded. | ||
| 127 | |**Excluded spaces**|Exclude a list of spaces.|A list of spaces that we have identified to be excluded. | ||
| 128 | |**Included spaces**|Only pages containing in this list of spaces will be converted|empty | ||
| 129 | |||
| 130 | Note: you can select the classes to exclude by clicking on the "excluded classes" field: | ||
| 131 | |||
| 132 | image:excludedClasses.png | ||
| 133 | |||
| 134 | == Plan == | ||
| 135 | |||
| 136 | Once the options have been carefully set, you can start the computation of a plan. This operation usually lasts about 10 seconds, but it could be more depending of the number of the pages and the complexity of the preferences, rights, and hierarchies. The logs of the operation are displayed in the page. If error happens, you will have some error entries in the logs. | ||
| 137 | |||
| 138 | {{info}} | ||
| 139 | While the plan is computed, nothing is changed in your wiki. It's safe. | ||
| 140 | {{/info}} | ||
| 141 | |||
| 142 | This is what a plan looks like: | ||
| 143 | image:plan.png | ||
| 144 | |||
| 145 | A plan is a tree of actions to perform in order to convert your pages. The tree is ordered as the resulting hierarchy would look like. If you click on the strong page name of each action, you will open the tree and see the children actions. You can close the tree by clicking again the page name. | ||
| 146 | |||
| 147 | Each line displays the target document (the new location of the page) and the original page (the current location of the page). It is displayed like this: | ||
| 148 | |||
| 149 | {{code}} | ||
| 150 | NewLocation.WebHome from Old.Location | ||
| 151 | {{/code}} | ||
| 152 | |||
| 153 | You can click on the old location to open the page (in a new window). It could be useful to look at the page you are about to move. | ||
| 154 | |||
| 155 | Some actions have the mention: "(unchanged)". It means the page will not be moved. They are present in the tree only to display their children when some of them have changed. | ||
| 156 | |||
| 157 | Each action has a checkbox. Only checked actions will be perform. So if you notice some changes that you don't want to perform, you can easily uncheck them. When you uncheck an action, it also concern its children. But you can also select the children one by one if you need. | ||
| 158 | |||
| 159 | Other actions are available: | ||
| 160 | |||
| 161 | * **exclude page**: click on this button to add the page to the exclude list (in the options). The plan might be recomputed. | ||
| 162 | * **exclude space**: click on this button to add the space of that page to the exclude list (in the options). Then plan might be recomputed. | ||
| 163 | * **set parent**: click on this button to manually set a parent for that page. {{warning}}Note: this action will be performed immediately, not when the plan will be executed. It is a shortcut to help you changing the parent without going to the page.{{/warning}} | ||
| 164 | |||
| 165 | === Preferences === | ||
| 166 | |||
| 167 | Some actions can contains preferences changes. You can check or uncheck any change one by one. If they are checked, the preferences will be set to the new location. The original preference is also mentioned. When a preference line is present, it means that the preferences of the new location are not the same than the preferences of the old location. | ||
| 168 | |||
| 169 | You can either let the migrator set the new preferences according to the plan, or manually modify some preferences before or after the migration. In case you modify them before, you should restart the computation of the plan. | ||
| 170 | |||
| 171 | === Rights === | ||
| 172 | |||
| 173 | Same as preferences, but for rights. | ||
| 174 | |||
| 175 | {{error}} | ||
| 176 | Remember, the current application is buggy and you should not apply these changes! | ||
| 177 | {{/error}} | ||
| 178 | |||
| 179 | {{info}} | ||
| 180 | However, you can use this plan to identify where rights will be changed by the migration. Indeed, even if the proposed actions to fix them are bad, the algorithm is able to identify where rights problems happens. Save this list and you will be able to fix the rights issues by yourself after the migration. | ||
| 181 | {{/info}} | ||
| 182 | |||
| 183 | == Execute the plan == | ||
| 184 | |||
| 185 | When you are ready, you can execute the plan. | ||
| 186 | |||
| 187 | image:PlanExecuting.png | ||
| 188 | |||
| 189 | {{warning}} | ||
| 190 | Be patient. The process could be very long. It will use a lot of server resources, so we recommend to don't let users accessing the wiki during the process. (For example, you can temporary forbid remote connections to your servlet container and access XWiki through an SSH tunnel for yourself.) | ||
| 191 | |||
| 192 | Since all logs are displayed in the page, even the browser can became slow. We have experienced better performances using Chrome instead of Firefox. | ||
| 193 | |||
| 194 | Some OutOfMemory errors could happen. To avoid them, we recommend to give a lot of memory to your XWiki instance during the execution of the migration. | ||
| 195 | {{/warning}} | ||
| 196 | |||
| 197 | **We highly recommend to perform migration tests on a staging server before doing it on a production instance.** | ||
| 198 | |||
| 199 | = What else? = | ||
| 200 | |||
| 201 | Unfortunately, running the migrator is not enough. This is a list of actions that you need to perform: | ||
| 202 | |||
| 203 | * since the pages have been renamed, pages doing {{code language="plain"}}{{include reference="..."/}}{{/code}} or {{code language="plain"}}{{display reference="..."/}}{{/code}} might not work. You should identify them and fix them. | ||
| 204 | * if you use the "SpaceDocs" or the "Spaces" panels, you should replace them by "Navigation", "Siblings" and "Children Panels". | ||
| 205 | * Some existing code may break slightly and needs to be adapted: code taking some user input and creating Spaces based on that will most likely display "\.", "\:" and " | ||
| 206 | " in the UI. Unless the code already cleans the user input and removes ".", ":" and "\" characters. So for example if a user enter a Space name of "my.space": | ||
| 207 | ** before 7.2: the code would create/display a Space named "my.space" | ||
| 208 | ** after 7.2: the code will create/display a Space named "my\.space" | ||
| 209 | * Various XWiki API that used to return a space name have been returning a space reference string (i.e. list of spaces separated by dots and escaped "\.", "\:" and " | ||
| 210 | " characters). Code using those API may need to be updated. See XWiki 7.2 release notes for more details (this content could be copied in a section of the migration guide). |
