As explained in previous comment, you need to run namespaceDupes.php
Mon, Aug 19
This is indeed a problem with MultiHttpClient and http/2 requests.
Thu, Aug 15
Issue solved for the examples provided
Mon, Aug 12
The update.php script breaks when upgrading from ancient MediaWiki versions. See T230317: Error: 1146 Table 'valid_tag' doesn't exist when upgrading from an ancient MediaWiki version
Thu, Aug 8
When using IPv6 notation to represent a IP and a port number, the notation is something like [::1]:80 (brackets to separate IP from port number). Maybe some server implementations add the brackets to the IP address because of that.
Mon, Aug 5
Sun, Aug 4
I've found a funny bug/feature: curl stores cookies in a file on the current folder, and uses it regardless of the login or api URL. This means, once we've successfully login once, curl stores the session cookies, and you can run the same script without providing username and password and you'll be still logged-in. In fact, this produces another bug when running against a remote wiki that uses a recent MediaWiki version
This is being done in https://gerrit.wikimedia.org/r/512539
Sat, Aug 3
I've raised it to 10, but I can't say whether it's a sensible default value... Maybe 5?
I'm going to be bold and reopen this bug. I've created the section Emergency throttling explaining how it works, and also how can a filter be randomly disabled, just because 2 edits hit the filter close after the number of profiling action reaches $wgAbuseFilterProfileActionsCap.
Thu, Aug 1
Tue, Jul 30
You should always clear any pending jobs (by running runJobs.php) before performing an upgrade
Fri, Jul 26
Mon, Jul 22
Nope. Thanks for the reminder. I'm closing this for now
Jul 9 2019
- Do we want to show it even when a reason has been selected from the dropdown?
I feel like if a Reason is selected, then the extra field should be disabled, no? Shouldn't it work like the "Other time" extra field?
Jul 8 2019
Jul 3 2019
Jun 26 2019
Jun 24 2019
Jun 21 2019
Ok, thanks for the update. I only need a read-only access to the repos, so I'd have to live with the github mirror...
Jun 14 2019
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:
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.
Jun 9 2019
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?
Jun 8 2019
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
Jun 7 2019
Jun 1 2019
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)
May 31 2019
May 25 2019
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)
May 22 2019
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.
*I'm showing the scroll bars to remind us of what the current result would be
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>.