Special rendering for draft pages in XWiki navigation elements

Help / Discuss
1

Hello, friends, really need your help!

At our organization, we’ve implemented to XWiki section templates for project management. These already include pages for analytics, development, testing, and so on.

When a new project starts, the project manager creates a new section using this template, and a large tree of pages with standard content is created in XWiki.

On the one hand, this is very convenient: we can create a ready-made section with an internal structure and pages in one click.

On the other hand, all these pages are displayed in the structure by default as regular wiki pages. The user begins navigating through them, but they don’t yet contain useful information, only a template. This irritates the user—they’ve navigated to this page in vain. Since there are many such draft pages in the project section, user frustration grows, as they can’t distinguish in the navigation draft pages and pages with full-fledged working information.

How can we make draft pages appear specially in the XWiki structure (for example, in 50% gray)? This way, users can identify them as drafts in the navigation bar and other navigation elements, and avoid having to navigate to them unnecessarily.
Essentially, we need special rendering for such pages in navigation elements (the “Navigation panel” macro, the “Children” macro, and the “Document Tree” macro).

Possible scenario:
To identify such pages, we can include a special tag (“draft”) for them in the template.
When XWiki finds this tag, it will identify the page as a draft and, according to the rendering rules defined in the CSS, display it appropriately in the navigation (for example, in 50% gray).
And when work on the page is finished, the author removes the “draft” tag, and the page appears in the navigation as a standard wiki page (without special CSS styling).

Questions:

  1. How feasible is this scenario for XWiki?
  2. How can we force XWiki to parse page tags and, upon detecting the “draft” tag, classify this page as a special class of draft pages?
  3. And how can we enable an alternative rendering option for this class of pages in navigation elements (“Navigation Panel” macro, “Document Tree” macro, and “Children” macro)?

We are using XWiki version 17.4.5.

I’d be very grateful for any advices ))

2

Do you mean that you’re using the XWiki Template Provider feature that allows copying a page and all the nested pages under it?

What about marking these pages as Hidden in the template, and when you modify these pages with real content, the editor removed the hidden flag? In this manner, simple users (who don’t see hidden pages by default), will not see the pages.

All these features use the {{documentTree}} macro so you’ll need to develop a custom Document Tree macro to replace the default one. Then in that code, you can do whatever you want, like display draft pages in a special way.

Personally I find that a bit comple, and I think the hidden pages approach is much simpler.

Another possibility is to create the templates in a separate wiki or under a separate page, work in there and when it’s ready copy or move the pages to the production wiki or production page tree. There’s even a publication workflow application that exist: https://extensions.xwiki.org/xwiki/bin/view/Extension/XWiki%20Publication%20Workflow%20Application

Food for thoughts :slight_smile:

3

Yes, that’s exactly it.

We tried this option, but it’s inconvenient for workflow. Hiding pages affects all users, including the author.
Let me explain with a typical workflow:
A project manager (PM) creates a project section in XWiki using a template. It contains about 50 structured pages. Different pages are filled by different people (analysts, developers, testers, technical writers, etc.).
To distribute work among authors, the PM needs to see the whole picture. But the “hidden” flag for a page applies to everyone, including the PM. This means that either the PM needs to enable hidden pages in their profile, which would allow them to see all XWiki pages, including service pages, macros, etc. This greatly complicates navigation.
Or PM need to maintain a directory of links to these hidden sections, which is also inconvenient, as there are so many of them.

In general, working with drafts in XWiki raises questions among users, especially those familiar with Confluence. Confluence is more convenient: by default, a page created by an author is visible only to them, allowing them to work on it freely. Only after clicking the “Publish” button does it become visible to other users. In this scenario, the PM sees all project pages, including drafts, while other users see only published ones. The contributor receives a link to the draft from the PM and works on it, then publishes it once finished.

The option proposed in this thread (special rendering for drafts) is a middle ground. Drafts are visible to all project participants, but users can immediately distinguish them from finished pages. This also provides another advantage for the PM: they can immediately visually assess the current status of the work (the ratio of drafts to finished pages).

In my opinion, this will complicate the project. We’re talking about a team of multiple contributors working on projects with tight deadlines. There shouldn’t be any confusion here; people should clearly understand what working materials are currently available for use and where they are located in XWiki. Duplicating and moving materials will inevitably lead to confusion.

Thanks for the link, I’ll check out that extension. We tested something similar a couple of years ago – Change Request Application. But it didn’t work quite as expected, and we decided against implementing it into our processes.
I think extensions like these are needed in areas where strict approval of work materials is required. There, the process makes sense, but in typical development, it’s redundant and would slow things down more than it would help.

Thank you for your answers!