Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.
Conversion from other board software? (Vbulletin)
This discussion has been closed.
Comments
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
One Bulletin Board -> Bulletin Board MicroFormat (in XML) -> Another Bulletin Board
Would solve a lot of trouble... and save us half the questions on BB discussion forums... ;-)
Is there actually a microformat in existance? Or are you suggesting making one?
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 etcUsers (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 hAtomMini, I think we're talking about creating something here, although building off something like Atom would seem to make sense...