Ok, after being bugged by this, and digging on the code, found that $requestProtocol is basically getting the info from WebRequest::detectProtocol(), which does this:
Fri, Jun 14
I also have this problem. PHP is executed from an nginx behind a load balancer. HTTPS is terminated on the frontend, and the connection between the frontend, load balancer and MediaWiki is plain HTTP. Because of how the logic is done in MediaWiki, there's no way to get rid of the "use secure connection" link despite all pages being served as HTTPS.
Sun, Jun 9
The bot flag seems like something intrinsic to the actor, not the action, but rc_bot was left on the recentchanges table. Also doesn't appear deprecated. Any plans there?
Sat, Jun 8
I'm just downloading a release branch as anonymous (hence https and not ssh), so it shouldn't be a problem with authentication. The only relevant differences may be:
More information: This happens with all the extensions I've tried. Also, I used the same method to download extensions 1 month ago without any issues
Fri, Jun 7
Sat, Jun 1
Now External Storage works on REL1_33 (tested it), and on REL1_32 if I manually apply the patches. May be worth backporting (they're applied and work well on a production wiki on 1.32)
Fri, May 31
Sat, May 25
Note that storing all threads, or all messages of a thread, on a single slot, will make conflict resolution harder, depending on how the edit is handled (2 or more users adding or editing comments of the same thread)
Wed, May 22
May 19 2019
May 6 2019
May 1 2019
It hasn't been listed in https://www.mediawiki.org/ :(
Apr 21 2019
Hello Krinkle. I was trying to hunt the bug without noticing the latest patch from aaron after the bug was marked as resolved, so I did test with a clean empty wiki downloaded from git master and only this addition to the default LocalSettings.php that the installer generates:
Apr 20 2019
I'm sorry this is still happening
Apr 19 2019
Patch merged, I guess this can be closed
I came across another one: https://www.mediawiki.org/wiki/File:Mscatselect_1.jpg
Apr 12 2019
In fact, Special:Statistics can count a number lower than the largest revision ID. If I move a page leaving a redirect, the number of edits is incremented by 1 but the number of revisions is incremented by 2 (the row in the page for the move, and the row on the redirect page). On the other hand, log actions that don't create new revisions, like deleting or restoring a page, each add 1 to the "number of edits of the wiki".
Apr 11 2019
If you have the XML dump, you can use grep, gawk or something to count the number of revisions present on the XML, and compare with the dump (it should be the same)
Apr 2 2019
grabLogs (and the grabbers suite in general) expects an initial empty database and to mirror everything using the same IDs on both wikis. I'm not against making this configurable, but it should be the opposite: only import them with user id = 0 if explicitly requested.
Mar 17 2019
Looks like easy according to T26575#1746030
Mar 14 2019
Maybe if we're afraid of too many links next to each header, we can consider to have only two: the edit link, and a "more..." link, that when clicked could expand to a list of actions (link to that section, share, copy link for use on an edit...). Even the edit link can be made expandible if we have the dual edit link (wikitext edit, visual editor edit). Just an idea.
Mar 13 2019
With respect to the files I could change the name, upload a new version, create a new one, delete, but the transfer of files to a different namespace I could not do it because it returns the message: "Unable to move the file to a space of names that is not for files. ", that still do not know how to solve, reason why I can not assure that that test works.
Mar 5 2019
Another instance of this error on 1.32: Topic:Uvchvjq4moxr5prh
Mar 3 2019
The debug log should be used to capture the events when you get the error. The error for you happens when undeleting a page. However, the log you posted is capturing a page view of the "Main_Page".
Mar 1 2019
In addition to this externally-shareable link, I think it would be great to also have a wikilink.
i.e. Provide two links the users can copy:1. [https://example.com/wiki/Example_page#Example_section] 2. [[Example_page#Example_section]]
Feb 28 2019
So what's going to happen to these null revisions? Will they just get deleted? What happens if the move is reversed; should those deleted null revisions get automatically restored, or should a sysop have to come along and restore them?
Feb 24 2019
I've done some edits and it seems to work fine. Many thanks!
Feb 22 2019
Feb 20 2019
Feb 17 2019
Feb 10 2019
Ok, I've tried a new 1.32 install and I'm able to reproduce the problem.
Feb 8 2019
/mw-config/index.php?page=Upgrade should be accessed only when an existing MediaWiki database exists, but you said that "there's no LocalSettings.php because it's a new installation". Can you clarify what steps you did on the install wizard to get to that page?
Feb 4 2019
Feb 3 2019
Jan 31 2019
Jan 11 2019
In fact, I have ExternalStore on my wiki configured, but AbuseFilter stores the reference to the external store to the text table. This method wipes the reference to it on the text table, but doesn't remove the external store data (T213480)
Jan 10 2019
Jan 8 2019
This happened at home (no proxy, etc. Normal ADSL). I'm using Firefox on linux (OpenSUSE). When this happened (page taking too long to actually display anything), I copied the URL that was causing the problem and tried to get it with curl on command line, which are the pastes attached to the bug.
Jan 6 2019
Jan 2 2019
Dec 30 2018
Ok, I wrongly assumed that the user who asked for help in my talk page, was using a real example from other pages where this happened, but it appears not. Sorry for the confusion.
I verified that this would fix the problem by opening https://de.wikipedia.org/wiki/%C3%84gyptische_Hieroglyphen in Firefox and adding the above CSS rule -- it fixes the rendering to the desired version.
Dec 24 2018
Looks like Esander's change is not the problem here. Even after returning the CSS, it doesn't display on the same line. Looking at the rendered HTML, hieroglyphs are rendered on a table that's outside of the paragraph text (paragraph <p></p> is closed before the hieroglyph).
Dec 20 2018
I don't think this should be done. A 404 means the website is no longer there, but a 500 could be a temporary error. Maybe reduce the frequency drastically (from 6 hours to 1 week?)
Dec 19 2018
Dec 13 2018
Interesting...okay, so something like this might make more sense, however:
- in some cases the panel itself will need to be scroll-able (assuming we don't want to make it taller - I imagine this would frustrate people)
- in most(?) cases the page itself will also be scroll-able. It does seem like we could remove the Wikipedia page footer from the diff views so at least shorter diffs don't result in a scroll-able page.
Dec 7 2018
Oh, that patch landed on the 1.31 branch, it's not present on 1.30. I'm using the 1.31 branch on MediaWiki 1.30 without problems, it's safe to upgrade this extension.
What version of LinkSuggest are you using? This was fixed on rELISa72ee43c41e98fedb510bbad6262f5a2d28ebfb0. Try using the master version of the extension.
Dec 4 2018
I'm going to re-propose this:
Dec 3 2018
Please at least add a class to these links. Currently I would like to use a custom css style on them and I don't see how I can.
You should be able to use the autocomment class once my first patch is deployed. Given the summary /* External links */ removed bogus entries, the HTML will look like:
<span dir="auto"><span class="autocomment"><a href="#External_links">→External links</a>: </span> removed bogus entries</span>.
Dec 1 2018
An option would be to just change the style. But for this, please make this section link have it's own CSS class, to allow both MediaWiki and users to style it differently than other links.
Nov 30 2018
Ugh, just found this problem. It wasn't breaking, but nukePage was taking a lot to delete one single page, and looked at the source code to see why.
I'm not sure what we should be doing about nested links, do you have any suggestions on how those should be handled?
We should just remove them from HTML markup, in my opinion.
Nov 29 2018
Adding /* Header with a [[Help:Links|link]] */ to a summary gives funny results
Nov 25 2018
We encounter a new error in MW 1.31.
The active user number droped from 1.3k to 50 after php /var/www/wiki/maintenance/rebuildall.php .
Neither php maintenance/initStats.php --active --update nor php maintenance/UpdateSpecialPages.php fix the number count error. However, the Special:ActiveUsers page do show all 1.3k editors' name at the same time.
$wgMiserMode = false / true doesn't seem to affect the active users number anymore this time. It's always 50.
Nov 19 2018
This won't work for HTTP caching.
Nov 9 2018
Nov 4 2018
Note that the change you mentioned (https://gerrit.wikimedia.org/r/445014) does remove the MFResourceLoaderParsedMessageModule class, which is already missing in your installation. This means it's either backported already, or you downloaded master instead of REL1_31
Oct 14 2018
Also, the counts on the revision table may also give higher results, because page moves count as 2 (one revision on the source page, and another revision on the target page). Ideally this extension should use a table with counts for each namespace (see also T173775)
Sep 30 2018
Sep 26 2018
Note that an undo may also be desirable for your own edits, in case you make an edit and then you realize something went very wrong.
Sep 18 2018
I'm confused. Deployment of wmf.22 is supposed to happen today https://www.mediawiki.org/wiki/MediaWiki_1.32/Roadmap but it hasn't happened yet on mediawiki.org, which is on .20, but the problem seems to happen since today.
Sep 17 2018
There's now MediaWiki:Loginprompt. I'm boldly closing this.
Aug 27 2018
Hmmm, I have to investigate. I can't reproduce this on the test install. Closing as invalid for now
Aug 26 2018
Submitted as https://gerrit.wikimedia.org/r/455402
If fixing this is not quick and easy, it may be worth doing T158620
Aug 25 2018
The todo CHECKME/FIXME is right. The message contains a $1 parameter that isn't substituted, which means strpos will not find anything. gj. The message should substitute the parameter and it should match (using a simple equality comparision). There's another flaw, however: It updates the stats for the user performing the edit. However, what if the blog is updated by a different user which adds its own category?
Aug 22 2018
I think this has been fixed somehow (or maybe because the feature that caused the error has been disabled in rEBLO08eb64a9a), because in my tests I haven't encountered this problem yet.
I don't think this is a duplicate, since users may prefer to receive plain text emails.
Aug 21 2018
This patch is obsolete. See F25204900 instead
Updated patch to account for no match found (looks like the previous one was only visible for me?)