Open AnrDaemon opened 6 months ago
From which version to which version did you try to upgrade?
The upgrade path: 4.3 → 5.0 → 5.5 → 6.0 → 6.1
Each version requires a distinct PHP and MySQL version.
If you have a very small wiki, it is probably easier to export and import all pages. By
Cluster/export.xml
& {{import}}
)using the page tag
and the page body
.
To circumvent the Fatal error: Field 'ip' doesn't have a default value'
you have to turn SQL strict mode off.
Patch: https://github.com/WackoWiki/wackowiki/compare/5.0.5...5.0 (pull 5.0 head)
Please please, use a recent supported version.
It requires not just distinct versions, but very specific configurations. Right now, I'm migrating R4.3 to 5.0. Even though it formally supports mysql/mysqli/pdo (with PDO being the fallback), if you do not specifically set driver to mysql_pdo, it won't even try to load the miration data and does not set DSN. Of course, connection initialization fails, and whole upgrade process halts. I've only found it out after connecting to xdebug and stepping through the whole process.
To circumvent the
Fatal error: Field 'ip' doesn't have a default value'
you have to turn SQL strict mode off.
Isn't it easier to just set default value?… Or at the very least, provide that value in migration data.
Back then (13 years ago) MySQL default settings were less strict, now it throws a PHP Fatal error. When this became an issue, we already worked on WackoWiki R5.4.
We can patch the 5.0 branch where possible and update the upgrade guide. The upgrade to 5.5 and 6.0 will probably cause similar problems.
WackoWiki 5.0 back ports most of the features of the openSpace fork.
I did see that. The upgrade guide MUST mention that setting database_engine
is required, else tables won't be created.
The DSN definition is missing ;charset=…
specification. (And it is required if your tables are already in unicode. Along with mandatory db_charset
spec.)
The acl
table fails one of the migrations.
The System
account fails creation.
And so on and so forth.
I'm slowly fixing all this [stuff]. But it's really slow. Mainly because, for some reason, database operations taking enormous amount of time.
BTW, I do not understand, why do you use str_replace instead of sprintf.
Added database_engine
to config defaults and write config array.
Please provide a patch against the 5.0
repo head.
Cannot say how it will work out with ;charset=…
later with the Unicode conversion (5.5 → 6.0).
str_replace
was already part of the legacy code base.
Cannot say how it will work out with
;charset=…
later with the Unicode conversion (5.5 → 6.0).
It'll work fine assuming PHP >= 5.3.6.
Please provide a patch against the
5.0
repo head.
Sure. Not in the near future, but sure. I have a working backup of my main wiki and 3 or 4 other wikis to migrate, so I have a plenty of testing space.
A lot of unnecessary table renames, field renames, mixed code paths… If you don't set your configuration in a VERY specific way, it doesn't even try to load critical parts of migration. Migrating a very small wiki with less than 300 pages took over 20 minutes. I've had to write CLI wrapper to push it though. Had to fix a number of issues as I go. But in the end, all I've got was this: