Inspired by Corey's comment about setup.pl, would it not be a good move to base any convertors around the existing y1>y2 convertor? I've started the groundwork on a webboard8 to y2, which is being made a lot easier by simply replacing the file reads etc and presenting the necessary data as though it actually comes from the y1 file.

I think modeling the looks and functionality of the YaBB 2 Setup/Converter file is good. However, it will probably be hard to use it completely and add/change things. It would probably be easier to start from scratch and copy out the functions that you truly need. Because you don't need the setup new YaBB 2 stuff or the Y1 -> Y2 stuff. Those will be executed by running Setup.pl when someone begins to install their new forum.

I would make a new converter file called Converter.pl that has the same basic look but instead begins with asking where your forum data is, attempt to autodetect the version and type of forum, ask what type it is to verify (from a dropdown), then go through similar conversion steps as the Y1 -> Y2 converter does, of course, executing the functions necessary for that system to be converted.

I think modeling the looks and functionality of the YaBB 2 Setup/Converter file is good. However, it will probably be hard to use it completely and add/change things. It would probably be easier to start from scratch and copy out the functions that you truly need. Because you don't need the setup new YaBB 2 stuff or the Y1 -> Y2 stuff. Those will be executed by running Setup.pl when someone begins to install their new forum.kj

POint taken. I thought the block at the end with the copies of the settings were likely #not# convertor.

I'm using the y1>y2 parts , replacing the file reads of the y1 with the database bits, to present the data as though it was from the y1 content. These are good templates for the purpose and avoids the 'reinventing the wheel' bits.

Yep, I agree. The layout, error functions, methods of converting Y1 data (like doing members in multiple steps to reduce server time for each process), etc. are great to model/copy. It will certainly save time and give us a quality converter that operates like the Setup/Convert wizard we already have. Just as long as it doesn't have the setup new YaBB 2 stuff in it or convert YaBB 1 data, since that will be included in the file that exists in YaBB 2's package.

What we can do is put this converter on the downloads page. If it's not too big, we can include the converters from all forum types in the one script. If necessary for file size, we can break it up and just copy and paste the shell of it and change just the internal data conversion functions for the corresponding forum. Then each of these can be provided separately on the downloads page.

Thanks for working on this, as I think it will help YaBB GREATLY to have a variety of converters.

The converter script will ask what software and version you have to convert from by populating the list after reading the drivers you have available in the drivers folder. Each driver will basically contain the data scheme of that forum system by giving each type of data a YaBB variable name. The converter will know what each variable name means and put that data into the proper location for YaBB 2's data structure.

There are some sub-issues I'm coming across as I work - sub GetCats is nearly sorted :

DBI and DBD modules are required to do the database conns, not such an issue.However, the exact DBD::ODBC or DBD::ADO (etc) is going to be both platform and database-dependent.There isn't a win32 build of the ADO library for some weird reason, being as that is the more efficeint way of talking to SQl Server/MSDE. I'm not too sure which DBD... is needed for MySQL, and generaly for UNIX/Linux hosts.

The converter script will ask what software and version you have to convert from by populating the list after reading the drivers you have available in the drivers folder. Each driver will basically contain the data scheme of that forum system by giving each type of data a YaBB variable name. The converter will know what each variable name means and put that data into the proper location for YaBB 2's data structure.

Also need to settle on some standard work-arounds.handling multiple attachmentsbuilding in 'fake' entries - how to drop in a 'template' value where it doesn't exist in the other forum

Are we keeping the same overall flow as setup.pl presents? If I'm understanding what is being said, the 'from' data structures will be stored in separate .pl files. Will these get pulled in on demand?that is, you'd have a 'eblah.pl', or 'vbulletin.pl' imported after the initial selection screen, each containing the same set of subs to handle the extraction, that would then feed a standard process to build the data into the destination file?