Wow, do you seriously check valid skins just by skinname-$currentUserSkin message?
WOW, JUST WOW.
Not all skins have skinname-$skinname message nor they are required to have it.

@JTannerWMF Does that mean they won't fix this bug?

@Catrope We don't have a user named "Flow talk page manager", even after installing Flow, and auto-created pages (e.g. Template:FlowMention, Template:LQT page converted to Flow, etc.) are attributed to "127.0.0.1".

@Sethakill Looks good, but when it can be merged?

When it can be merged?

Still not fixed, same issue on MediaWiki 1.34.0-wmf.1

PS C:\nginx\web\Wiki\mediawiki\data> cd ../maintenance
PS C:\nginx\web\Wiki\mediawiki\maintenance> php update.php --doshared --quick
MediaWiki 1.34.0-wmf.1 Updater

How to reproduce:

1. Install MediaWiki 1.33.0-wmf.13 using SQLite database
2. Run update.php as soon as installation process is finished
3. Set $wgSharedDB to same as $wgDBname
4. Run update.php again with or without --doshared option

@Paladox Still shows same error. But it works well when changing like this instead of that:

		if (!( $GLOBALS['wgDBtype'] == "postgres" || $GLOBALS['wgDBtype'] == "sqlite")) {
			# Delete search index...
			$dbw->delete( 'searchindex', [ 'si_page' => $id ], __METHOD__ );
		}

When database type is SQLite, it is NOT PostgreSQL, so $GLOBALS['wgDBtype'] !== "postgres" is also true. Therefore I think that if statement returned true regardless of database type. (When database type matches one of them, another one (not equal) returns true, and they are combined with or (||))

@Paladox Could you fix it for SQLite?

@Mainframe98 Yes, it works well after adding that line, but I think SecurePoll itself should support that.

@Mainframe98 When I run update.php after inserting `case "sqlite":` in SecurePollHooks.php, following error occurs:

PS C:\nginx\web\PlavorEXITBeta\mediawiki\maintenance> php update.php                                                                                                             MediaWiki 1.33.0-alpha Updater

@Paladox There are 2 columns, si_title and si_text in searchindex table.
Note: I can't use DESCRIBE command since I'm using SQLite and it doesn't support DESCRIBE command.

Yes, there is searchindex table in my database.

I didn't set a custom value of $wgCommentTableSchemaMigrationStage in LocalSettings.php.

@Paladox I just switch to 1.33.0-alpha (which update.php works well) and ran update.php, but when I tried to delete a page permanently, still shows following error:

[dbb1ed6ad56d109713f50b7d] /mediawiki/index.php?title=User:PlavorSeol/Test&action=delete_page_permanently Wikimedia\Rdbms\DBQueryError from line 1506 of C:\nginx\web\PlavorEXITBeta\mediawiki\includes\libs\rdbms\database\Database.php: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading?
Query: DELETE FROM searchindex WHERE si_page = '331'
Function: ActionDeletePagePermanently::deletePermanently
Error: 1 no such column: si_page

Resolved after upgrading from 1.33.0-wmf.8 to 1.33.0-alpha.

@Paladox Currently I can't because of T211893.

@Seb35 @Paladox Still shows following error, even with latest version of DeletePagesForGood:

[874d008438c0368f80067450] /mediawiki/index.php?title=User:PlavorSeol/Test&action=delete_page_permanently Wikimedia\Rdbms\DBQueryError from line 1506 of C:\nginx\web\PlavorEXITBeta\mediawiki\includes\libs\rdbms\database\Database.php: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading?
Query: DELETE FROM searchindex WHERE si_page = '331'
Function: ActionDeletePagePermanently::deletePermanently
Error: 1 no such column: si_page

At that time, I was using one of MediaWiki 1.32.0 WMF build, and I'm currently using 1.33.0-wmf.8.
I use SQLite database.

@Aklapper I'm very sorry for that. I will try to change my tone.

@Liuxinyu970226 I'm warning you again, DO NOT add him as a subscriber ANYWAY. Never try to justify your crime.

Rolled back all weird actions by @Liuxinyu970226
@Liuxinyu970226, I WARNED YOU NOT TO ADD HIM AS A SUBSCRIBER JUST BECAUSE SOMEONE IS KOREAN. IF YOU CONTINUE, I WILL REQUEST TO BLOCK YOUR ACCOUNT.

Not needed.
WARNING: @Liuxinyu970226, DO NOT add him as a subscriber just because someone is Korean.

Reopened per @Gochiusa's comment.

@Gochiusa said they already ran composer update.

I just changed my caching method from WinCache to APCu, and update.php updates tables related to AbuseFilter successfully.
I think update.php doesn't work correctly when using PHP WinCache extension, and it needs to be fixed because IIS users must use WinCache for caching (but I'm using NGINX).

Still seems the problem with WinCache needs to be fixed.

Resolved.

@Daimona Exactly what you thought

And I also completely uninstalled and reinstalled PHP 7.2.10, but issue wasn't resolved.

I also tried to do "fresh install" another wiki with newly downloaded MediaWiki 1.32.0-wmf.22, but same thing happens.

@Daimona Only string in line 155 was printed.

@Daimona Which should I add, echo or die?

@Daimona

@Daimona It prints "Success":

@Daimona It just ends after printing at line 68, and yes, there is an echo in line 69 (which contains $this->mainRoleId):

@Anomie

Same when running update.php

@Daimona
String inserted in line 74 was printed, but string inserted in line 86 wasn't.

Huh? Why it doesn't print anything?

Oh no... Nothing different shows even I set error_reporting=E_ALL, display_errors=On, $wgShowExceptionDetails=true; ,$wgShowDBErrorBacktrace=true; and $wgShowSQLErrors=true;.

Also update.php shows nothing different even I add -d display_errors=1 parameter:

@Tgr Still no output...

@daniel populateContentTables.php ends with no outputs.

I found this on debug log file (temporarily enabled debug logging and ran update.php):

IP: 127.0.0.1
Start command line script maintenance\update.php
[caches] cluster: WinCacheBagOStuff, WAN: mediawiki-main-default, stash: db-replicated, message: WinCacheBagOStuff, session: WinCacheBagOStuff
[caches] LocalisationCache: using store LCStoreNull
[DBConnection] Wikimedia\Rdbms\LoadBalancer::openConnection: calling initLB() before first connection.
[DBReplication] Wikimedia\Rdbms\LBFactory::getChronologyProtector: using request info {
    "IPAddress": "127.0.0.1",
    "UserAgent": false,
    "ChronologyProtection": false,
    "ChronologyPositionIndex": 0,
    "ChronologyClientId": null
}
[DBConnection] Wikimedia\Rdbms\LoadBalancer::openLocalConnection: connected to database 0 at 'localhost'.

@daniel There is no abuse_filter_action table in database.

@daniel update.php terminates after MCR migration again even I disabled AbuseFilter:

C:\NGINX\web\PlavorEXITBeta\plavorexitbeta>"C:\PHP\php.exe" "maintenance\update.php"
MediaWiki 1.32.0-wmf.22 Updater

What I did:

1. I did "fresh install" of MediaWiki 1.32.0-wmf.20 few days ago.
2. After I finished installing MediaWiki, I installed some extension (including AbuseFilter) and ran update.php.
3. Database error occured on 'Special:RecentChanges' page because update.php doesn't update AbuseFilter-related tables.
4. So I opened this issue and removed wfLoadExtension("AbuseFilter");
5. I upgraded my MediaWiki to 1.32.0-wmf.22 few hours ago.
6. I added wfLoadExtension("AbuseFilter"); again and ran update.php (to see if this issue is fixed)
7. But AbuseFilter still not working
8. So I removed wfLoadExtension("AbuseFilter"); again

1. I'm currently running MediaWiki 1.32.0-wmf.22 (previously 1.32.0-wmf.20, I just upgraded to that)
2. There is no $wgMultiContentRevisionSchemaMigrationStage in LocalSettings.php
3. Nothing different happens when I run update.php again. AbuseFilter still doesn't work.
4. I newly installed MediaWiki few days ago, AbuseFilter doesn't work from then.
5. I currently have no debug log file.

I will check more information as soon as I can.

@Daimona MCR line is really the last - commond input shows again after that (please show updated description)

I'm terribly sorry, but it's not RevisionSlider's fault. There was a problem with WikEdDiff extension.

Resolved on MediaWiki 1.32.0-wmf.16