-
Notifications
You must be signed in to change notification settings - Fork 256
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixes some upgrader errors #8437
Fixes some upgrader errors #8437
Conversation
Signed-off-by: Jon Stovell <[email protected]>
Signed-off-by: Jon Stovell <[email protected]>
Signed-off-by: Jon Stovell <[email protected]>
I can get much closer to running a simple 2.1.4 => 3.0 upgrade. Still an outstanding issue though. PHP 8.4.2; MySQL 8.4.0; Upgrader run via CLI. Partial log:
|
Signed-off-by: Jon Stovell <[email protected]>
Note I attempted to run the installer and got a WSOD with :
The WSOD happened in the very last step, creating the admin account. |
Signed-off-by: Jon Stovell <[email protected]>
There were some leftover $smcFunc['db_*'] calls. Should be fixed in 1032ac3.
Should be fixed in 3b8a2c9. |
OK.... Ran a few tests...
Upgrader error in PHP 8.4 (partial CLI output log):
Upgrader error in PHP8.3 (partial CLI output log):
|
Let me know if you want me to focus testing on PHP8.3. The PHP8.4 issue is tracked separately here: #8402 |
Signed-off-by: Jon Stovell <[email protected]>
c469228 should fix that. I think I have found all the places that would have triggered that error now.
Once we have fixed the underlying issues so that no more error are triggered, we won't see that one either. We can deal with #8402 itself separately. |
OK here's the latest:
Note the "The process cannot access the file because it is being used by another process (code: 32)" must be related to this upgrade - it's the only thing running. Also.... up.txt is the name of my CLI output log, where messages are being piped, it's not an SMF file... Upgrade test, PHP8.3, partial CLI log:
|
I just attempted a 2.0 => 3.0 upgrade, & it didn't get very far. I thought we were thinking of dropping upgrades from forums prior to 2.1??? Anyway here's the error:
|
Signed-off-by: Jon Stovell <[email protected]>
Signed-off-by: Jon Stovell <[email protected]>
Signed-off-by: Jon Stovell <[email protected]>
These ones should be fixed by 67e0235.
This one should be fixed by 0015dbc.
This one should be fixed by 1eeb801. |
Not yet. Once #8093 is done, we'll move the stuff for upgrading from SMF 1.x into separate converter packages. I plan to keep support for upgrading from SMF 2.0.x in the large upgrader package, though. We still have a lot of 2.0.x forums out there, and I want it to be easy for those admins to upgrade to 3.0 when they learn that 2.0 has reached end-of-life. |
Signed-off-by: Jon Stovell <[email protected]>
Results:
Partial CLI log:
Partial CLI log:
|
Still haven't tried 1.1, 1.0, or YaBBSE yet; some setups needed on my side to get all that working again. Also haven't yet done a 3.0 => 3.0 upgrade test yet. Historical we've ensured the upgrader can be rerun, eg, for folks who encounter issues & end up restarting it a few times... |
Signed-off-by: Jon Stovell <[email protected]>
Signed-off-by: Jon Stovell <[email protected]>
Latest two commits should fix those.
Don't worry about that for now. The real target for installer and upgrader stuff is Alpha 5. The goal for Alpha 3 regarding the upgrader is just to verify that the rewritten ConvertUtf8() works correctly. Testing 2.0 → 3.0 is sufficient for that. |
That's an important one for sure. |
OK, won't do 1.1, 1.0, or YaBBSE at this time. Results: Partial CLI log:
|
Apparently it doesn't like |
Signed-off-by: Jon Stovell <[email protected]>
... Which is not actually what I did. Instead I simply added fallbacks in SMF\Calendar\RecurrenceIterator to replace the time zone identifier with the UTC offset when the time zone identifier is not recognized by \DateTimeInterface::modify(). |
OK, here are the current results, with 2 caveats: Caveat 1: Caveat 2: |
Great! Thanks, @sbulen! We can deal with those remaining items elsewhere later. |
@sbulen, this should fix the unrelated issues that you ran into while testing #8425. Please test this PR first. Once we have merged this, we can go back to testing #8425.
Also fixes #8439