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
Page creation glitch218:04, 11 September 2014
LQT search boxes on this site hit HTTP timeout atm.407:24, 8 September 2014
Email, watchlist, and notifications019:35, 6 September 2014
[RESOLVED] order reversed for Special:MyContributions?313:12, 5 September 2014
Enable DynamicPageList705:11, 1 September 2014
How to to get password reset for account on this site which has no email address706:10, 26 August 2014
left menu problem014:40, 14 August 2014
about wiki syntax012:21, 14 August 2014
Updated Red Hat/CentOS install instructions115:35, 13 August 2014
Installation guide consolidation519:10, 10 August 2014
reset password page falsely states it sent a password, given blank username014:47, 8 August 2014
Can't log in419:33, 2 August 2014
Heartbleed308:51, 19 July 2014
No "LOG OUT" link007:27, 18 July 2014
Extensions not tagged with REL1_23112:32, 16 July 2014
insert "Vorlage" into a new mediawiki001:35, 13 July 2014
Broken link in user contributions footer613:54, 9 July 2014
Translate extension1408:28, 3 July 2014
Honoring our volunteer devs614:45, 25 June 2014
Finding the correct version of an extension509:34, 20 June 2014
First page
First page
Previous page
Previous page
Last page
Last page

Page creation glitch

When I tried to create a new userpage, I got this peculiar problem: File:Bobrayner pagecreation problem.jpg

  • MediaWiki is trying to warn me that I'm creating a new page, but this notice can seemingly only be triggered by users who willingly click on the "Create" link or similar (not just by navigating to a currently-redlinked page), so why is a warning necessary?
  • The notice is malformed and unreadable, apparently due to being put inside a narrow frame which takes up the left half of the notice area, and the leftmost strip of the warning is devoted to a pointless image which only takes a small % of the vertical height.
  • Also, on trying to search this page for any related issue, I get "An error has occurred while searching: HTTP request timed out.". Sorry if this is a duplicate.

Any suggestions?

Bobrayner (talk)18:29, 6 September 2014

The first two appear to be some VisualEditor issue. The other is about the old search system which is being discountinued (see Search) but still has some leftovers: please use Special:Search instead.

Nemo22:24, 6 September 2014

The first (the warning) is triggered when you navigate to a redlink. Go to Special:RecentChanges and click on any red-linked username, and you'll get the same message at the top of the wikitext editing window.

The second is a problem with the design of the template. It was designed to be displayed on a particular shape of a screen. You'll see the same mess in the wikitext editor if you have a very narrow screen (e.g., anyone using a smartphone over Mobile web, or if you drag your browser window to be narrow). It should be possible to make the text wrap around the icon, but the person designing it (years ago) was only thinking about how it would display for desktop users using the wikitext editor (because that's pretty much all there was back then).

Whatamidoing (WMF) (talk)18:04, 11 September 2014

LQT search boxes on this site hit HTTP timeout atm.

I'm using HTTPS and experience this issue. That is all.

Gryllida10:54, 31 August 2014

Someone added a topic summary, but I don't see who. Thanks though for identifying the issue and reporting it!

Gryllida12:15, 4 September 2014

It's still silly to link a dead feature and newbies were getting confused, so I hid the search box: [1]. Surely there is some configuration setting or hook to do it properly?

Nemo05:35, 7 September 2014

Best configuration remedy for this would be to disable LQT.

Max Semenik (talk)07:51, 7 September 2014

Email, watchlist, and notifications

A thread, Thread:Project:Current issues/Email, watchlist, and notifications, was moved from here to Project:Support desk. This move was made by Nemo bis (talk | contribs) on 6 September 2014 at 19:35.

[RESOLVED] order reversed for Special:MyContributions?

I don't remember changing any of my personal preferences, but when I look at my contributions (Special:MyContributions) the list starts with the earliest edits and there's no way to reverse the order. (The watchlist, on the other hand, still looks the same to me)

Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7)22:27, 4 September 2014

Things are back to normal, so the (temporary) changes must have been restored.

Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7)06:46, 5 September 2014

Just for information: This was a bug in new MediaWiki 1.24wmf20 tracked in bug 70413. It was hot fixed for and testwiki yesterday :) So that's why all is ok now :)

Florianschmidtwelzow (talk)11:10, 5 September 2014

Alright, thanks for the explanation.

Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7)13:12, 5 September 2014

Enable DynamicPageList

Meta-Wiki, along with hundreds Wikimedia projects, has DynamicPageList enabled. It's trivial to enable it here as well, but it wasn't done yet, yet e.g. I need it on Project:Language_policy/Migration_list to intersect 1 with non-2.

So I ask the community: any objection to enabling it here?

Nemo14:55, 8 August 2014


Florianschmidtwelzow (talk)16:51, 8 August 2014

What would be the purpose? Can you give some examples of how it might be useful on this wiki?

HappyDog (talk)10:17, 9 August 2014

I gave one in the first message. You can also click edit on that page to see the syntax.

Nemo10:55, 9 August 2014

Oops - yes, silly me!

Sounds like it is not something we generally need, but which might have the odd occasional use such as this. I don't have any objection to it being enabled.

HappyDog (talk)07:55, 10 August 2014


Gryllida09:56, 25 August 2014
Edited by 2 users.
Last edit: 00:25, 1 September 2014


Nemo04:55, 29 August 2014


Gryllida10:53, 31 August 2014

How to to get password reset for account on this site which has no email address

I've got an account here which I started back in 2006, but I forgot my password and it seems that in this case I neglected to set up an email address for my username. Thus the Reset Password page just says: "There is no email address recorded for user <xxxxx>". Oops!

So I'd like a password reset sent to the email address I use for the same username on several other Wikipedia projects. I can think of several ways to demonstrate that I'm the same person. Is there a way to privately submit a request to the admins here? Or some other option? Thanks!, 6 August 2014

If the account is the same as Wikipedia, the password should also be the same. You should check Special:CentralAuth/YourAccountName and see if the account is linked.

Ricordisamoa23:39, 6 August 2014

Thanks for the quick response. This account was set up before there was that sort of linking of accounts. They are not linked, and the password is different. So I'm still looking for some help here., 7 August 2014

I'm sorry, but there's nothing we can do about that. If you don't have the email address and you don't remember the password, we cannot retrieve the account for you.

Jorm (WMF) (talk)02:32, 14 August 2014

Well, almost. On the off chance you set up a committed identity (if you don't know what that is, then you didn't), you can use that to prove you own the account and get it back.

Jackmcbarn (talk)02:56, 14 August 2014

I would like to know what it is, please.

Gryllida09:55, 25 August 2014

left menu problem

A thread, Thread:Project:Current issues/left menu problem, was moved from here to MediaWiki talk:Sidebar. This move was made by Qgil-WMF (talk | contribs) on 14 August 2014 at 14:40.

about wiki syntax

A thread, Thread:Project:Current issues/about wiki syntax, was moved from here to Project:Support desk. This move was made by Nemo bis (talk | contribs) on 14 August 2014 at 12:21.

Updated Red Hat/CentOS install instructions

After working through a new install of mediawiki 1.23.2 on CentOS 6, I made a number of what I hope are improvements to the install instructions here: Manual:Running MediaWiki on Red Hat Linux.

Chasmo (talk)20:47, 11 August 2014

Thanks. We're trying to reduce the duplication among installation instruction pages, please feel free to remove any outdated or less useful part (especially if already covered somewhere else).

I see you've not made the page heavier, but good part of the new text is for SELinux. Is there any way to combine the two pages?

Nemo15:35, 13 August 2014

Installation guide consolidation

Edited by author.
Last edit: 07:46, 9 August 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

reset password page falsely states it sent a password, given blank username

A thread, Thread:Project:Current issues/reset password page falsely states it sent a password, given blank username, was moved from here to Project:Support desk. This move was made by Nemo bis (talk | contribs) on 8 August 2014 at 14:47.

Can't log in

I can log in here as myself (obviously), but the login for my bot (Reinheitsgebot) does not work anymore. I used "forgot password" to get a new one, but still the same issue. Error message:

[979b6eb4] 2014-08-01 12:49:06: Fatal exception of type PasswordError

Help please!

Magnus Manske (talk)12:52, 1 August 2014

Note: I can still log in on e.g. Wikidata. Must be a local problem.

Magnus Manske (talk)12:53, 1 August 2014

There's another report here: [1]. filing a bug would be useful.

Okay, I just went ahead and filed bug 69007, since a new code was rollout yesterday on and not other sites, so the cause is probably on yesterday's deployment.

Ciencia Al Poder (talk)14:42, 1 August 2014

I just deployed the patch to fix this. Thanks for the report!

CSteipp (talk)18:16, 1 August 2014
Edited by another user.
Last edit: 07:49, 2 August 2014

My login Bmrberlin had the same error message. Now I tried to reset my password an got a new one. But this does not work. Kogin fails with "wrong password". What can I do now? Regards Bernd update I tried my old password again. To my surprise, it worked.

06:59, 2 August 2014


Hi All, is Heartbleed security issue fixed? please confirm the version it got fixed., 16 April 2014

It's not a MediaWiki problem, but you may be interested in the Wikimedia projects handling: wmfblog:2014/04/10/wikimedias-response-to-the-heartbleed-security-vulnerability/.

Nemo15:22, 16 April 2014

Thank you Nemo, we have downloaded the MediaWiki app for internal wiki purpose, just want to know the version of wikimedia in which this bug was fixed..., 17 April 2014

Heartbleed was a bug in OpenSSL, not in MediaWiki. The Wikimedia Foundation runs both on its sites, so it had to fix the OpenSSL problem; but there's no problem in MediaWiki. (MediaWiki and Wikimedia are two different things.)

Yaron Koren (talk)16:50, 14 May 2014

No "LOG OUT" link

A thread, Thread:Project:Current issues/No "LOG OUT" link, was moved from here to Extension talk:LDAP Authentication. This move was made by Florianschmidtwelzow (talk | contribs) on 18 July 2014 at 07:27.

Extensions not tagged with REL1_23

So far the repos were not tagged for MW 1.23. Thus it is not possible to select the "recommended version" for this release when using "Special:ExtensionDistributor". Not sure if there is something in the water.

[[kgh]] (talk)14:06, 10 July 2014

Ah, apparently there is indeed something in the water. Thanks for providing the links to Bugzilla.

[[kgh]] (talk)12:32, 16 July 2014

insert "Vorlage" into a new mediawiki

A thread, Thread:Project:Current issues/insert "Vorlage" into a new mediawiki, was moved from here to Project:Support desk. This move was made by Ciencia Al Poder (talk | contribs) on 13 July 2014 at 01:35.

Broken link in user contributions footer

It looks like the bottom of the "User contributions" page links to an edit counter which used to be hosted on toolserver. The link should be changed to link to some other edit counter.

APerson (talk)02:28, 9 July 2014

Which MediaWiki version do you run on your server that has this? Or is this about some Wikimedia website and not MediaWiki? Exact steps to reproduce welcome - I don't see any link to toolserver on my user contribution page on

Malyacko (talk)07:29, 9 July 2014

I suggest he mean, which links to toolserver:

I think this isn't a bug report for bugzilla, but Support-Desk isn't the right place, too, i think. So move to talk page of Message or wait for admin? :)

Florianschmidtwelzow (talk)07:33, 9 July 2014

Done it. Thanks.

This, that and the other (talk)10:01, 9 July 2014

Thanks :) Now the question is: Wikipedia-project's uses supercount, mediawiki now uses xtools? Is that correct? :)

Florianschmidtwelzow (talk)10:25, 9 July 2014

Well, no-one said which one they wanted, so I just added a "link to some other edit counter". What's the difference between the two?

This, that and the other (talk)11:38, 9 July 2014

I don't know, i only saw the difference :) For me it's ok with this one.

Florianschmidtwelzow (talk)13:54, 9 July 2014

We've been using the translate extension for a while now on this wiki, which definitely needs more multilingual support, so I think we should greatly expand its usage, by deciding where to start. The aim is to reach more MediaWiki users (rather than developers); benefits have to be balanced by costs, and in some areas the extension is easier to use than in others (or even easier than continuing with {{Languages}} and so on). Some ideas:

  1. Most viewed pages: I've done some, but they often need an update/revamp in English too.
  2. Configuration variables: hundreds of them have the corresponding Manual: page translated and can be assumed of interest. The pages use a common pattern and most important info is in the template, so – in principle – translations can be moved to the new system (semi)automatically.
  3. Help pages would be the most useful in theory, but those we have here are very specific and limited. It makes no sense to translate most of them, because the "real help pages" and their translations are in fact on Meta or scattered among Wikipedias (or other Wikimedia projects.
Nemo09:23, 21 October 2012
Edited by another user.
Last edit: 13:31, 21 October 2012

About #3: What about the users of non-WMF wikis? Wouldn't translated help pages be helpful for them?

Leucosticte (talk)13:31, 21 October 2012

Yes but one should first move the up-to-date and complete English pages here from Meta and other wikis (finding a solution for licensing problems and also convincing them not to keep outdated copies around), which is not going to happen.

Nemo14:01, 21 October 2012
Edited by 0 users.
Last edit: 16:53, 21 October 2012

You may be right. I think it was a mistake to insist on public domain Help pages, and that we are reaping the harmful consequences of that decision. But to fix it would require acknowledging that a mistake was made, and sometimes people are resistant to that.

Leucosticte (talk)16:53, 21 October 2012

I disagree - PD help pages are a very good idea. However, it is a mistake to think they will be of any real use until we provide a workable method of distibuting them. I think it is a fairly safe assumption that if there was an easy way to import the default help pages into your local wiki, in the appropriate language(s), then that would be sufficient encouragement for the current pages to be tidied up (if, indeed, that is necessary - I haven't looked at them for a while) and, more importantly, widely translated.

I don't think think the solution here is to import existing non-English help content from elsewhere, or to try and encourage a translation drive for the help content, without having an export process in place.

HappyDog (talk)18:22, 21 October 2012

Seems we can all agree on this, so we're left with #1 and #2 for now.

Nemo08:26, 22 October 2012
Edited by 2 users.
Last edit: 18:21, 1 January 2013

Configuration settings summaries have over 23 thousands translations for the Configure extension; it would be nice to find a way to use them on wiki. I've opened bugzilla:43380 to see what's technically feasible.

Nemo11:06, 24 December 2012

I'm not familiar with the Translate extension, although I'm looking for an excuse to finally give it a try.  :) Is it possible to promote a set of pages where translation is prioritized? Using a category, for instance.

Trying to translate the whole is pointless and actually counterproductive, but there is a bunch of pages that would really welcome more translations, and a formal request to be translated. It would be useful for the project and for translator to identify those, and if possible get those nice stats telling that Japanese is 100% up to date, Italian is 83%, Arabic is 12% and so on.

There are two types of translatable pages based on motivation:

  1. Promotion: local languages are good to reach out to new users and contributors. Homepage, the hubs, How to contribute, the local Groups (mainly in their respective native languages)...
  2. Support: essential pages for users of MediaWiki and our technical infrastructure. The most basic and required pages of the manual, how bugzilla works how to get developer access...

Maybe it's worth having both translatable categories separate? Maybe some languages make total sense for Promotion but less so for Support (no specific examples, although I can imagine Indic or Latin languages speakers needing those translations more for Promotion than Support, since the average sysadmin / developer of those languages is used to deal with English documentation).

It is clear that the deeper you get into both categories the clearer is the need to manage some English, at least in our current reality. We could probably define a VERY LIMITED set of pages translatable here and now in both categories and then consider the addition of new pages based on actual need.

And I agree with Nemo that those pages need a review in the canonical English version before making big calls for translation. But maybe this is a feature? It forces us to go through identified pages, mark them as translatable progressively and giving more time to translators to deal with new content. For instance, we could start focusing in How to contribute and Help:Formatting, and do a first test with these pages.

Qgil (talk)17:00, 24 December 2012

Yes, it's possible to "categorize" requests for translations, see for instance m:Special:AggregateGroups. It's also possible to define priority languages and even to disable translations in some languages, but this makes little sense on this wiki. In general, people will always translate what they're interested in, not what you'd most like to have translated, therefore if something would use translations it should be translatable, while for focused translation recruitement you can have a specific priority group of translatable pages.

In short, I don't like that "very limited" in all caps, unless you consider (like me) that e.g. 600 configuration settings pages (out of ten thousands content pages) would be a "very limited" set of translatable pages. ;-) Specific pages ready for translation should made translatable immediately: I'll comment on those two on talk.

Nemo17:49, 24 December 2012

Ok, got your point. I just find useful to have a set of pages identified for volunteer translators without own itch or agenda. "I want to start translating MediaWiki content to Catalan: where should I start? Thank you."

Qgil (talk)18:08, 24 December 2012

I've created a high priority group now.

Nemo18:46, 24 December 2012 was updated; the Help: and Manual: pages in the top-1000 list should probably be made translatable. Who's willing to help me?

Nemo08:38, 24 May 2013

Thank you for this useful link!

Qgil (talk)14:41, 24 May 2013

Honoring our volunteer devs

I've been a little frustrated recently by a couple of users who don't seem to understand how important our volunteer devs are. It's not entirely their fault; they're just so new, compared to MediaWiki's existence, that they have no idea that the entire concept of MediaWiki software was a volunteer achievement. The WMF devs are working on some large, high-profile projects, and the result is that "volunteer dev" sounds like "second-class dev" to these new folks.

So I have just started a page, How to become a MediaWiki hacker/Volunteer achievements, on which I've listed a couple of obvious, user-facing changes that were written by volunteer devs (even if said devs were later paid to work on MediaWiki).

I'm secretly hoping someone will tell me "No, that's just a poor duplicate of <this much, much better page>", but, failing that, if there's anything that you did, or that you know someone else did as a volunteer, please expand. I'd like people who are interested in become hackers to know that volunteer devs can do real things here, and for non-technical users to be able to see that volunteer devs have created many of the things that they use and rely on every single time they read or edit the site.

Thank you–to all the volunteer devs, for doing your work, and to anyone who can help me expand this page, for helping honor that good work and educate the next generation of users about our debt to the volunteer devs.

WhatamIdoing (talk)18:31, 18 June 2014

This is a great idea. Could you post this to the mediawiki-l and wikitech-l mailing lists? If you can't, would you mind if I post your message there?

MarkAHershberger(talk)18:45, 18 June 2014

I've added a link there. Usually, I do this on the MediaWiki release pages: you'll notice that most stuff on 1.21, 1.22, 1.23, 1.24 is done by volunteers.

I'm not sure how to expose such information without duplications nor ghettos, there would be two extremes:

  • highlighting volunteer contributions on MediaWiki history: could only be very high level (as your stub currently is);
  • filling in the "assignee" field on bugzilla for hundreds of particularly important bugs: very atomic, not super-readable.

As an aside, it's easy to find the conversation you probably had in mind and I'm not sure the person meant to depreciate volunteer work, rather the opposite.

Nemo19:24, 18 June 2014

I've seen more than one of these conversations in the last year or two, and different users have different views. Some agree with me that it's awesome that volunteer devs do so much. Some seem to be dismayed that critical infrastructure is left to mere volunteers.

Mark, you should feel free to post a link to the page any place that you'd like.

WhatamIdoing (talk)05:13, 20 June 2014

I would disagree that critical parts of the infrastructure are "left to mere volunteers". If a volunteer fills a need, the Foundation doesn't necessarily look to replace them with a paid employee. There have bee critical bits of infrastructure that have been handled by volunteers, but many of them have been hired as full time employees.

MarkAHershberger(talk)18:10, 21 June 2014

I think that your idea of what constitutes "critical infrastructure" might be narrower than some other people's.  ;-)

Whatamidoing (WMF) (talk)18:54, 23 June 2014

Finding the correct version of an extension

When I was here the last time, it was easy to find the correct version of an extension for my mediawikiversion - which is 1.17.0 - as than subversion was used to download snapshots. Now it is almost impossible to find the correct version as GIT ist used and only the newest snapshot is easyly found, while the correct old versions are almost impossible to identify.

Now I need Extension:ConfirmEdit to block spam and the newest snapshot doesn't work and I don't know if this is because it is not the correct version.

Kersti (talk)10:38, 2 December 2012

Yes, there's currently no way to reliably download extensions. This is very unsatisfactory and has been discussed several times on this wiki, bugzilla, wikitech-l and mediawiki-l but there's no solution on sight coming from the devs; try reading/joining those discussions to find partial solutions...

Additionally, 1.17 is unsupported and 1.18 will be soon the next, so I think you're really supposed to upgrade to 1.19 or 1.20.

Nemo11:45, 3 December 2012

Actually 1.18 is already EOL.

Daniel Friesen (Dantman) (talk)12:49, 3 December 2012

Sorry, but it is not possible for me to upgrade that often. And there may be good reasons why someone is not able to upgrade to a newer version, for example because he is running Mediawiki at home and has an old Computer.

Kersti (talk)11:47, 13 August 2013

That's really not a good reason.

Krenair (talkcontribs)13:31, 13 August 2013

I think, ab big site als Wikipedia or a Wiki which has 20 Contributors or more schould upgarde regularly whenever there is a new version.

But in cases where upgrading for itself is more work than I do on the contents of the Wiki, than this is a very good reason, to reduce upgrading to a sensible niveau! And in this case it is really impossible to upgrade that often, as I simply don't have the time to upgrade once a year!

Kersti (talk)09:34, 20 June 2014
First page
First page
Previous page
Previous page
Last page
Last page