Hi Stefan,
On 10 Feb 2017, at 10:29, Thomas Mortagne <[email protected]> wrote:
On Fri, Feb 10, 2017 at 8:17 AM, Stefan Helmerichs <[email protected]> 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]