When developing apps for Nextcloud it is more usual that as a developer you can directly clone the app and enable it. The makefile is also very specific.
To improve the developer experience I have renamed that file to "info.xml" directly. At least I was kinda confused why I couldn't enable the app the first time I cloned it :-)
Setting up FS is enough to get the correct file version. No need
to make the user login here.
File version would be in owner's FS, not editor, so
s/editorid/ownerid/
Since this WOPI Put method is executed when loolwsd hits owncloud
server, it has no session or probably invalid session data. Even
though WOPI Put file operation initiated by loolwsd succeds, i.e
file is successfully put into owncloud storage and versioned, it
returns an HTTP 500 Internal server error as response to loolwsd
which causes problem on loolwsd side messing up its state.
Following trace can be observed in webserver's error logs after
HTTP 500 is returned:
PHP Fatal error: Uncaught exception 'Exception' with message 'Session has been closed - no further changes to the session are allowed'
in /var/www/html/owncloud9/lib/private/session/internal.php:135
Stack trace:
#0 /var/www/html/owncloud9/lib/private/session/internal.php(60): OC\\Session\\Internal->validateSession()
#1 /var/www/html/owncloud9/lib/private/session/cryptosessiondata.php(150): OC\\Session\\Internal->set('encrypted_sessi...', 'e747091469b9905...')
#2 /var/www/html/owncloud9/lib/private/session/cryptosessiondata.php(64): OC\\Session\\CryptoSessionData->close()
#3 [internal function]: OC\\Session\\CryptoSessionData->__destruct()
#4 {main}\n thrown in /var/www/html/owncloud9/lib/private/session/internal.php on line 135
Creating a dummy memory session, setting it as current session,
and then setting the desired user session seems to address this
problem and does not emit HTTP 500 anymore.
There's a race condition here between page being rendered with
all the document(s) information and showing the editor to the
user. The later requires the former as it uses data rendered into
the page.
In most cases, former is quick enough and we do not see any
problems, but in some cases, mostly when the server is responding
very slowly, it will lag behind the later causing the editor to
be shown before data is rendered into the page leading to '404
Object not found'.
This should, hopefully, avoid such cases.
... so no need to create a deferred object separately and then
resolve it manually. This is since jquery 1.5
See: https://api.jquery.com/jquery.getjson/
