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
We already have converters as separate scripts
Building converters into the product is not worth the effort.
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 ?
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.
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.
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.
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.
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
https://github.com/SimpleMachines/SMF/pull/8093 (https://github.com/SimpleMachines/SMF/pull/8093)