Tech comments:XML import

[Edit]Export Functionality Needed

Moved from the Feedback page:

I could really use Export functionality, either for moving between Prod and Dev platforms or for moving out of JamWiki and into another implementation (in case of issues with JamWiki). Can this be moved up on the priority list?

If you're referring to a database export, a DBA should be able to move content fairly easily between databases, and copying the JAMWiki file directories should handle file data. If you're referring to an XML export, technically an XML export is pretty simple to do but the problem comes from determining what the DTD for an export should look like - what author information should be included, how should topic and version information be exported, etc. Backwards compatibility can be a huge PITA, so I'd like to make sure that whatever format we choose is well thought-out. One specific problem is making sure that enough author information is provided with exports to conform to licenses such as the GFDL, which require attribution for redistribution. If you have ideas or suggestions please feel free to discuss them here or on Tech:XML import. -- Ryan 27-Jan-2007 01:40 PST

I think, a proper XML export/import can handle backward compatibility much easier than the database internal structures can do. Imagine a solid update procedure: export your data (optionally incl. changed settings), install the new JAMWiki version and import the exported data. At least this works very smooth since ages with Atlassian JIRA -- Tom 31-Jan-2007 11:53 PST

Sorry, I wasn't clear. My concern about backwards compatibility is that once JAMWiki chooses an XML format, we're pretty much stuck with it. Therefore I'd like to see whatever DTD we use be well thought-out. Exporting content as XML is easy; the hard part is figuring out the best way to structure that content. Mediawiki's DTD formats provide a good starting point if someone wants to work on a proposed JAMWiki DTD format. -- Ryan 31-Jan-2007 12:22 PST

As a user who acknowleges the usability and the value of JAMWiki I think that an easy export mechanism, oriented for non DBAs would be a valuable feature for JAMWiki. It would be very usefull because the export problem does not rise until one needs to move their wiki. If they fail to do so, they might not actually loose data, but they may get such an impression. Not beeing a DBA myself, I find it difficult to access the db where my data is stored when I need to move them. However, if there is no plan to provide such an export functionality, it would be usefull to document the inport/export proceedure for JAMWiki.

It's definitely climbing up my personal to-do list, although if someone else has the time and motivation to put something together that would be great. Either way, before too long the current XML functionality (discussed on Tech:XML import) will definitely be expanded to allow significantly more functionality. -- Ryan 17-Jul-2007 23:26 PDT

[Edit]general purpose import of all pages from mediawiki or another jamwiki

Moved from Feature Requests:

The descripton of XML import is arcane and doesn't explain how to use it to generally import a whole mediawiki or use existing online wiki services as a base to import articles/frame pages.

[Edit]static

Static import means identifying a mediawiki or its SQL database and sucking it in to jamwiki, choosing manually on a form which namespaces to include. May require dealing with one-time conflicts when names are being overwritten, with policies such as dumping the losing page to the talk/comment/discussion page associated with the winning page.

This is primarily useful for those moving to jamwiki from existing mediawikis.

[Edit]dynamic

Dynamic import means identifying which of several mediawikis, jamwikis, or even other wikis supporting XML import, contains an authoritative article on a subject, and instructing jamwiki to import it when there's an open link to it. Wikinfo does this with Wikipedia, importing every page not native to Wikinfo. Tikiwiki has a general facility of this nature.

It's extremely useful for intranets since you don't want to define every damn term in the language, you just want to refer people to relatively standard ones in Wikipedia or some fork of it like Wikinfo, without having them leave your corporate wiki.

[Edit]Dumping Wiki

Moved from the Feedback page:

Yo, guys. Is there a possibility of dumping my whole wiki in an HTML doc (many HTML pages)? --Zajoman 05-Sep-2007 13:09 PDT

Not yet, but it probably wouldn't be hard to build. I don't have time to work on it at the moment, but if you're a programmer feel free to throw some code together, or you can add a request to the Feature Requests page. -- Ryan 05-Sep-2007 14:41 PDT

[Edit]other wiki's data

Moved from the Bug Reports page:

Dear Ryan, Thank you for your replay. Jamwiki-0.6.6 allow export internal database data to CSV, that's great! Jamwiki could migrate from an external database of other wiki's,for example,Confluence or Snipsnap? how ?

In order to migrate wiki data someone would have to write an import/export tool for each of the various wikis. At present no tool exists to support that functionality, but given enough time something will probably eventually get created. -- Ryan 01-Jun-2008 08:28 PDT

[Edit]XML Export

Moved from the Feature Requests page:

XML import and export is useful for complying with open source licenses such as the GFDL and the CC-SA license, as it allows the full history of an article to be downloaded and credited. However, while this feature may be implemented in some form to allow for testing using data from other wikis, it will probably not be implemented as a fully supported feature for a while.

I really would appreciate it, if this Export/Import feature could be used to backup and restore the whole content. JIRA has a very smart feature: a backup-task can be configured to create backups in a regular intervals and store them zipped on the server's file system. Beside that, it also allows to import and export the content as XML which is very useful upgrading to a newer version. Tom 2007-01-26

Obviously being able to import an entire MediaWiki XML dump would make it a lot easier for enterprise users who've already started an MW instance to migrate. --Evan Prodromou 05-Apr-2007 06:42 PDT

See also Tech:XML import. -- Ryan 05-Apr-2007 23:25 PDT

There's now also Feature Requests about this, asking for both static and dynamic (Wikinfo-like) import.

[Edit]Getwiki/Wikinfo-like whole-wiki import

The extremely strategic and useful feature of Getwiki (a mediawiki fork) is that it draws in an entire wiki and populates all pages that are populated in that other wiki, and then lets users merely specialize and customize the pages. This is how Wikinfo works and it's how most organizations SHOULD use wiki content. That is, NOT write most of it themslves but rather import and specialize. Getwiki/Wikinfo uses some color coding to tell users which articles have been imported and which not.

Being able to nest wikis in a multiple-wiki cascade would make jamwiki extremely useful for projects that, like most in a private corporation, have multiple layers of security.