Sep 15 2019
The version is 1.33.0, see https://wiki.archlinux.org/index.php/Special:Version
Sep 3 2019
Thanks. Those two things should be seriously disambiguated...
How is this related to this change? https://phabricator.wikimedia.org/rEABF24aef037852a991c40432b37d86953d26ea45a90
Mar 16 2019
Feb 10 2019
@Wbm1058 That should be considered as two separate bugs, definitely not as a feature.
Jan 14 2019
The patch I proposed adds a bunch of configuration options that will have to be supported forever, [...]
Oct 13 2018
Oct 11 2018
Sep 10 2018
Aug 18 2018
Aug 14 2018
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?
Aug 2 2018
@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.
May 30 2018
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.
Mar 27 2018
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.
Mar 23 2018
@GeoffreyT2000 Why did you remove subscribers?
Mar 14 2018
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
Feb 12 2018
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.
Jan 22 2018
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.
Jan 21 2018
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.
Jan 19 2018
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.
Jan 18 2018
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?
Dec 21 2017
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.
Dec 20 2017
Aug 31 2017
Please review and [[mw:Extension:AbuseFilter/Conditions|optimize]] your conditions before editing the filter to remove this restriction
Aug 29 2017
I think that is still confusing given the current state of the AbuseFilter documentation.
Aug 9 2017
Jun 29 2017
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.
Jun 20 2017
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).
Jun 12 2017
Sep 24 2016
Sep 20 2016
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:
Sep 13 2016
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:
Jul 10 2016
Apr 12 2016
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.
Mar 6 2016
Mar 3 2016
Feb 14 2016
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.
Jan 13 2016
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.
Dec 22 2015
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.
Oct 5 2015
Related, but not the same. Category/language links are not handled equivalently to comments w.r.t. whitespace squashing. Consider the first snippet above,
Oct 4 2015
Isn't this duplicate of T20431?
Isn't this duplicate of T20431?
Sep 27 2015
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.
Sep 23 2015
Aug 24 2015
Jul 8 2015
Feb 21 2015
Feb 9 2015
@bd808 Unfortunately I have accidentally hit Enter while submitting the report, which has saved it prematurely...