I can confirm the updated patch worked without error. You can issue a request to merge the patch. Thanks again for taking a second look.

I did discover a workaround for this bug, make modifications to includes/user/ActorStore.php
import use MediaWiki\User\UserRigorOptions ;

tested the patch, unfortunately did not resolve issue. The failure occurs on namespace 2 [User].

I have tested the patch and confirm it resolves the bug report.

@Ciencia_Al_Poder no errors though I did have to forcefully skip revision 95686 - duplicate entry in slots table. Thanks for all the help.

ok, running the script again. Will update on result.

another workaround that probably works better is this instead of skipping all invalid or null parent ids -> creates Error pages

function processRevision( $revision, $page_id, $title ) {
	if ($page_id !== bad_index) {
		$rev->setPageId( $page_id );
		$rev->setParentId( $revision['parentid'] );
		$this->revisionStore->insertRevisionOn( $rev, $this->dbw );
	}
}

The MediaWiki version of the remote target wiki is 1.37.6.

Here is the commit that's blocking update.php from functioning as normally expected: https://github.com/wikimedia/mediawiki/commit/cf39a40f164799ffed328a5b8d7a42823441f507

@DannyS712 @Xover
It would seem that this proposed extension should just perform the functionality. This will likely require installation of Extension:FlaggedRevs or implementing a similar lightweight functionality for the new special page.
As for handing merging, I propose using Special:MergeHistory to combine the specific revision approved for merge into the original page in MediaWiki namespace. Since this would lockout editing the mediawiki namespace pages, there would be less conflicts. This would retain the historical revision and edit summary in page history as attribution. As for what happens to the forked page to user subpage, that's for the wiki community to handle as their policy.
When forking, there should be some coordination to avoid edit conflicts or loss of code functionality.

• Forking user is responsible for maintaining up to date with original page to avoid overwrite. if it does overwrite, previous revision should remain in page history.

As for the rights based access issue

• Handled by restricting access to the special page with a new user permission.
• When a user who is allowed access to the special page, submits a fork or merge request, extension will check if the user has all these permissions: editinterface, editsitecss, editsitejs, editsitejson. Instead of relying on default usergroups [Interface Administrator], this would allow anyone to use the extension.

@Daimona Is there a particular trade off analysis for the possible chance of the filter getting throttled within the 24 hours it takes for the filter age to reset? Why can't the filter age just be reset as soon as the job in the job queue is completed?

@Daimona Why is there a need for 24 grace period? I am unsure what suitable solution exists 

@MrPie5 I agree on a new user right to further restrict who can mark a filter exempted from throttle; especially since this allows further protection to avoid malicious actors.

@Huji in my above example, it impacts account registration. Overall, that is always a risk and why access to abusefilter should always be strictly limited to only the trusted and those who understand & capable of writing Regular Expressions (regex). Access to abusefilter at WMF is rather strict and chances of that particular risk is low, it seems the risk is for independent third party installs? Those with access to abusefilter and logs should be keeping a regular eye on things and reviewing any new filters created. Access is a privilege of trust and responsibility, all should be acting as a check on each other.

@Daimona Hmm I just thought of an alternative idea/proposal. What if we could on each filter have a checkbox to disable throttling? Instead of having to worry about throttle age, there could be a selection on the specific filter to just ignore throttle conditions.

@Jdrewniak it appears there is confusion regarding this bug ticket by QA/web reading team. I have a wikifarm set up consisting of 9 wikis, the issue is occurring on 4 wikis which is ~45%. I followed installation steps for MinervaNeue skin and Extension:MobileFrontEnd, this should not be occurring on latest mediawiki stable - 1.33.1 (a security release for 1.33)

wait, you want me to modify mediawiki core files?

skinStyles/mediawiki.ui.icon does not exist, I am still confused what is causing the drop down button to remain hidden for 1.33.1 (security release) on Google Chrome 78. Is it possible that Google made a breaking change regarding MinervaNeue?

Checked the submitted patch with a +2 in code review yet unable to locate the file referenced by patch....skinStyles/mediawiki.ui.icon/mediawiki.ui.icon.less
I would like to have a working mobile skin for current stable release instead of waiting 2 releases

@Jdrewniak
This is occurring on Google Chrome 78 on Windows 10. No impact in Mozilla Firefox, button displays.

@Masumrezarock100 no notification icons are showing up despite Echo installed

It appears after running update.php multiple times, the tables are now created...not sure what happened

It appears after running update.php multiple times, the tables are now created...not sure what happened - resolved issues for both Abusefilter and Checkuser

though this doesn't explain why when running update.php that the required tables are not being created. whether I have a single wiki or a group of wikis shouldn't make an impact...

Is it possible that update.php is forgetting about the actor table migration?

I can always just directly run the sql commands to create the tables required.

@Daimona I tried alternative 1, it sort of worked - its showing up in special:version. database errors remain...I removed all of the abusefilter tables from all the wikis installed and ran update.php again. I am trying to install on my own wikifarm, doubt that would complicate things. using alternative equivalent to MySQL.

@Nux Wouldn't a simply way to utilize another namespace where the script or gadget is copied too and anyone that is authorized to make changes only touch that copied version? This way there wouldn't be any merge conflicts when merging back upon reviewer approval and the scripts/gadgets in MediaWiki namespace would be locked as production - live for viewers/users.

If we allow forking these to user css/json/js pages, when merging back there could be edit conflicts considering another edit could have been merged and the user didn't pull. How would you suggest keeping a fork to user namespace be kept up to date, might need to keep track of diff changes - this gets complicated? Sending the fork to another namespace and keeping it in one location is much better. I am suggesting a simpler system due to these projects not being finished ie partial blocks was meant to become multi-blocks.

@JEumerus clarified my side note, yeah it was confusing. I was meaning to refer to how js, json, css pages under MediaWiki were split out, did not mean to suggest that EditInterface was a new permission.

@DannyS712 isn't that the current system that Wikipedia already uses?

thanks for letting me know about T205482. Given that Flagged Revs gave me an internal error (VM1844:1 Uncaught TypeError: Cannot read property 'addPortletLink' of undefined) for trying to add in MediaWiki namespace, I do not think that placing effort and time into solving T205482 is worth it.

I know that a while ago it was mentioned that Extensions Flagged Revs + Code Review could be a potential solution. I tested yesterday on a small wikifarm and Flagged Revs does not work on the MediaWiki namespace at all, pretty sure I configured correctly. I did not grant myself the autoreview permission and did not use any of the default user groups. Any valid or invalid javascript added to MediaWiki:common.js went live immediately. Trying to hardcode "NS_MEDIAWIKI" into extension array resulted in an internal error at Special:UnreviewedPages. Extension:Approved Revs explicitly says that it doesn't work on MediaWiki namespace.

In T183099#4199438, @Daimona wrote:

This might be a good reason to provide this feature which wasn't mentioned in the other task. I'll try to see if I can send a patch.

"enforcement of abusefilters", I mean to actually filter new threads/replies to WikiForum or new comments in MediaWikiChat.

@Mooeypoo Task T189391 claims that its being blocked by this one and I do have interest in working on the task.

@Mattflaschen-WMF is this task still locked for Google Summer of Code or Outreachy? Asking cause its preventing others from working on T189391

Now under MediaWiki 1.29.2, FireFox console tells me

Exception in module-execute in module ext.onlineStatus:
ReferenceError: hookEvent is not defined ReferenceError: hookEvent is not defined

If I disable Extension:OnlineStatus, it goes away

Yes, this is a feature request for a button that allows quick reactivation of a disabled filter due to safeguards being exceeded.

updating to mediawiki 1.29.2 and PHP 7.0 resolved all issues, including Extension:WikiForums also causing similar internal error upon upgrading mediawiki from mediawiki 1.29.1.

Ok i'll look into getting cache set up properly

I disabled extensions MassMessage, VoteNY, Comments, BlogPage and now the internal server error went away...any idea why this came to be? Everything is fine now.

The 500 internal server error occurs if I simply try to visit the wiki website, it just instantly crashes. Disabling a few other extensions didn't help. Didn't install that many extensions

I ran a strace command, It appears that the application crashes while trying to do a number of sequential INSERTs into the database. I have attached the output file.

Its being converted to extension registration per T152865. The segfault/internal 500 error happens upon enabling the two extensions in question, are you running master branch of AbuseFilter and SocialProfile? Keeping either AbuseFilter or SocialProfile enabled is ok, but not both. This is for mediawiki 1.29.1.

64 bit Debian Linux running Apache 2.4.10
PHP 5.6.32 (cgi-fcgi)
SocialProfile version 1.13 (ede9c86) 02:46, 4 November 2017

The exact error after enabling the extension is that the PHP interpreter crashes (segmentation fault).
server logs:

This is an interesting idea and I support this since currently the method of delete is nuking from the SQL database resulting in complete loss. In order to restore, this requires to first store deleted items in a temporary SQL table for later restore.

apparently not using mw.load.loader() to execute scripts via index.php and just simply hosting all the code inside mediawiki:common.js apparently doesn't throw the above errors even when denied writeapi & Extension:Lockdown is used.

@TBolliger
Splitting this into two tasks is a good idea as they are different enough. Allowing admins to remove offensive content, vandalism and leave talk page message by default is expected. yes, for now admin request would have to do until this is built.

another possibility outside of Gadget 2 is a test wiki where any JS, CSS or Lua is tested and then moved over to the main WMF wikis after having a +2 code reviewer approve merging it over. The MediaWiki namespace is mostly interface messages, restricting JS & CSS editing to new permissions might make this safer as well; editusercssJS was split into separate permissions though seems to be limited use cases (someone breaking personal js/css).

There also is Extension:CodeReview but status is historical reference, perhaps reopening that for development would be a potential solution?

Would it be more secure to possibly add in a few more custom user permissions such as splitting editinterface into editJS and editCSS with also adding in restrictions for template namespace and editLua for Lua? I know that edituserjs&css was split into edituserjs and editusercss. This way the mediawiki namespace would contain the interface messages; all javascript is restricted to .js and users with editJS, all css is restricted to .css and users with editCSS; all lua modules restricted by editLua; possibly restrict templates to editTemplate. Just a suggestion...