News:

Want to get involved in developing SMF, then why not lend a hand on our github!

Main Menu

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

Started by UT99Shade, December 15, 2023, 09:53:11 AM

Previous topic - Next topic

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.
Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

UT99Shade

Quote from: Kindred on December 15, 2023, 08:40:50 PMWe 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.
Slava
Ukraini!
"Before you allow people access to your forum, especially in an administrative position, you must be aware that that person can seriously damage your forum. Therefore, you should only allow people that you trust, implicitly, to have such access." -Douglas

How you can help SMF

Arantor

Quote from: Kindred on December 15, 2023, 08:40:50 PMWe 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.
Holder of controversial views, all of which my own.


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

Quote from: live627 on December 22, 2023, 08:14:26 PMAn 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.

Quote from: live627 on December 22, 2023, 08:14:26 PM(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.

Quote from: live627 on December 22, 2023, 08:14:26 PMloosely like OpenImporter

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

Quote from: live627 on December 22, 2023, 08:14:26 PMMaybe 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.
Holder of controversial views, all of which my own.


Dblog

Quote from: Kindred on December 15, 2023, 08:40:50 PMWe 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

I promise you nothing.

Sesqu... Sesqui... what?
Sesquipedalian, the best word in the English language.

Advertisement: