I described the problem I had with using the rest interface to update files in xwiki 2.1 format. The point is to script a bulk upload that way. But as I have described, it seems that the content of the <content> element must not contain xml, even if enclosed in {{code}}...{{/code}}. It is interpreted as belonging to the surrounding xml and breaks the parsing process. When pasting exactly the same xwiki/2.1 format direclty into the xwiki editor it works as expected. That means that REST upload of xwiki pages only accepts that subset which does not contain characters which are processed by the xml processor, right? I would appreciate a confirmation or rebuttal of the problem, and, if so, a possible workaround. Would a future solution to the problem be to require the content of the <content> element to be within a block? Regards, Roland -- View this message in context: http://xwiki.475771.n2.nabble.com/Rest-API-XML-and-Xwiki-syntax-interference... Sent from the XWiki- Users mailing list archive at Nabble.com.

Hi Roland, On Tue, Sep 30, 2014 at 5:35 PM, rol <[email protected]> wrote:

Hello,

I want to do a bulk import of some 80 wiki pages (i.e. files) in xwiki 2.1 syntax to an xwiki instance.

However, in the input there is some xml within {{code}}...{{/code}} sections which creates trouble.

The following xml markup:

{{code}} <property as="xs:anyURI" name="oxf.fr.detail.send.success.uri.*.*" value="http://localhost:8080/site/mycases/form/confirmdispatcher"/> {{/code}}

causes the parser to derail. To prevent this from happening, I must substitute the '<' and '>' with < and > respectively.

However, when pasting exactly the same code directly into the xwiki-editor in source mode the content is parsed correctly.

The content is not the only information that a wiki page has. It also has a title, a parent, an author, a creation date, etc. When you export a wiki page (but it applies to import too) all this information ends up in a single XML document so each (meta)data must be XML-encoded to prevent it from interfering with the XML tags used to describe (mark) them. <xwiikidoc> <title>XML encoded title</title> <content>XML encoded content</content> ... </xwikidoc> When you edit the content of a wiki page using the wiki editor (source mode) the content is obviously decoded (otherwise it would have been a pain to edit). Hope this helps, Marius

Is there any better way to solve this problem than to pre-process all xwiki-2.1 files and perform the necessary substitutions within code sections such as above?

BTW I used a scriptified version of the following command for the operation:

curl -u Admin:admin -X PUT --data-binary "@input.xml" -H "Content-type: application/xml" -H "Accept: application/xml" http://wiki.motrice.org/xwiki/rest/wikis/xwiki/spaces/Motrice/pages/NewPage

Best regards, Roland

-- View this message in context: http://xwiki.475771.n2.nabble.com/Rest-API-XML-and-Xwiki-syntax-interference... Sent from the XWiki- Users mailing list archive at Nabble.com. _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

Ha right I missread, I tough he was talking about some XML sent by REST. You indeed must not mix what is part of the XML syntax of what you send to XWiki and what is some black box content from this XML point of view and should then be escaped. On Wed, Oct 1, 2014 at 12:01 PM, Marius Dumitru Florea <[email protected]> wrote:

On Wed, Oct 1, 2014 at 12:54 PM, Thomas Mortagne <[email protected]> wrote:

...

That sounds like a bug to me.

There's no bug here. It doesn't matter that you have the {{code}} macro in the content of the wiki page. Anything that is inside the content of the wiki page is XML encoded when you export (import) the page. Just try it.

<xwikidoc> ... <content> XML-encoded content here {{code}} This still need to be XML encoded! Otherwise it would interfere with the XML syntax used to describe the wiki page. {{/code}} ... </content> ... </xwikidoc>

...

Would be great if you could create an issue in http://jira.xwiki.org with detailed step to reproduce it.

On Wed, Oct 1, 2014 at 11:49 AM, rol <[email protected]> wrote:

...

I described the problem I had with using the rest interface to update files in xwiki 2.1 format. The point is to script a bulk upload that way.

But as I have described, it seems that the content of the <content> element must not contain xml, even if enclosed in {{code}}...{{/code}}.

It is interpreted as belonging to the surrounding xml and breaks the parsing process.

When pasting exactly the same xwiki/2.1 format direclty into the xwiki editor it works as expected.

That means that REST upload of xwiki pages only accepts that subset which does not contain characters which are processed by the xml processor, right?

I would appreciate a confirmation or rebuttal of the problem, and, if so, a possible workaround.

Would a future solution to the problem be to require the content of the <content> element to be within a block?

Regards,

Roland

-- View this message in context: http://xwiki.475771.n2.nabble.com/Rest-API-XML-and-Xwiki-syntax-interference... Sent from the XWiki- Users mailing list archive at Nabble.com. _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

-- Thomas Mortagne _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

-- Thomas Mortagne

Hi Roland, On 1 Oct 2014 at 15:51:05, rol ([email protected](mailto:[email protected])) wrote:

Hello,

Thank you for your answers. It then makes sense that embedding content in a CDATA block is not a good idea, since that would have to be done not only for the content element, but for all metadata elements that might contain xml-encodable characters.

I forgot to say: The input files are in Trac format ( http://trac.edgewall.org/wiki/TracWiki ) so if there exist a conversion script that takes a set of trac files and generates an XAR archive I would happily use it.

In an older thread I found this:

...

Could you tell us more about the wiki you wish to convert since there are some conversion scripts that exist already on http://code.xwiki.org and in the sandbox.

But that resource has either been moved or is deleted.

code.xwiki.org has been moved to http://extensions.xwiki.org Actually I’ve put a link to all extensions related to migrating from one wiki to another here: http://platform.xwiki.org/xwiki/bin/view/Features/Imports#HImportingfromanot... AFAIK there’s no Trac import ATM but maybe Trac can export in HTML and then read that in XWiki. Alternatively use some regex to convert as some scripts do... Hope it helps a bit, Thanks -Vincent

If there is no existing script for importing a set of Trac wiki files, I will go for building a XAR archive, since my earlier problems with that turned out to be the same encoding problem that I had with the REST import.

Is there any published schema of the xwikidoc document type (or a list of optional fields), and maybe also a description of the package.xml?

If not, I will just tweak it from an example export.

Thanks, Roland

----- Roland Hedayat

Could you paste the exact XML you are sending ? On Wed, Oct 1, 2014 at 4:41 PM, rol <[email protected]> wrote:

Hi,

Thanks for the answer.

We have created an (unpolished) groovy script which takes the input directory name, a file with regexps and an output directory as arguments. It then creates the directory structure and the package.xml file, which we manually zip into a XAR.

We can provide this conversion from Trac as a contribution (when it works, and after polishing).

However, we have a new problem: The xml encoded characters are kept as such, which means that the imported document is cluttered with xml-encoded characters, which also destroys all xwiki-syntax links.

Shouldn't the XML-processor resolve the xml encoded characters so that the xwiki parser gets back the escaped characters in original form?

Example:

The source code of an imported page now has stuff like the following: {{code}} sudo sh -c "./execute_file.sh motricedb ../create/motrice.postgres.demodata.sql" {{/code}}

And the destroyed xwiki-syntax links:

* [[Initiering Motrice databas>>BootStrapMotriceDb]] * [[Motrice installationsdokument>>PortalInstall]] * [[Motrice Sample Configuration>>MotriceSampleConfig]] * [[Motrice Stand-Alone Deployment>>MotriceStandAlone]] * [[Hippo CMS hantering>>HippoAdmin]] * [[Orbeon/plattformen: bra att ha>>OrbeonHandgrepp]]

Are we doing something wrong?

Thanks //Roland

----- Roland Hedayat -- View this message in context: http://xwiki.475771.n2.nabble.com/Rest-API-XML-and-Xwiki-syntax-interference... Sent from the XWiki- Users mailing list archive at Nabble.com. _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

-- Thomas Mortagne

The conversion of Trac wiki files to Xwiki 2.1 format and packaging of these into a XAR archive works now. Some 70+ pages from Trac were imported from Track, no errors and links intact. Thanks for the help provided. If desired, we can contribute the Groovy script and the regexp file. Regards, Roland ----- Roland Hedayat -- View this message in context: http://xwiki.475771.n2.nabble.com/Rest-API-XML-and-Xwiki-syntax-interference... Sent from the XWiki- Users mailing list archive at Nabble.com.

  On 2 Oct 2014 at 09:43:50, Thomas Mortagne ([email protected](mailto:[email protected])) wrote:

Glad you succeeded !

I'm sure there would be people happy to find it on http://extensions.xwiki.org ;)

I concur, that would be great! Thanks -Vincent

On Wed, Oct 1, 2014 at 9:19 PM, rol wrote:

...

The conversion of Trac wiki files to Xwiki 2.1 format and packaging of these into a XAR archive works now. Some 70+ pages from Trac were imported from Track, no errors and links intact.

Thanks for the help provided.

If desired, we can contribute the Groovy script and the regexp file.

Regards, Roland

----- Roland Hedayat