[xwiki-users] XWiki 8.4.3 REST - attachments and versioning
Hello, I am using (as stated) XWiki 8.4.3 on a CentOS7-VM running in a docker-container. I am using a gradle script to push markdown-files and images to the wiki. The markdown is being wrapped in an xml envelope and pushed to the REST-API, which works nicely. The envelope looks like this: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <page xmlns="http://www.xwiki.org"> <title>TITLE</title> <syntax>markdown/1.2</syntax> <content>CONTENT</content> </page> TITLE and CONTENT are being replaced with the corresponding items, which are all escaped, so the problem is not with escaping. We are keeping the files in a structure like the XWiki page-structure, so we have a directory which contains the markdown and its images (corresponding to page, WenHome and attachments) and this contains other directories which in turn.. you get the idea. Basically, every directory is a page, every markdown-file is a WebHome and every other file is an attachment. Right now I am doing two iterations, one fetches the markdown files and the second fetches all other files. I am pushing the markdown with XML Content type and the Attachments with BINARY content-type (both from groovyx.net.http.ContentType.*). Now my problem is that when I upload the attachments, every single attachment adds a new version to the page history. I tried to mitigate this by adding <majorVersion>1</majorVersion> and <version>1.1</version> to the envelope, but these seem to be unevaluated, as the major version is still increased with every upload. So my question is: is there a way to: a) make sure the minor version is upgraded instead of the major version when sending an attachment b) replace the history of the page with a single major.minor-version history (as is done when importing .xar-files) c) upload the page with all its attachments at once, without having to change it from markdown to XAR?
On Fri, Feb 10, 2017 at 8:17 AM, Stefan Helmerichs <sh@form-solutions.de> wrote:
Hello,
I am using (as stated) XWiki 8.4.3 on a CentOS7-VM running in a docker-container.
I am using a gradle script to push markdown-files and images to the wiki. The markdown is being wrapped in an xml envelope and pushed to the REST-API, which works nicely. The envelope looks like this:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <page xmlns="http://www.xwiki.org"> <title>TITLE</title> <syntax>markdown/1.2</syntax> <content>CONTENT</content> </page>
TITLE and CONTENT are being replaced with the corresponding items, which are all escaped, so the problem is not with escaping.
We are keeping the files in a structure like the XWiki page-structure, so we have a directory which contains the markdown and its images (corresponding to page, WenHome and attachments) and this contains other directories which in turn.. you get the idea. Basically, every directory is a page, every markdown-file is a WebHome and every other file is an attachment.
Right now I am doing two iterations, one fetches the markdown files and the second fetches all other files.
I am pushing the markdown with XML Content type and the Attachments with BINARY content-type (both from groovyx.net.http.ContentType.*).
Now my problem is that when I upload the attachments, every single attachment adds a new version to the page history. I tried to mitigate this by adding
<majorVersion>1</majorVersion>
and
<version>1.1</version>
to the envelope, but these seem to be unevaluated, as the major version is still increased with every upload.
So my question is: is there a way to:
a) make sure the minor version is upgraded instead of the major version when sending an attachment
No. Would need to add support for some "majorVersion" parameter in https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwik.... But hard to make it memory efficient (but yes not a big issue with small attachments).
b) replace the history of the page with a single major.minor-version history (as is done when importing .xar-files)
Not using standard REST API.
c) upload the page with all its attachments at once, without having to change it from markdown to XAR?
No with the current standard REST API. Would need to add an optional content property in the Page model and add support for it in https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwik....
The possible alternatives are: * go trough XAR import REST resource as you probably seen from what I understand * write a wiki page which act as custom REST service * write a custom /rest/ resource component in Java -- Thomas Mortagne
Hi Stefan,
On 10 Feb 2017, at 10:29, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Fri, Feb 10, 2017 at 8:17 AM, Stefan Helmerichs <sh@form-solutions.de> wrote:
Hello,
I am using (as stated) XWiki 8.4.3 on a CentOS7-VM running in a docker-container.
I am using a gradle script to push markdown-files and images to the wiki. The markdown is being wrapped in an xml envelope and pushed to the REST-API, which works nicely. The envelope looks like this:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <page xmlns="http://www.xwiki.org"> <title>TITLE</title> <syntax>markdown/1.2</syntax> <content>CONTENT</content> </page>
TITLE and CONTENT are being replaced with the corresponding items, which are all escaped, so the problem is not with escaping.
We are keeping the files in a structure like the XWiki page-structure, so we have a directory which contains the markdown and its images (corresponding to page, WenHome and attachments) and this contains other directories which in turn.. you get the idea. Basically, every directory is a page, every markdown-file is a WebHome and every other file is an attachment.
Right now I am doing two iterations, one fetches the markdown files and the second fetches all other files.
I am pushing the markdown with XML Content type and the Attachments with BINARY content-type (both from groovyx.net.http.ContentType.*).
Now my problem is that when I upload the attachments, every single attachment adds a new version to the page history. I tried to mitigate this by adding
<majorVersion>1</majorVersion>
and
<version>1.1</version>
to the envelope, but these seem to be unevaluated, as the major version is still increased with every upload.
So my question is: is there a way to:
a) make sure the minor version is upgraded instead of the major version when sending an attachment
No. Would need to add support for some "majorVersion" parameter in https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwik.... But hard to make it memory efficient (but yes not a big issue with small attachments).
That would be a nice improvement. Would you mind raising a jira issue for this? Thanks -Vincent [snip]
participants (3)
-
Stefan Helmerichs -
Thomas Mortagne -
Vincent Massol