@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...

In T170249#3442986, @zhuyifei1999 wrote:

In T170249#3442161, @SpookyGhost8 wrote:

Since you mentioned that uploads are "edits" rather than uploads, you can target file uploads using the following

This task is about testing in retrospect, not in prospect.

Since you mentioned that uploads are "edits" rather than uploads, you can target file uploads using the following

In T165124#3312438, @Nemo_bis wrote:

does anyone besides the owner of that page really need to edit it

Yes, collaboration in user space is very useful on Wikimedia wikis and absolutely necessary in a number of cases (without it, we'd often have to give up on the user, i.e. block or disgruntle them, making our wikis less inclusive). In particular it's important:

• to help newbies with the syntax and content of their user pages;
• to help users improve their sandbox pages before they get into main namespace (if they choose to go the sandbox way);
• to collaborate on smaller personal projects which are not felt appropriate for project namespace but interest more than one user;
• to fix and maintain content of user pages and subpages of "important" or inactive users who don't manage to do it themselves;
• to keep archives on discussions functioning (e.g. fixing broken links or broken wiki syntax), since a lot of discussion relevant for the community or for articles happens in user talks;
• to take care of certain inappropriate content on user talks by other users, such as spam;
• etc. etc.

There is practically no way this can ever work on Wikimedia wikis, unless perhaps it's some special feature which only admins can enable (and disable) for users. In core it could be implemented with two feature requests: one to allow page protection to apply only to a list of users, and another to have page protection apply to all subpages of a page (with some restrictions). Otherwise, it needs to be an extension.

In T165124#3309873, @Nemo_bis wrote:

It's not about "priority" but about avoiding to completely break collaboration on wikis. For instance, if I can't edit a userpage I have problems with, my only option is to ask administrators directly (without the user even knowing) to delete it.

In T165124#3309389, @Nemo_bis wrote:

The current summary is clearly a WONTFIX: random users cannot decide the editing permissions of an entire namespace. I suppose you mean that each user should be able to restrict their own user page, talk page and subpages thereof? (Which is not gonna fly anyway, but feel free to beat the dead horse.)

The error was in relation to a rewrite rule in .htaccess

While a private blacklist under user preferences would be ideal, upon leaving a message the user would find out either by checking if message was left or a warning. Now it could be implemented as a fake edit but...any determined user would just start abusing account creation making this useless along with the worst case scenario of a proxy being involved.

running MediaWiki 1.28.2, I can still reproduce the problems as further detailed below.
Link to wiki: http://www.hypoverse.com/wiki/Main_Page I have reopened creating accounts, let me know so i can grant access to creating public test filters.
I have tried to create a test filter with conditions

action='edit'

marked checkboxes

In T165552#3277469, @matmarex wrote:

The hookEvent call and the warning is coming from the OnlineStatus extension you have installed.

In T165552#3275954, @matmarex wrote:

I wanted to check it out again but your wiki (http://www.hypoverse.com/) seems to be down…

@Aklapper actually logging in causes it with or without any JavaScript in common.js. I now deleted MediaWiki:common.js and there is no other JavaScript running. Hence I reopened this task for bug consideration.

In T165552#3272078, @matmarex wrote:

I don't see any warnings when viewing the site.