Message "failed to lock the page" when tring to edit a page

I can’t edit pages any more in the principal wiki (it still works in subwikis). Maybe it’s linked to the recent update - I’ve noticed a lot of changes included some social features.
I checked that page creation and deletion still work.
Many thanks in advance.

1 Like

You need to check the server logs for error messages that may be logged when trying to edit a page, and you should also look at the Network tab from the browser’s developer tools to get more information on the failed lock request (check the response).

Thanks @mflorea ,
I have nothing in the catalina log. The network tab gives us nothing after the 302 InplaceEditing get request - no response.
But I also noticed, on the console, an error related to load block of the mixed active content.

We also noticed that it works using WYSIWYG edition.

You don’t have any HTTP requests there with 4xx or 5xx status code? “failed to lock the page” suggests that the lock request has failed, and 302 (redirect) is not a failure. Are there any JavaScript errors in the Console tab?

Capture du 2020-10-23 14-24-57 nothing after 302.
Capture du 2020-10-23 14-25-50 and a “TypeError : b is Null” message I had already before

For some reason the request URL to lock the page uses http instead of https. Your browser is configured not to send such requests from a page with https.
This might be some problem with the configuration or the setup. Is in the Wiki descriptor for the main wiki the “Secure” flag set?

Dear Clemens,
You’re right, it seems to call the http page, well spotted !
But I checked and the secure flag is set in the wiki descriptor of the main wiki.
Is there something else to check ?

If there is an apache or nginx running in front of the servlet engine, doing the HTTPS encryption, then XWiki in the backend might think that the request came in via plain HTTP and thus responds via HTTP sometimes.

If the servlet container is tomcat, adding a scheme="https" to the relevant <Connector element in the server.xml often helps.

We tested your proposal @ClemensRobbenhaar , many thanks.
The problem is that doing that, the URL got back to local 8080 and xwiki is not reachable any more then.
We use nginx as a proxy as you well guessed. So there might be some interference with the server settings.

I have the exact same problem. Is there a solution?

I have installed XWiki using the official docker image from GitHub - xwiki/xwiki-docker: Dockerfile to build and run XWiki on docker with docker compose and mysql.

What can I do to fix this? In the current state, xwiki is unusable.

XWiki doesn’t have any known problem (that I know of) regarding HTTPS. There are plenty of instances around the world using that. So if there’s an issue , I’d say it’s with the way you’ve setup your front end to use HTTPS somehow. Could you check it?

I just followed the installation guide of the docker image and chose to use docker compose. I did not change any settings there.

My server uses plesk for administration and I you can just check “Use Let’s Encrypt” for https which I did. And then I put the following proxy rule for my xwiki subdomain in plesk (see screenshot).


Interestingly, everything else in xwiki works with https. It is only the “edit” button that does not work. So, maybe it’s just one setting in xwiki that I missed? Or something like this?

There’s no setting for that in XWiki. Actually there’s nothing to do to support HTTPS in xwiki, see

What is then the reason for the “failed to lock the page” message? Is there a documentation somewhere that explains in which situations this message appears? And how to fix it?

I had the same battle with Apache to Tomcat and xWiki… easy “fix”: configure Tomcat to listen to https (like 8443) and use any certificate you want (self signed or whatever). As long as you have a reverse proxy in front that does not care about the backend certificate, you are fine … HTH

thanks for your answer! how do I configure tomcat in such a way? (I’m using the docker image). Can you hint me to a tutorial or something?

I don’t know the version and setup of the docker image as I never used it. But this should be straight forward by generating a certificate (pkcs should do), and then enable the connector in the server.xml. Make a copy of the server.xml to have a fallback. Then re-configure the reverse proxy to point to the https port (declaring the https scheme to connect to the backend)

Same problem here on both 14.4.1 and 13.10.6
Steps to reproduce:

  1. create subwiki
  2. log in to that subwiki as a read-write user which is NOT the owner
  3. create a page, save
  4. try to edit recently created page - you’ll get the ‘failed to lock page’ message


  1. The xwiki is served via https
  2. The default editor is Wysiwyg

The reason is:

  1. browser sends the lock-request GET https://domain/get/Main?action=lock...
  2. xwiki (the application itself) answers 302 location httP://domain/...

And it doesn’t matter what the SSL and Port settings of the subwiki and/or mainwiki are set to

It is a bug. Maybe thats a Wysiwys-editors bug, but THERE IS a problem

I’ve installed the Realtime WYSIWYG Editor, assigned it as a default editor and it did the trick

  • XWiki 13.10.6
  • Realtime WYSIWYG Editor 13.10.6