Project:Current issues

Jump to: navigation, search
This page is for discussing issues related to site. To get help with MediaWiki software, ask on Project:Support desk.
An archive box Archives 

Current issues archive overview

Start a new discussion


Thread titleRepliesLast modified
Failed to mark for translation111:36, 1 February 2015
[RESOLVED] Include API: and Skin: in default search namespaces821:36, 13 January 2015
Special:Translate not working117:48, 9 January 2015
[RESOLVED] password115:31, 8 January 2015
Seach to a specific page/word013:42, 2 January 2015
Extension:CodeReview1018:56, 19 December 2014
[RESOLVED] MediaWiki:Titleblacklist720:29, 16 December 2014
Installation guide consolidation611:52, 16 December 2014
[RESOLVED] User:MisterLambda was blocked in error207:06, 15 December 2014
Index119:09, 6 December 2014
What spam are our captchas stopping?009:02, 5 December 2014
CSS not working in Hebrew Wikipedia010:26, 26 November 2014
Need to change oauth consumer redirect URL021:02, 22 November 2014
Recategorisation of MediaWiki settings categories, discussion on restyling Template:CS cat header015:01, 22 November 2014
Using Project:Support_desk for emergency bug reporting during the Bugzilla - Phabricator migration105:33, 22 November 2014
Recurring spammer Hughclayton120:26, 3 November 2014
Replace full protection with FlaggedRevs1116:54, 29 October 2014
Wikimedia Engineering reports319:19, 28 October 2014
Toolserver wiki211:04, 19 October 2014
[RESOLVED] rapid-fire vandalism from Ekkentros109:19, 14 October 2014
First page
First page
Previous page
Previous page
Last page
Last page

Failed to mark for translation

Failed to mark Help:Magic words for translation:

Function: MessageGroupStats::clearGroup
Error: 1205 Lock wait timeout exceeded; try restarting transaction (

Too many translation units?

Shirayuki (talk)07:24, 25 January 2015

Still happening... please file a bug, hopefully the WMF DB admin will help.

Nemo15:01, 26 January 2015

[RESOLVED] Include API: and Skin: in default search namespaces

It seems the default search namespaces on this wiki haven't been updated for some time. Just now I searched for apidisabled in the search box, and only got 1 result, which was some release notes page. What I really wanted was API:Restricting API usage.

Currently the following namespaces are in our default search namespaces:

  • (Main)
  • Help
  • Manual
  • Extension

I propose that we add the following namespaces:

  • API
  • Skin

Any comments?

This, that and the other (talk)05:39, 5 January 2015

Good idea.

I believe you need to log a ticket in the bug tracker for this kind of change, as it requires modifying the site config files.

HappyDog (talk)09:44, 5 January 2015

+1 Should be an easy change with a lot of benefits.

Florianschmidtwelzow (talk)12:54, 5 January 2015

YesY Done Api: and Skin: are now in the default namespaces (see Task T85807).

Florianschmidtwelzow (talk)20:22, 6 January 2015

Yep, makes sense; let's also include them in content namespaces if we didn't yet.

Nemo14:47, 6 January 2015

+1 (they aren't content pages atm), if there is enough content to be helpful for search, it should be a content page.

I just read it now, so that would be a new change/task :)

Florianschmidtwelzow (talk)20:21, 6 January 2015

Tracked in Task T86391

Florianschmidtwelzow (talk)01:30, 10 January 2015

YesY Done by Reedy :)

Florianschmidtwelzow (talk)21:34, 13 January 2015

Special:Translate not working

Starting from yesterday morning, I cannot use the Special:Translate. When I clicked the strings, nothing happens. This only occured if I'm logged in.

Here's the error found in the browser console:

TypeError: mw.config.get(...) is null" TypeError: mw.config.get(...) is null
Pelacakan susunan:
util.getUrl@ line 4 > eval:9:119
getTarget/targetPromise<@ line 4 > eval:53:1245
Uncaught TypeError: Cannot read property 'replace' of null
(anonymous function)load.php?debug=false&lang=id&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150107T1…:65

Anyone having this problem too?

William Surya Permana (talk)12:07, 9 January 2015

Yes, but not everyone. Thanks for reporting.

Nemo17:45, 9 January 2015

[RESOLVED] password

Told my password was wrong, I reset it. Got new temp PW in email. Trying to log in with that. being told my password is wrong., 22 December 2014
Edited by 0 users.
Last edit: 18:28, 22 December 2014

finally able to log in. Nevermind

Dbrezenoff (talk)18:28, 22 December 2014

Seach to a specific page/word

A thread, Thread:Project:Current issues/Seach to a specific page/word, was moved from here to Project:Support desk. This move was made by Ciencia Al Poder (talk | contribs) on 2 January 2015 at 13:42.

I don't think this deprecated function should still be installed at Why not move all data of Special:Code to Phabricator and remove this extension from

GZWDer (talk)08:14, 27 September 2014

Won't that create a lot of dead links?

If it can be done in a way that (a) doesn't break the web; and (b) means the content is still fully accessible then I don't have an objection, however if either of these is not possible then I strongly urge that it not be removed.

Perhaps a simpler answer would be to remove code-reviewing rights from everyone, so the pages remain but are no longer editable by anyone?

HappyDog (talk)08:46, 27 September 2014

Would you like to work on the migration code to move all data of Special:Code to Phabricator?

AKlapper (WMF) (talk)14:03, 27 September 2014

Not really, no.

HappyDog (talk)11:03, 28 September 2014

Oh, I didn't mean you, more the original requestor and her/his question "Why not move all data". :)

AKlapper (WMF) (talk)13:47, 28 September 2014

Should have paid more attention to the indentation!

HappyDog (talk)13:57, 28 September 2014

Special:Code is very pretty and useful and it shouldn't be replaced without a clear benefit. In fact, some days ago I wanted to reply to a thread and I couldn't because it was frozen: which is okay and makes sense, but a bit against WikiNow.

Nemo20:45, 27 September 2014

I also have no time to write the code. However, is it possible to move data after data from gerrit is moved?

Maybe we should remove coder and svnadmin group from It currently does nothing about CodeReview (though coder sill have autopatrol right). Extension:CodeReview can be on hold. But I still concern that keeping CodeReview is a risk if there're bugs in extension and this probably can be used by hackers.

GZWDer (talk)14:32, 28 September 2014

Phabricator will not even have comments from gerrit: I'd rather support importing gerrit comments into the CodeReview extension. ;-)

Nemo08:24, 29 September 2014

fyi, is closed.

GZWDer (talk)12:11, 29 September 2014

Which shows my point. ;-) Hopefully you can reach the place where my link went; if not, add to the reasons to keep CodeReview.

Nemo19:12, 29 September 2014

Hi! There is a problem with one BlackList entry. This one:

#Allows creation of pages with titles too similar to existing pages

It doesn't allow (new) users with cyrillic SUL name to login to MediaWiki site. Cause they usually contain these cyrillic (е|а|о) characters. You need to either remove this entry or improve it somehow.

Piramidion (talk)13:33, 4 December 2014

@Jasper Deng: Can you take a look?

Florianschmidtwelzow (talk)13:48, 4 December 2014

@Jasper Deng:@Florianschmidtwelzow: A week has passed. Anything? Our users still cannot enter MediaWiki site nor create their own user pages if their SUL usernames contain any of these 3 characters. The only exception is for those users with cyrillic SUL names who had registered here before this blacklist entry was enabled. Are you gonna do anything about that or should I address someone else to solve this problem?

Piramidion (talk)13:58, 11 December 2014

@Piramidion: I have commented out this rule for now, so it should work, if this is the real problem. Can you test it and give a response, if it works now?

@Jasper Deng: We should check, if we need this rule and should re-enable it with some adjustment?

Florianschmidtwelzow (talk)07:17, 15 December 2014

Thanks! I will tell the user(s) who couldn't enter MediaWiki under their own SUL login to try again. Earlier one user (now an administrator on ukwiki) had got the message that "this username is blacklisted on MediaWiki" or something like that. Now it should be fine. I will post the result here.

Piramidion (talk)19:14, 15 December 2014

Yes, it works! You can check it yourself :) Thanks again!

Piramidion (talk)19:31, 15 December 2014

Great :) YesY Done

Now we just need to figure out, how we can use this rule, without this behavior :P

Florianschmidtwelzow (talk)13:30, 16 December 2014

Installation guide consolidation

Edited by author.
Last edit: 11:48, 16 December 2014

Manual:Installation guide has one section with a 400 words summary, but then links to a "Main installation guide" composed of 4+4 more pages. None of these pages is translatable. Can we consolidate truly important information and make it translatable? Currently one is supposed to find the following logical steps.

  1. Download
  2. Requirements
  3. The actual installation
  4. Misc troubleshooting and alternatives if something went wrong
  5. Configuration
  6. Maintenance
  7. Informative material

The pages in bold are part of the official Template:InstallationNav (which complements Template:MediaWiki Introduction): they are supposed to be the official path and need special care and coordination.

Nemo14:17, 27 May 2014

Given Chad's comment, I'm also going to tag all "platform-specific" manual pages for merge to the main ones. Common parts can be merged and transcluded on the specific pages, while really platform-specific additional information can be left there. P.s.: for a start, I removed 5 guides on obsoleted systems and marked the others for merge.

Nemo09:51, 14 June 2014

Thank you for this!

MarkAHershberger(talk)13:39, 14 June 2014

I made Manual:LocalSettings.php translatable and expanded Manual:System administration by merging Manual:Configuration.

  • Manual:System administration could be useful if it becomes a reasonable index/step by step guide/tutoring of the really important pages in Category:MediaWiki for site admins (allowing to remove respective information from the general installation manual), but I'm not sure of its current role.
  • Manual:LocalSettings.php is very visited, but it's quite a mess. I doubt it kept anywhere close up to date, is it currently making a good service to users?
Nemo07:50, 9 August 2014

I wonder what's the purpose of making Manual:LocalSettings.php translatable if you doubt about the usefulness of that page or if you plan/propose to improve/restructure it.

Ciencia Al Poder (talk)18:36, 10 August 2014

The page is vastly correct and the strings contained in it look rather stable, so it's ok to translate it. It is my impression that some consolidation will be needed for that page (reducing total amount of text around), but not a rewriting.

Nemo19:10, 10 August 2014

I've tried to make the essential stuff transcludable, and I've trimmed some more pages.[1]

IMHO the direction is rather clear:

  • always defer to other sites for guides on how to set up PHP etc.;
  • keep all the steps internal to MediaWiki (like installer, config script, LocalSettings.php) in their own, shared manual pages;
  • in all the setup-specific pages, just transclude the former and maintain only:
    • information on packages available and how to use them (debatable, should be on their sites whenever possibles),
    • OS-specific instructions which can't be found anywhere else, like specific paths to put in MediaWiki config or RAM/suhosin requirements and the like.
Nemo11:52, 16 December 2014

[RESOLVED] User:MisterLambda was blocked in error

I am making this thread on his behalf.

User:MisterLambda is blocked for being a "vandalism-only account". From what I've observed, his account has not performed any vandalism, and his contributions include an extension.

Frozen Wind (talk)01:23, 15 December 2014

I'm not sure what happened, but I unblocked him.

Daniel Friesen (Dantman) (talk)02:57, 15 December 2014

What spam are our captchas stopping?

Some hours ago, FancyCaptcha was disabled on this wiki for 18 minutes. There was some more spam coming in as result, let's find out at Extension:ConfirmEdit/FancyCaptcha experiments exactly how much and what abusefilters can be set up to reliably stop it.

Nemo09:02, 5 December 2014

CSS not working in Hebrew Wikipedia

A thread, Thread:Project:Current issues/CSS not working in Hebrew Wikipedia, was moved from here to Project:Support desk. This move was made by Ciencia Al Poder (talk | contribs) on 26 November 2014 at 10:26.

Need to change oauth consumer redirect URL

I registered on an OAuth consumer for a project I am working on. When I registered it, I used a .local DNS name in the redirect URL for development purposes. Now, I want to change it to a staging server. However, when I go to my consumer's management page, which I am permitted to do, I cannot change the URL - only the source IP addresses and RSA key. What is the process for resolving this problem?

Ddennedy (talk)21:02, 22 November 2014

Recategorisation of MediaWiki settings categories, discussion on restyling Template:CS cat header

Edited by 0 users.
Last edit: 14:53, 22 November 2014

For the second part, it's been taking a long time for the back-and-forth of replying, so I'm just linking the discussion here:

For the main part of this post, this is the current layout of Category:MediaWiki configuration settings:

  • MediaWiki configuration settings
    1. MediaWiki configuration settings X.XX
    2. MediaWiki configuration settings introduced in X.XX
    3. MediaWiki configuration settings deprecated in X.XX
    4. MediaWiki configuration settings removed in X.XX

As you can see, (1) and (2) are both duplicates, and they both have many translation pages! I think it's complicating and effort is wasted in these. But, these are just category pages. The only text content in (1) is provided in Template:CS cat header so the category pages don't need to be translated themselves, but (2) doesn't even use the template. As for the deprecated and removed categories, they seem fine so no complaints. The only reason I have found why this was done was from the Template:CS cat header template which says it was to make the naming consistent.

What would everyone say to making all (1) categories redirect to (2) pages? I have used a script to check what pages link to (1) and I have found that they link only to each other using the template, so no pages will need to be updated to remove double redirects. I could also make a script to perform the redirects.

I also have another suggestion of modifying the layout, which would involved only adding [[Category:MediaWiki NAMEHERE configuration settings]] in each page. But it may involve edit-spam so I'm not sure. Modified layout:

  • MediaWiki configuration settings
    1. MediaWiki introduced configuration settings
      • MediaWiki configuration settings introduced in X.XX
    2. MediaWiki deprecated configuration settings
      • MediaWiki configuration settings deprecated in X.XX
    3. MediaWiki removed configuration settings
      • MediaWiki configuration settings removed in X.XX
-- Nahiyan8 (talk | contribs)14:53, 22 November 2014

Using Project:Support_desk for emergency bug reporting during the Bugzilla - Phabricator migration

Cross-posting Quim's suggestion

As part of the Bugzilla - Phabricator migration, Bugzilla is planned to be turned to read-only mode on Friday 21 November 00:30 UTC, and Phabricator will be completely down. We will discourage the submission of bugs/tasks that can wait, but we need to have channels open for emergencies. We are proposing to use the Support Desk combined with a specific IRC channel, both monitored by Andre Klapper and other usual suspects (so we would not leave you alone here). What do you think? See the related discussion at phab:T473#10278.
Ciencia Al Poder (talk)10:52, 7 November 2014
Edited by 2 users.
Last edit: 05:33, 22 November 2014

For other issues not so urgent, an etherpad has been created:

Ciencia Al Poder (talk)17:46, 21 November 2014

Recurring spammer Hughclayton

This one is a recurring spammer who needs to be blocked at some point. Low volume but still every edit was reverted due to linkspam. Cheers

[[kgh]] (talk)19:58, 3 November 2014

Replace full protection with FlaggedRevs

Some pages that are currently fully protected could benefit from a less rigid protection scheme using Flagged Revisions, allowing more editors to suggest edits without risking having highly visible pages contain potential gibberish. I propose changing the fully protected pages to Flagged Revision's "Require review for revisions from everyone except Reviewers" setting. That way people can suggest edits but these won't be publicly visible unless approved by a reviewer or administrator. Optionally, semi-protection can be added to prevent edits from unregistered or new accounts. What do you guys think?

Waldir (talk)15:51, 7 January 2013

The principle sounds interesting. What pages are you thinking of? Maybe it's easier to just report pages that should benefit from Flagged Revisions and change their status unless there is a good reason not to. Should we try with a just a few first?

Qgil (talk)18:13, 7 January 2013

There are 7 in ns0 (none worth unprotecting), one in Extension and none in Help or Manual. Waldir, what pages are you talking about?

Nemo19:12, 7 January 2013

I'm thinking all of them, really. It might be worth revisiting what we understand by "worth unprotecting". There is always a small detail (a typo, a minor rephrasing to make things clearer, etc.) that we will overlook — nothing's ever perfect, after all. As an example, just yesterday I noticed that the main page has a link to "How does MediaWiki work?", a redirect that can be replaced with its actual target, "Manual:What is MediaWiki?". Requiring edit requests makes the workload for such small edits triple. Besides, this wiki doesn't get much vandalism/spam (AFAIK), so it shouldn't be such a problem.

In any case, we can certainly try it with one or two pages and reassess after a month or two. Any edits will only be visible immediately if made by reviewers or admins, and should any of them screw up (which is rather unlikely to happen, as you might imagine), the right can easily be removed; at the same time, autoconfirmed users will be empowered to suggest edits (to make a git analogy, that's kind of a pull request rather than a patch, where the final repository gets the actual authorship in the version history). So what do you say about a test trive?

Waldir (talk)13:30, 8 January 2013

It's no big deal. If it's just those 7 pages (I'm excuding the main page and Visual editor/Feedback which might still be linked in edit view from somewhere) I can do it immediately.

Nemo15:00, 8 January 2013

Great, please do. Just one question: what do you mean by "which might still be linked *in edit view* from somewhere"? a url with action=edit?

Waldir (talk)17:19, 9 January 2013

I thing this is a very good idea.

Countless times, I have wanted to improve - most often correct - a page or a template, and I gave up, because it was locked. → The wiki gets no gain.

Countless times also, I have edited a page, or a part of the home page, with flagged revisions, and my edit went live after a few hours or days. → The wiki gets improved.

However, in the proposal by Waldir, there is one thing I don't like : the part "except Reviewers". If we place a barrier in front of content editing, why would reviewers have a passe-droit ? Admins behaving "above the law" are a chronic disease in Wikipedia communities. If there is a good reason to allow reviewers to edit directly, then there is a good reason to allow everyone to edit directly.

Nnemo (talk)15:44, 21 October 2014

This is a dead horse, FlaggedRevs has been removed from

Nemo05:27, 22 October 2014

If one has removed this, then one can put it back.

Nnemo (talk)14:00, 23 October 2014

But we aren't going to. Failed technologies need to be allowed to die.

Jdforrester (WMF) (talk)16:54, 29 October 2014

Wikimedia Engineering reports

The Wikimedia Engineering report for August is still a draft, the link to the September summary is a red link, and {{SoFixIt}} is not applicable. But WP:BRION is alive and kicking again.

Be..anyone (talk)07:43, 13 October 2014
Edited by author.
Last edit: 07:19, 16 October 2014

You gotta be kidding, "Previous reports" in the footer has three red links. :) m:Tech/News mostly replaced BRION. WMF reports are lagging behind due to some work shifts in their maintainers, AFAICS.

Nemo11:52, 14 October 2014

Well, those links worked seven years ago, before somebody intentinally "lost" his m+w passwords. :-| The new m:Tech/News/Latest is fine, I have a link to it on my user page.

Be..anyone (talk)17:17, 15 October 2014

The engineering reports have traditionally been published within two weeks after the end of a month. The reports for August and September were delayed due to several reasons, but the August report has now been published, and the September report is being drafted and will be published shortly.

That said, it's true that the engineering reports are very labor-intensive, and that's why we're considering replacing them by a more consistent combination of timely updates (in the form of Tech News and status updates) and quarterly retrospectives. See also the last paragraph of this wikitech-l email.

Guillaume (WMF) (talk)19:15, 28 October 2014

Toolserver wiki

I'd like to import several Toolserver wiki pages on this wiki, with some regex cleanup. I lean towards:

  • changing titles to pseudo-namespace format as we did for API etc., Toolserver:;
  • regex change of internal links (but not templates) so that they keep working;
  • run AnankeBot to add a template similar to Template:MoveToMediaWiki on top;
  • perhaps manually fix some active usernames to match this wiki (e.g. 'nemobis' -> 'Nemo bis').


Nemo09:33, 19 October 2014

What content specifically are you looking to import?

Peachey88 (talk)09:36, 19 October 2014

Toolserver wiki's.

Nemo11:04, 19 October 2014

[RESOLVED] rapid-fire vandalism from Ekkentros

Ekkentros (talk · contribs) is creating lots of nonsense pages. Could an admin please delete all of them?

Ixfd64 (talk)18:46, 13 October 2014

YesY Done by Tegel

The user is blocked with an expiry time of indefinite.

Florianschmidtwelzow (talk)20:42, 13 October 2014
First page
First page
Previous page
Previous page
Last page
Last page