I believe someone else was working on this a while ago but I'm not sure if it was released or not due to some DB changes.

Aha I've found

http://lussumo.com/community/comments.php?DiscussionID=145&page=3

and have e-mailed chris gwynne about where he's at with the vbulletin converter. *crosses fingers*

did anyone ever get to this? It is what is stopping me from changing my big board :)

I'd say email him - if he's paused in development half way through (as i tend to do with nearly everything i touch) it might be worth him sending you his code so you can finish it off or whatever.

I'd be interested to work on a migration api or something to make it easier for new migrators to be written in a common way if you're up for it adm?

well where you're at is pretty much spot on - my idea was just to make it easier for non-tech types to be able to build a migrator, and to let all migrators follow a common theme. I'm still not sure on the exact how's, mind.
Are you any good on the graphic side of things?

*does the dance of joy* Thanks guys, once this is done I can lead my users to the promised land that is Vanilla :)

ADM, you've emailed me? Haven't received it bud. Send it to chrisgwynne@gmail.com

As far as development, it's postponed until I can get my SQL database fixed, as I was messing with importing and exporting via various boards and Vanilla it's got seriously screwed up. If anyone's got any progress done on their own converter and want me to take a look, shoot it to the email above.

has there been any progress on this?

Josh drop me an email at g at int0rw3b dot com. I've told kay I'll migrate her wolt board so I'm thinking now is probably a good time to make a universal migrator system. Might be good to get our heads together (especially if you're useful with php?)

*bump

would love this

Bumpy, bumpy, bump-bump.
Does anyone know if anything's occuring with this? Is the universal converter being worked on? Even if it's not, just a working copy of the vBulletin converter would fulfill most people's needs.

If I really have to I will hack-up a vBulletin converter, not yet, but soon. Am looking to convert http://www.webmaster-forums.net to this fine software. :)

I'm still eagerly waiting for this too, I'm getting ready to move from vbulletin to vanilla and I'm basically just waiting on a converter...

anyone have updates to this??? it would help the Vanilla community grow a lot if there were some converters out there...

Hi,

while searching for "vbulletin to vanilla" migration, I came across this company that has already converted their helpdesk product based from Vbulletin to Vanilla.
I left a message in this thread:
http://forum.cerberusweb.com/comments.php?DiscussionID=8169&page=1#Item_18

Want to start creating that MicroFormat then Tom? ;) If you post it here as you go along everyone else can chip in features they need :)

OK, here goes 'hForum' :-)

A forum is a collection of posts/conversations (optionally hierarchical/organized).

A conversation consists of a content element posted by one author (user), followed
by a discussion (comments) by other authors (and/or the original author).

Hence a forum is not that different from a blog, and I think it could very well be captured
within the proposed hAtom spec for content elements:
http://microformats.org/wiki/hatom
(part of the official WIKI replicated below to facilitate easy discussion)

Notes:
Comments or (threaded) discussions can be seen as recursive hAtom content elements, e.g.

hAtom content element (post)
+- hAtom content element (comment 1)
| +- hAtome content element (comment 1.1 on comment 1, aka threaded discussion)
+- hAtom content element (comment 2)
etc etc

Users (authors) in hAtom are captured in the hCard format:
http://microformats.org/wiki/hcard

As a microformat hAtom is "Designed for humans first and machines second [...] built
upon existing and widely adopted standards." in this case Atom.

On second thought I'm not sure that exporting a forum in recursive (h)Atom elements
would satisfy the 'easy to grasp' goal.

Perhaps a less recursive (flat?) approach would result in more converters... anyway,
it's a start.

TT.


hAtom: Field and Element Details

Feed

* a Feed element is identified by the class name hfeed
* a Feed element represents the concept of an Atom feed (http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1)
* the Feed element is optional and, if missing, is assumed to be the page
* hAtom documents MAY have multiple Feed elements

Feed Category

* a Feed Category element is identified by rel-tag
* a Feed MAY have a Feed Category
* a Feed Category element represents the concept of an Atom category (http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.2) inside a feed (http://www.atomenabled.org/developers/syndication/#optionalFeedElements)
* Feed Category elements MUST appear inside a Feed element but not inside an Entry element
* the rel-tag href encodes the atom category:term; the link text defines the atom category:label

Entry

* an Entry element is identified by class name hentry
* an Entry element represents the concept of an Atom entry (http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.2)
* any microformat content inside a <blockquote> or <q> element within the Entry should not be considered part of the Entry.

This allows quoting other microformated data without worry of corrupting the model

Entry Category

* an Entry Category element is identified by rel-tag
* an Entry MAY have an Entry Category
* an Entry Category element represents the concept of an Atom category (http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.2) inside an entry (http://www.atomenabled.org/developers/syndication/#optionalEntryElements)
* the rel-tag href encodes the atom category:term; the link text defines the atom category:label

Entry Title

* an Entry Title element is identified by the class name entry-title
* an Entry SHOULD have an Entry Title
* an Entry Title element represents the concept of an Atom entry title (http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.14)
* if the Entry Title is missing, use
o the first <h#> element in the Entry, or
o the <title> of the page, if there is no enclosing Feed element, or
o assume it is the empty string

Entry Content

* an Entry Content element is identified by class name entry-content
* an Entry SHOULD have Entry Content
* an Entry Content element represents the concept of an Atom content (http://www.atomenabled.org/developers/syndication/atom-format-spec.php#atomContent)
* an Entry MAY have 0 or more Entry Content elements. The "logical Entry Content" of an Entry is the concatenation, in order of appearance, of all the Entry Contents within the Entry

Many weblogs split content into multiple sections with a "Read More" link and javascript tricks. This is also needed in cases where Entry Titles are coded inline and are considered part of the content.

* if the Entry Content is missing, assume it is the empty string

Entry Summary

* an Entry Summary element is identified by class name entry-summary
* an Entry Summary element represents the concept of an Atom summary (http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.13)
* an Entry MAY have 0 or more Entry Summary elements. The "logical Entry Summary" of an Entry is the concatenation, in order of appearance, of all the Entry Summarys within the Entry

Entry Permalink

* an Entry Permalink element is identified by rel-bookmark
* an Entry SHOULD have an Entry Permalink
* an Entry Permalink element represents the concept of an Atom link in an entry (http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.7)
* if the Entry Permalink is missing, use the URI of the page; if the Entry has an "id" attribute, add that as a fragment to the page URI to distinguish individual entries

Entry Updated

* an Entry Updated element is identified by class name updated
* an Entry Updated element represents the concept of Atom updated (http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.15)
* an Entry SHOULD have an Entry Updated element
* use the datetime-design-pattern to encode the updated datetime
* if there is no Entry Updated element,
o use the Entry Published element, if present
o otherwise the page is invalid hAtom

Entry Published

* an Entry Published element is identified by the class name published
* an Entry Published element represents the concept of Atom published (http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.9)
* use the datetime-design-pattern to encode the published datetime

Entry Author

* an Entry Author element is represented by class name author
* an Entry Author element represents the concept of an Atom author (http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.1)
* an Entry Author element MUST be encoded in an hCard
* an Entry Author element SHOULD be encoded in an <address> element
* an Entry SHOULD have at least one Entry Author element
* an Entry MAY have more than one Entry Author elements
* if the Entry Author is missing
o find the Nearest In Parent <address> element(s) with class name author and that is/are a valid hCard
o otherwise the entry is invalid hAtom


Stash, I'd say to stick to a standard, but *do* start simple, then add 'missing' features.

Convertor completed! 15 modules - http://downloads.exlc.net/vb_va_conv.png

Who is interested in convertor - my ICQ: 294779

P.S> At once write that you is interested in converter.

Best Regards, Raveex