More upgrader fixes

[Sesquipedalian]

Fixes #8197
Fixes #8198
Fixes #8199

[Sesquipedalian]

@Oldiesmann, please test to confirm that upgrading now works in both the browser and on the command line.

[Oldiesmann]

Upgrade went smoothly with MySQL via the browser. Will test with PostgreSQL on command line shortly.

[Oldiesmann]

Upgrade went fine in the shell as well but I still got a deprecation warning for pg_version() even after making the changes, this time on line 75 of upgrade.php.

[Sesquipedalian]

Latest commit should fix that, @Oldiesmann. Can you please test on PG one more time?

[Oldiesmann]

New problem this time.

PHP Fatal error:  Uncaught TypeError: strpos(): Argument #1 ($haystack) must be of type string, false given in /.../Sources/QueryString.php:70
Stack trace:
#0 /,,,/Sources/QueryString.php(70): strpos()
#1 /.../upgrade.php(848): SMF\QueryString::cleanRequest()
#2 /.../upgrade.php(241): loadEssentialData()
#3 {main}
  thrown in /.../Sources/QueryString.php on line 70

The problem is that $_SERVER['QUERY_STRING'] is never set when running via CLI (since there is no query string as we're running the file directly through the PHP interpreter). Best option would be to just check whether we're running from the command line and skip that check if so. I'm not sure why I didn't run into this last time, unless I just wasn't paying attention.

[Tyrsson]

Normally, and this is just a general observation. QueryString will pretty much mirror argv. If the browser script is supporting params being passed the same options should "generally" be passable via argv in shell should they not?

[Oldiesmann]

The code in question is simply checking whether someone is trying to be funny by sticking a URL in the query string. Completely irrelevant when upgrading via CLI.

		// It seems that sticking a URL after the query string is mighty common, well, it's evil - don't.
		if (strpos($_SERVER['QUERY_STRING'], 'http') === 0) {
			Utils::sendHttpStatus(400);

			die;
		}

[Sesquipedalian]

New problem this time.

PHP Fatal error:  Uncaught TypeError: strpos(): Argument #1 ($haystack) must be of type string, false given in /.../Sources/QueryString.php:70
Stack trace:
#0 /,,,/Sources/QueryString.php(70): strpos()
#1 /.../upgrade.php(848): SMF\QueryString::cleanRequest()
#2 /.../upgrade.php(241): loadEssentialData()
#3 {main}
  thrown in /.../Sources/QueryString.php on line 70

The problem is that $_SERVER['QUERY_STRING'] is never set when running via CLI (since there is no query string as we're running the file directly through the PHP interpreter). Best option would be to just check whether we're running from the command line and skip that check if so. I'm not sure why I didn't run into this last time, unless I just wasn't paying attention.

It's strange that I don't receive any such errors in my tests. But at any rate, try now.

[Oldiesmann]

Latest attempt...

PHP Deprecated:  pg_version(): Automatic fetching of PostgreSQL connection is deprecated in /.../Sources/Db/APIs/PostgreSQL.php on line 1113
 * Updating Settings.php... Successful.
 *  done.
 Successful.
 *  +++  Adding a new column "version" to messages table done.
 +++  Adding a new column "version" to personal_messages table done.
 Successful.
 *  +++  Add duration, rrule, rdates, and exdates columns to calendar table done.
 +++  Set duration and rrule values and change end_datePHP Fatal error:  Uncaught TypeError: SMF\Db\APIs\PostgreSQL::fetch_assoc(): Argument #1 ($result) must be of type object, false given, called in /.../upgrade.php(2467) : eval()'d code on line 9 and defined in /.../Sources/Db/APIs/PostgreSQL.php:350
Stack trace:
#0 /.../upgrade.php(2467) : eval()'d code(9): SMF\Db\APIs\PostgreSQL->fetch_assoc()
#1 /.../upgrade.php(2467): eval()
#2 /.../upgrade.php(1884): parse_sql()
#3 /.../upgrade.php(371): DatabaseChanges()
#4 {main}
  thrown in /.../Sources/Db/APIs/PostgreSQL.php on line 350

[Sesquipedalian]

Er, are you sure you tested with the correct commit checked out? The connection is provided on line 1113.

[Oldiesmann]

I'll double check. I may have forgotten to update that file.

[Oldiesmann]

That got rid of the deprecation error. It still dies with the other error though.

[Oldiesmann]

Further digging reveals that the query beginning on line 129 of upgrade_3-0_PostgreSQL.sql is failing because there is no longer an end_time column in the calendar table (since that was dropped during a previous run of the upgrader). We either need to check whether that column exists first or add a setting indicating we've already completed that part previously and then skip the event conversion stuff if so.

[Sesquipedalian]

Hopefully the latest commit will finish it.

[Oldiesmann]

Hopefully the latest commit will finish it.

Unfortunately not.

 +++  Set duration and rrule values and change end_datePHP Parse error:  Unclosed '{' on line 2 in /.../upgrade.php(2467) : eval()'d code on line 46

[Oldiesmann]

It's because the "{" in the if statement on line 128 of upgrade_3-0_PostgreSQL.sql is never closed. I'm just not sure where to add it.

[Sesquipedalian]

Bleh. I must have made the same mistake there that I made earlier in the MySQL file. Not sure why I didn't catch it when I checked after finding the one in the MySQL file.

[Oldiesmann]

Everything completed successfully this time, though it did show Clean up "Cleanup" twice for some reason.