Ability to disable "Blank page" template on page creation UI

Hi devs,

I’d like to propose that admins be able to disable the “Blank page” template on page creation UI.

The use case is the following:

  • Imagine a wiki where you want that all pages contain some xobject or that there’s some default content (like a toc macro at the top or a reference macro at the bottom, for example to list all citations in the page)
  • One way to achieve this would be to disable “Blank page” template and provide a custom Template.

In order for this new template to appear in the “Default” template section area in the page create UI, I’m also proposing to allow a template provider to declare that it’s a “default” one. Right now the “default” section says “Default (1)” and there’s only the “Blank page” in it. I don’t think we can add other ones even if the (1) suggest that it should be possible. Thus this proposal is about making it possible.

Screenshot 2022-03-10 at 10.37.38



+1, seems like a good way to promote a common style across a wiki.

Imo an interesting improvement could be to provide a specific default for a space. For instance, if you have a space dedicated to documentation, define a “Documentation template” as the default for this space.

Removing the “Blank page” template is not so critical if we can replace the default, as users can always remove all content from the editor and start from scratch if they want to.

That could be interesting too indeed.

It still raises the question of being able to have several default templates. The “Blank page” would be registered for the whole wiki and thus wouldn’t be replaced. The new default template would be added next to it for some specific spaces in your example. So we’d still need the ability to disable/remove the “Blank page” one I think.

Do note that we already have a mechanism for pre-selecting and sorting the “recommended” template(s) from the list, which works by matching the current location with one of the locations specified in the available template providers.

See Loading...

So, I am not really sure what “default” would mean at this point and considering the above mechanism and why we would want to add more stuff as “default”.

Another option would be to remove the “default” category completely and make the “Blank page” just another template provider which always ends up on the first location by default and which admins could configure or disable completely, since for some wikis, it could be less important. Of course, when no template providers exist, the “blank page” provider could still be handled as if it existed, in order to allow page creations on completely empty wikis. So, the existence of the actual template provider for “blank page” would be simply to allow configuring its behavior.

(side note: maybe we need an “enabled” flag for template providers)

Thanks Edy for you feedback and ideas.

I think the concept of default is to show some providers more pro-eminently than others, i.e. push users to use them. Now if we sort the providers and remove the default category then it could work too (even if the separation would less visible since there would be no clear boundaries between providers that are shown because they are “promoted” for the current page vs the rest of the providers (like Encyclopedia, etc). I guess we could use some vertical line separator to act as such a separation.

Yes, I agree. This was my original idea too but I got convinced by a stakeholder that it was simpler and less work to just allow disabling the “blank page” default template.

So to recap there are 3 separate topics here:

  1. Possibly removing the concept of “default” providers, or being able to set providers as default providers (while still maintaining the sorting algorithm)
  2. Being able to either disable the “blank page” template or transform it into a standard provider
  3. Be able to disable providers with a less final way than to delete the provider pages… BTW since I guess they are components in the backend (if not they could/should be so that it’s possible to implement providers in java), this could be generified as a need for an Admin UI to disable a component (since we have that needs in lots of other places too, for UIXs, etc).

My current preference:

  1. Remove the concept of “default” providers but find a way to separate the templates that are shown before in the list because they match some location from the others.
  2. Transform the “blank page” template into a provider proper
  3. Be able to remove/instantiate again components from the Admin UI



1 Like

+1 for the idea on blank page.

Personally I’d also like to be able to hide/restrict/remove the other default templates. (might be an issue on my implementation) but no matter what I try with the ‘Article / Encyclopedia / Meeting’ templates, they remain visible/usable.

Whereas I’d like the users to only see the self made templates, i.e.


sorry for the necro if this is a closed topic btw, came upon it & found it interesting!

We wanted the blank template only and did this dirty “hack”.

  1. go to admin/XWiki/XWikiPreferences?editor=globaladmin&section=Templates.
  2. click one of those templates on the right side you want get rid of
  3. edit this template
  4. “yes” force editing
  5. press “+” to add space “XWiki” as a place where this template should be available
  6. save the template
  7. repeat from 1.

Because you set this template available only at space “XWiki” it isn’t to see on other places.

It’s not a nice one but working.

1 Like

This was one of the things I tried! …

Turns out users actually had the disred choice of templates already… it was just me being logged in as global admin that could see all the templates :face_with_head_bandage:

Thanks a ton for writing it out @Simpel , got it working how I want it now (minus the blank page)

Perhaps for ordering of templates it’s an idea to assign index numbers. i.e. higher index number goes first.

This template provider index number could be administered from the template provider class, the global administration or from the provider page itself.

also +1 for an ‘enabled’ boolean