Confusion about "aliases" for subwikis

We have created a “subwiki” on our “”-XWiki and want to use a different url, so that “” is an alias to the new subwiki. There are two different options to create “alias” entries when configuring the subwiki - “Alias” (“The alias used to access the wiki.”) and further down: “Create new alias” - what is the difference (see screenshot)? If we use either one of them to set an alias “it-intern”, we are redirected to the base XWiki (and the same happens to any name “” which is not explicitly configured as an alias). What is going wrong? Many thanks in advance!
Screenshot 2024-01-05 at 15.54.00

The meaning of the wiki descriptor alias is very different depending on if your wiki is configured to have a domain based access (where what decide which wiki you end up on is the domain of the URL) or a path based access (the default, where the domain in the URL is not really relevant and the identifier of the wiki is part of the path).

You might want to take a look at

Thanks - but we are still having problems - we have now changed “xwiki.virtual.usepath” in xwiki.cfg and set Alias to “” (the “Alias” entry at the bottom, the top one we left blank) - this URL now yields the start page of the subwiki, as intended. However, it is not using https (the certificate allows for *, so this is not the problem) and there is a timeout when clicking on the home icon in the bread crumb path. Another question: is there/should there be a difference in performance when using path vs URL based access?

It’s not very clear what you mean exactly, do you mean external URL pointing to this wiki don’t contain https ? If that’s the case, it’s possible to forgot to indicate in the wiki descriptor that it’s a “secure” wiki by default (meaning using https instead of http when generating a URL for this wiki by default).


Sorry, my answer lacked important details: the subwiki is indeed configured as “secure” (SSL) and it uses https, however, the browser warns that “parts of the page such as images are not secure”. So currently “” will open the correct subwiki, however we have the mentioned security warnings, also the “Wiki Index” entry from the “hamburger menu” is broken: it tries to open "“ instead of "“ (which works) as does indeed “” in general (no security warnings). I hope both problems are due to simple configuration mistakes?

This is usually the sign that the HTTP proxy in front of XWiki is wrongly configured and does not forward enough information about the source URL. See for example for Apache.

YES - it seems we have a working configuration now - many thanks for your help!

In summary:

our server has a basic Wiki which is available like this:

We have configured a subwiki which should be accessible in this way:

(1) set "xwiki.virtual.usepath=0” in xwiki.cfg
(2) configure the “”- wiki:
secure: Yes, Port: -1, alias: “
(3) configure the “”-wiki:
secure: Yes, Port: -1, alias: “”, “create new alias”: “
(4) create a certificate with wildcard: “*”
(5) add a second “server_name” in nginx config:

server {
  listen 443 ssl http2;
  ssl on;
  ssl_certificate /etc/ssl/certs/info_sf_mpg_de.pem;
  ssl_certificate_key /etc/ssl/private/info.key;


  client_max_body_size 100M;

  access_log /var/log/nginx/xwiki-access.log;
  error_log /var/log/nginx/xwiki-error.log;

  location = / {
    return 301 https://$host/xwiki;

  location /xwiki {
    proxy_set_header   X-Real-IP $remote_addr;
    proxy_set_header   Host      $host;
    proxy_http_version 1.1;
    proxy_set_header   Upgrade $http_upgrade;
    proxy_set_header   Connection 'upgrade';
    proxy_cache_bypass $http_upgrade;

You should keep the port empty (or -1) actually as 443 is the default port for HTTPS.

fixed, thanks.

There is a minor bug in XWiki: using the entry “Wiki Index” from the “hamburger” menu, the resulting page is called “Browse Wikis” (which should be “Wiki Index” or vice versa) but on a more important note: the “Edit” and “Delete” button/links on the right hand-side (see attached screenshot) are grayed out when in fact they are functional and should have the default link colour.
Screenshot 2024-01-09 at 16.30.48

Indeed. Don’t hesitate to create two BUG issues on Loading... for those.