[3.0] Integrate updated forum migration to help people switch from other forums

[UT99Shade]

Hello,

as a SMF 3.0 release might result in some publicity and more people wishing to switch sides, I think it would be quite valuabe to have a migration feature integrated into the installation process, if someone wants to migrate from other well known forum softwares.

I have looked up the code frequency from different forum softwares on Github and it seems SMF is by far the most active project lately, while other projects are slowing down over the years.

SMF 3.0 would be the perfect opportunity to let the community grow even further and welcome people onboard who are stuck with their forum software. (Like me...)

What are your thoughts?

Regards
Shade

[Kindred]

We already have converters as separate scripts

Building converters into the product is not worth the effort.

[UT99Shade]

We already have converters as separate scripts

Building converters into the product is not worth the effort.

Do you think it is worth the effort to update the converter for  official support of PHP 8.x, phpBB 3.3.x (released back in 2020...) , SMF 2.1.x or even SMF 3.0 ?

[Aleksi "Lex" Kilpinen]

Sadly, converters require quite a bit of effort to keep up to date, and the team is fairly small.
If someone is interested and able to work with the converters, I'm sure the help would be welcomed.

[Arantor]

We already have converters as separate scripts

Building converters into the product is not worth the effort.

Yes, and that's the reason they're largely unmaintained. Redesign it, bring the core of it into the core of the platform, and make it more modular - it'll be easier to maintain and you'll make it easier to add new ones.

[live627]

An idea here could be to build a common core for installer, upgrader, and converters  all with separate schemas (I think in Laravel land it's called "migrations")... loosely like OpenImporter. Maybe even build Repair Boards on top of it, so that there's no excuse to not build it in.

[Arantor]

An idea here could be to build a common core for installer, upgrader, and converters

Yes. I certainly approached doing some of that in StoryBB where the entire schema was declarative rather than imperative, meaning that you could at any point run a Symfony console command and missing tables or missing columns would be created - and the same structure would be created by installs and upgrades alike.

(I think in Laravel land it's called "migrations")

In Laravel land a migration defines a step change; my typical production apps have 15-20 migrations which each define a new table, or new connected tables, some of my longer term apps might define 50 migrations over time.

These are much more akin to 'the changes you make to get from x.y.z to x.y.z+1' documented in code rather than massive sweeping changes.

loosely like OpenImporter

OpenImporter was a good idea of TE's that never got the traction it deserved.

Maybe even build Repair Boards on top of it

If you already have the schema described logically and descriptively, there's absolutely no reason not to do that. Mind you, if you define proper constraints, proper triggers and actually transactionalise things, the need for repair boards distinctly goes away.

[Dblog]

We already have converters as separate scripts

Building converters into the product is not worth the effort.

Many of those converts are old and not updated.
Converters can be kept as separate script, not built into 3.0

[Sesquipedalian]

https://github.com/SimpleMachines/SMF/pull/8093