On 10 Feb 2017, at 10:29, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
On Fri, Feb 10, 2017 at 8:17 AM, Stefan Helmerichs <sh(a)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/xwi….
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]