@Ladsgroup Can you unbreak this at least for 3rd-party-managed MediaWiki instances? I.e. provide a setting for the backend administrators to opt-in for sending emails on bot edits

This has been a long standing issue for "minor" bot edits, c.f. https://phabricator.wikimedia.org/T40874

In T358087#9727479, @Qwerfjkl wrote:

For what it's worth I've made https://watchlistemail.toolforge.org/ to send emails for bot edits. (It will only work on enwiki, ping me if anyone wants it working on another wiki).

In T183729#3878749, @Mooeypoo wrote:

What is the ramifications of this for performance, especially for big wikis like enwiki?

10 years later, this is still an issue. Consider a section like

This changed in some version, probably due to https://phabricator.wikimedia.org/T238385, and the anchor of == A B == is actually A_B now, which is also the result of {{anchorencode:A B}} as of 1.35.2.

We have MediaWiki 1.34.1.

We have UserMerge 1.10.1 (3517022).

@Aklapper: if you end up with https://en.wikipedia.org/wiki/Wikipedia:Content_forking#Point_of_view_(POV)_forks instead of https://en.wikipedia.org/wiki/Wikipedia:POVFORK in the address bar, then Javascript was not properly blocked.

But MediaWiki doesn't use foreign key constraints

when deleting a page, move the page record to a page_archive table. This is always just one row.

Yes, I was able to create a user with that patch.

Not public, I don't even know how to test bounced emails... But ensuring that running maintenance/update.php with wfLoadExtension('BounceHandler'); does not crash on PostgreSQL would be a start.

MediaWiki 1.33.1 seems to provide non-zero "parentid" in these API queries.

The version is 1.33.0, see https://wiki.archlinux.org/index.php/Special:Version

Thanks. Those two things should be seriously disambiguated...

How is this related to this change? https://phabricator.wikimedia.org/rEABF24aef037852a991c40432b37d86953d26ea45a90

@Wbm1058 That should be considered as two separate bugs, definitely not as a feature.

The patch I proposed adds a bunch of configuration options that will have to be supported forever, [...]

Apparently since MediaWiki 1.30.0 there is a $wgFragmentMode setting, but I still don't think that all issues raised in the OP have been updated accordingly (at least for the legacy mode). Could somebody review it again?

@TheDJ This ticket is definitely still valid because various parts of MediaWiki code still use invalid anchor ids. The introduction of additional unescaped anchors (like Biography,_familiy_lines) into the HTML did not change anything.

This RFC is getting kinda ridiculous. The comments requested by the OP should trigger a discussion between the OP and others, not endless modifications of the proposal by the OP based on the comments and whatnot. As a result, it is impossible to tell which points were already addressed in the comments, which comments were the motivation for the new points in the proposal etc.

The description of the advantages and disadvantages above is irrelevant to clarifying the meaning of the rev_parent_id field. You're assuming that the rev_parent_id is the only "unknown" and all other code is immutable, while you could modify other code to fix the wrong/undesired behaviour. You might even find out that the desired IDs can be computed differently, in which case using an ambiguous database field would be useless.

@GeoffreyT2000 Why did you remove subscribers?

The log events should say if the IDs were reset or not, otherwise you won't know what's happening on the wiki and debugging will be impossible without complex SQL queries like https://phabricator.wikimedia.org/T186280#4048072

Since the system actually allowed me to reopen the task myself, I just did that because the extra information requested by @Anomie has been provided.

Further, since both the web UI and the action API perform the undeletion by calling PageArchive::undelete(), it seems unlikely that one would have different behavior than the other.

It's not intended as a backup solution, but caching for bots and other client tools. And since incremental dumps are not supported, it's actually much more efficient than downloading the full dumps again and again. Plus, the synchronization period is controlled by the client, not by the administrator releasing the dumps.

Can this be reopened now?

Huh, it seems that the Special:Undelete page sets rev_parent_id correctly somehow, but the API:Undelete module always sets it to 0.

It's MediaWiki 1.30.0, AbuseFilter REL1_30 and PostgreSQL 10.1.

Please show me which PHP code sets the rev_parent_id to the ar_parent_id on undeletion.

What does "sets the revision parent id to an automatically pre-determined value based on comparing rev_id values" mean? What makes the old behaviour (whatever that is) a correct behaviour worth preserving?

I'm writing a client software which will synchronize the content of a wiki into a local database. This is useful e.g. for caching of the data for bots which don't have direct access to the wiki's database. So I think that in the end, "I want all the data" is pretty good reason :-)

Changing the direction of the sorting does not require changing the indexes so you could at least swap the direction for the default title-based ordering.

Please review and [[mw:Extension:AbuseFilter/Conditions|optimize]] your conditions before editing the filter to remove this restriction

I think that is still confusing given the current state of the AbuseFilter documentation.

The rule number 1 in the document is to make fewer HTTP requests in general, but allegedly there are 2 requests for CSS and 2-3 requests for Javascript, so I don't get why you're so strict about rule number 11.

The cost I was referring to is for the more common "plain" redirects, e.g. Foo > Bar, with no section being involved. In that case you previously just follow a link to load a page, and you now follow a link, wait for the browser to receive the redirect, wait for the browser to follow that link instead, and then the page will load.

I think we can solve this quite easily nowadays.

• In the Parser, when linking to a page that is a redirect, fetch the destination but only use its anchor (hash fragment).

@petr.matas This page says right in the first sentence:

this field is needed to allow anon users/maintenance scripts protecting a title against recreate

The protected_titles table holds essentially the same information as page_restrictions, but the structures of the tables are fundamentally different. page_restrictions holds some information specific to existing pages, which is understandable. protected_titles has some unnecessary columns:

What's interesting is that if the first paragraph after the category/language links at the top starts with a wikilink, then it is parsed correctly:

There are no custom OOjs UI themes because even if there were, it would be impossible to use them. I'll bet that even with skins, MediaWiki first enabled the configuration of custom skins and after that, first custom skin was created. I can't justify to myself spending time to work on a custom OOjs UI theme when it can't be even enabled.

Is there a plan to actually resolve this ridiculous issue? Will that be before or after the whole MediaWiki interface is converted to OOUI? From what I can tell, you are deliberately breaking any existing skin not used by the WMF and blocking the creation of new ones.

In T53736#556866, @PleaseStand wrote:

(In reply to comment #1)

So possible solutions:

• When accessed directly, do a proper 301 or 302 redirect instead of target

content with <link rel=canonical>

Not going to happen; see bug 18883. This would make it impossible to include the "(Redirected from $1)" message.

So perhaps the best we can do is to add a new "(Redirected from $1 to section $2)" message, so the user can at least know what section was supposed to scroll into view, and quickly jump to that section.

Actually, it's the stripping around named parameters that is wrong. Newlines in front of tokens that need to be at the beginning of a line should never be stripped.

Similar behaviour is on recent changes and user contributions lists, where first revisions of a page are marked with capital "N". When other (older) revisions are merged in front of the first revision, it is still marked with "N" in those lists, even though it is not first after the merge.

I don't understand why this task does not block the transition of more and more MediaWiki elements to OOUI. As the most recent example, consider how the "move page" interface looks in MW 1.26 with the ArchLinux skin (compare with 1.25 version). It looks completely out of place and considering this task is still open, I assume there is no way to fix the style from the skin part.

Related, but not the same. Category/language links are not handled equivalently to comments w.r.t. whitespace squashing. Consider the first snippet above,

First paragraph

Isn't this duplicate of T20431?

Isn't this duplicate of T20431?

Thank you for your input. The problem with generator=recentchanges is that it is affected by $wgRCMaxAge, but for the purpose of incremental grabbing the time span might be larger. Seems that I'll need to wait for list=allrevisions to make things more efficient than with revids...

All in all, there may just be a missing module like list=allrevisions to complete the functionality of prop=revisions, prop=deletedrevisions and list=alldeletedrevisions. Taking the same parameters as list=alldeletedrevisions would be sufficient for my use case outlined above. This would also likely solve T21314.

The last, https://wiki.archlinux.org/api.php?action=query&generator=revisions&titles=Main%20page, does not give an empty result.

Redirects to sections require JavaScript to work properly, see T53736.