Apr 14 2021
Jan 20 2021
A page is orphaned when it is not linked from anothers page content (or from within other pages). Links from navigations typically not treated as "used" or "linked" as that is a implemantation detail of the software, while an actual link from another page is a detail by the user of the wiki.
Jan 19 2021
Do you think then that https://en.wikipedia.org/wiki/Special:WhatLinksHere/Main_Page should contain a list of all pages on the wiki (and similarly for other pages linked in the navigation)? I think it would be contradictory if it didn't.
Jan 18 2021
My point is that I don't think it does qualify under the criteria as it is linked to via the navigation that is present on every page.
Jul 16 2020
As an extension writer, the purge action is massively, massively useful. It is not uncommon whilst working on the extension, to mess-up rendering, and without an easy way to purge the page, you're a bit stuck.
Jul 18 2019
Jul 12 2019
That may be true of a general abstraction layer, but we're talking about a specific abstraction layer for MediaWiki. Therefore, by definition, it is the choice of the application.
Jun 9 2019
This is getting somewhat off-topic, but:
Jun 8 2019
Jun 5 2019
Another note: MSSQL has been broken for a while now (Look at my above comment)
Mar 30 2019
Further to my above comment, about my personal use-case, I have found that there are public links - even from prominent pages on mediawiki,org - that are currently dead.
From my perspective, tags are fine.
Mar 27 2019
Mar 14 2019
Maybe I'm confusing things - when I use 'add existing panel' then all the old versions of the panel are still listed, currently. But I don't know how that maps to the suggested workflow - I don't really understand the difference between a query and a query panel.
Sounds reasonable (taking you at your word - personally, I can't think of any reasons why immutable search results are a good idea).
Mar 7 2019
Resolving as complete. Thanks for your help, @Legoktm.
Mar 4 2019
Feb 21 2019
Why was this declined?
Feb 20 2019
I'm sorry, but that is a totally unacceptable answer.
Feb 19 2019
Feb 16 2019
I notice that 1.32 has now been release, but this bug has not been fixed. That means extensions will be broken without any upgrade path being supplied.
Oct 17 2018
Oct 12 2018
Adding to 1.32 release, as it is imperative that there are upgrade instructions before the hook is formally removed.
Please, please, please can you make sure that T178844 is resolved before 1.32.0 is released.
Aug 16 2018
Hi Reedy - sorry not to reply to this sooner. I will take a look at the example you've posted (which I would never have found on my own!) and see if I can get things working.
Aug 6 2018
That seems like a poor design decision. It means there is no way to correct mistakes or adapt to changes.
Aug 4 2018
There is also this RFC related to abstract schema definitions. Let's call it Proposal #3 (even though the page has been around since 2012): https://www.mediawiki.org/wiki/Requests_for_comment/Abstract_table_definitions
Jun 15 2018
Any word on this? This is preventing me from upgrading my extensions to support the latest MediaWiki versions.
Jun 13 2018
Jun 1 2018
Removing myself - I created the original manual page for this setting, but all the information was drawn from other sources. I have no direct knowledge about this setting, so can't help with this.
May 15 2018
As mentioned in T190363, this is also really important for extension writers who want to support more than the current latest-and-greatest versions of MediaWiki. We need to have an easy way to locate old releases in order to check whether a given feature we would like to use was supported.
Apr 4 2018
The way I see it, there are three areas of interest (which overlap slightly):
Apr 3 2018
Trying to fit all work by all people into a single workflow seems counterproductive to a goal of mine which is to make technical contributions easier
Apr 1 2018
Depends what you mean by 'different projects'. If they include core extensions, or tightly-coupled things like Parsoid, then it adds up to a lot of inconvenience!
I think this is a great idea. There should be clarity and consistency in how/where development takes place.
Mar 22 2018
Mar 21 2018
Mar 10 2018
Feb 2 2018
WikiDB is now very mature, and I think it covers everything in the original request, and more besides: http://www.kennel17.co.uk/testwiki/WikiDB.
Jan 13 2018
Apologies if you found my comments condescending. That was not the intention.
Jan 10 2018
Oct 23 2017
Oct 14 2017
May 14 2017
May 13 2017
Also note: gerrit is getting a new ui with gerrit 2.14 which has been released. They are calling it polygerrit and can be viewed at https://gerrit.git.wmflabs.org/r/?polygerrit=1
This should be declined as we will eventually go with differential but that's currently on hold.
Mar 22 2017
Feb 10 2016
Feb 7 2016
PS - What happened here:
One of my extensions seems to be triggering this, and I have no idea what to do about it.
Jan 20 2016
Nov 27 2015
Well, I just Googled for Wordpress, and they have a pretty great requirements page: https://wordpress.org/about/requirements/
Your stats are out of date, FWIW according to Wikipedia.
Nov 26 2015
@hashar, support for older PHP versions by various operating systems/distros/other apps was discussed in a fair amount of detail.
The number of attendees was half the number of subscribers here.
I'm very disappointed that the decision seems to have been made without any regard for any kind of usage statistics, beyond WMFs requirement for 5.5 as the upper bound.
Nov 19 2015
Nov 18 2015
I'm not sure they are duplicates. I was about to add the dependency on T86081 that comes from that bug, but that ticket shouldn't block a decision being made - it should just block actually putting the decision into action. If we decide to drop 5.3 there will be a requirement to finish the internal WMF migration before actually adopting this as policy (updating docs, allowing > 5.3 code into the codebase, etc.), otherwise things will break.
Out of curiosity, is there anything really evil about traits or are they just out of scope for this RfC?
I think WikiApiary is a good start for stats, but I'm not sure whether it should be the only data source that is considered.
Aug 12 2015
We want to diminish the risk of confusing them by mixing the content relevant to the with the rest of mediawiki.org.
Jul 28 2015
I agree with QGil and Ricordisamoa - skin per page is completely contrary to where consensus seems to be going. You might just about get sufficient support for a separate skin for the namespace as a whole (though there is quite a lot of opposition, too), but I doubt skin-per-page is going to be approved by the community, based on comments made so far (assuming, of course, that the MW community is going to be listened to).
Jul 6 2015
I don't see the benefits to tying ourselves to Vector for this well delimited namespace in mediawiki.org.
Jul 3 2015
I think that splitting these conversations up is a very sensible idea.
Jun 30 2015
Hi - yes, I know that post. I agree with some of it.
Jun 16 2015
A couple of points: