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.