This is the multi-page printable view of this section. Click here to print.
WikiPakk Topics
1 - Scripting the Page Hierarchy
WikiPakk shows SharePoint pages in a tree-like manner; pages have a parent-child relationship.
If you create SharePoint modern pages “by script” (for example via PowerShell or Power Automate Flow), you might want to set their hierarchical relationship as well.
This article explains where WikiPakk gets its hierarchy information from, so you can potentially create it in an automated fashion.
Where Does WikiPakk Get Its Hierarchy Information From?
There are two hierarchy sources for WikiPakk:
- the Site Pages library
- the WikiTraccsPageTree hierarchy list, which is hidden
Hierarchy information from the WikiTraccsPageTree list overrides hierarchy information from the Site Pages library.
Site Pages Library
The first (of two) hierarchy sources for WikiPakk is the Site Pages library. WikiPakk looks for specific columns and - if it finds those - uses hierarchy information it finds there.
Note
Did you migrate pages from Confluence to a SharePoint site using WikiTraccs? Then all columns described here are present in all migration target sites. Plus all hierarchy-related metadata.WikiTraccs-Owned Columns
Do not create those columns yourself. Rather use WikiTraccs to create the columns for you by starting a (dummy) migration to the target site. WikiTraccs prepares the site and makes sure everything is set up correctly.| Display Name | Internal Name | Type | Notes | Sample Value |
|---|---|---|---|---|
| Confluence: Title (WikiTraccs) | WT_In_CfTitle | Single line of text | Original Confluence page title; WikiPakk does not use this value, unless the SharePoint-native Title field is empty | Demo Page |
| Confluence: Id (WikiTraccs) | WT_In_CfContentId | Single line of text | Confluence page ID | 118587460 |
| Confluence: Parent Id (WikiTraccs) | WT_In_CfParentId | Single line of text | ID of parent page (0 for the top-most pages) | 118587459 |
| Confluence: Sibling Order (WikiTraccs) | WT_In_CfSiblingOrder | Number | Order in the page tree, lower numbers come first | 1 |
When those columns are not present, WikiPakk continues to look at the second hierarchy source.
Hierarchy List
The second (of two) hierarchy sources for WikiPakk is the WikiTraccsPageTree hierarchy list.
Note
The list is called WikiTraccsPageTree for historical reasons.The hierarchy list is created automatically in a SharePoint site when the WikiPakk app is added to the site. Removing the WikiPakk app from a site does not delete the list, so you can re-add the app and hierarchy data will still be there.
Every site WikiPakk has been added to will contain the hierarchy list.
The list is hidden and thus not visible in the Site Contents view. But the list can be accessed by using its URL Lists/WikiTraccsPageTree, for example https://COMPANY.sharepoint.com/sites/SITENAME/Lists/WikiTraccsPageTree.
| Display Name | Internal Name | Type | Notes | Sample Value |
|---|---|---|---|---|
| Title | Title | Single line of text | Settings in internal JSON format, e.g. forced alphabetic order for children; leave empty | |
| WtPId | WtPId | Number | Item ID of SharePoint page (ID column in Site Pages library) | 123 |
| WtPPId | WtPPId | Number | Item ID of parent SharePoint page (0 for root pages) (ID column in Site Pages library) | 0 |
| WtO | WtO | Number | Internal use; leave empty | |
| WtH | WtH | Number | Internal hierarchy source; must be 3 | 3 |
| WtR | WtR | Single line of text | Rank of items in internal format; leave empty |
The list is initially empty. When users move tree nodes around, either in the page tree panel or the WikiPakk page tree editor web part, items will be added or (if already existing) modified.
Hierarchy items in the hierarchy list override hierarchy information from the Site Pages library.
Note: If you screw up the hierarchy, the tree is capable of crazy things, like showing duplicate subtrees. Please take care.
Sample Script
The Wiki Transformation Project library contains a PowerShell script that manipulates the hierarchy both in the Site Pages library and in the hierarchy list: CreateHierarchy.ps1. This can serve as sample.
2 - Inaccessible Pages
You might see nodes in the tree that say inaccessible page, like here with inaccessible page 47:
Where do they come from?
There are two sources: deleted pages and pages that the current user is not allowed to see.
Deleted pages
Deleting pages can make tree nodes show the inaccessible page placeholder.
Consider the following page tree:
Note the Projects page that has two child pages: Project Bar and Project Foo.
Now we delete the Projects page (that has the SharePoint item ID 47):
The tree now cannot get information about that page anymore. However, it still knows where the page used to be in the hierarchy of pages.
To maintain the configured hierarchy of pages, the tree shows a placeholder inaccessible page 47 where the page used to be:
The child pages are still being shown at the correct position.
If we restore the Projects page from the recycle bin the tree will again show its title and link to the page:
Note that WikiPakk cannot know if a page has been deleted or if a page is not accessible due to missing permissions.
Pages with unique permissions
Consider the following page tree:
What happens if a user cannot access the Projects page? This is the case when the page has its permission hierarchy broken, unique permissions set, and the current user is not allowed to view the page.
For the current user, the tree will look like this:
For other users, the tree will look differently, depending on their access level.
Note that WikiPakk cannot know if a page is not accessible due to missing permissions or if it has been deleted.
SharePoint works differently than Confluence
If you know the page tree from Atlassian Confluence, you won’t know this issue of inaccessible pages.
In Confluence, if you are not permitted to access a page, you also cannot access its child pages.
In Confluence, if a page is deleted, the child pages won’t exist anymore.
Pages work differently in SharePoint.
In SharePoint, when deleting a page, its child pages in the Site Pages library and in the WikiPakk page tree still exist.
In SharePoint, when restricting access to a page, child pages might still be accessible for the current user.
Thus WikiPakk has to cope with a situation where in the midst of the page tree certain pages might be inaccessible.
Those pages will be represented as inaccessible page.
Handling inaccessible pages
There are some strategies to handle those pages.
Remove those pages via context menu
Note: this option is available as of WikiPakk 2.5.1. Update now.
Use the mouse to hover over the inaccessible page. Click the three dots to open the context menu. Click Remove from tree.
This removes hierarchy information for this page from the WikiPakk hierarchy table. All children of this page will be moved one level up.
The resulting tree looks like this:
Move inaccessible pages to a dedicated node
Use the WikiPakk page tree editor web part to move the inaccessible page away:
Note: the Deleted node in above image is a dummy page that has been created to serve as parent for inaccessible page nodes.
Out of sight, out of mind.
If the inaccessible page has child pages, you might want to move those to another parent node. In our sample those are the Project Bar and Project Foo pages, which have been moved to Home.
Note
WikiPakk already hides inaccessible page nodes if those don’t have any children and are true tree leafs. So, after moving inaccessible notes to a dedicated parent, they might disappear, which is the expected behavior.Advanced: Delete hierarchy information for inaccessible pages
You can make the inaccessible pages disappear completely by deleting their hierarchy information.
WikiTraccs stores hierarchy information for pages in a hidden list. This list exists in every site WikiPakk has been added to.
Open WikiPakk’s hidden hierarchy list by appending Lists/WikiTraccsPageTree to the SharePoint site root address, like so: https://contoso.sharepoint.com/sites/pagetreedemo/Lists/WikiTraccsPageTree.
Build this root address for your site and enter it into the browser address bar.
Locate the inaccessible page ID in the WtPId column, here 47.
Delete the list item.
The inaccessible page 47 is now gone from the tree.
Usability outlook
There are features currently being worked on that will improve handling for deleted pages:
- ✅ done:
manual option to remove inaccessible page nodes from the tree via their context menu - detection of deleted pages by looking in the recycle bin - this would allow removing some of the inaccessible page nodes automatically