Misplaced Pages

This is an old revision of this page, as edited by Glaisher (talk | contribs) at 12:32, 20 August 2013 (Reverted 1 edit by Graham87 (talk) to last revision by Kwamikagami. (TW)). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

• Table of contents
• First discussion
• End of page
• New post

• WP:VPT
• WP:VP/T
• WP:TECHPUMP
• WP:PUMPTECH

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk.

view · edit Frequently asked questions (see also: Misplaced Pages:Technical FAQ) Click "" next to each point to see more details. If something looks wrong, purge the server's cache, then bypass your browser's cache. This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown. No, we will not use JavaScript to set focus on the search box. This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences. No, we will not add a spell-checker, or spell-checking bot. You can use a web browser such as Firefox, which has a spell checker. If you have problems making your fancy signature work, check Help:How to fix your signature. If you changed to another skin and cannot change back, use this link. Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem. If an image thumbnail is not showing, try purging its image description page. If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear. For server or network status, please see Wikimedia Status. If you cannot reach Misplaced Pages services, see Reporting a connectivity issue.

Village pumps

policy

tech

proposals

idea lab

WMF

misc

• Voluntary RfAs after resignation
• Allowing page movers to enable two-factor authentication
• Rewriting the guideline Misplaced Pages:Please do not bite the newcomers
• Should comments made using LLMs or chatbots be discounted or even removed?

• view
• edit
• history
• watch
• archive
• talk
• purge

Section heading numbers

I would like to suggest that section heading numbers should be followed by a fullstop. My reason is that, in headings that also contain numbers, the result often appears confusing at first glance. (To me, at least.)
For example, a heading like "Class 4" or "Class 4 locomotive" may display as, for example, "4 Class 4" or "4 Class 4 locomotive". I believe "4. Class 4" or "4. Class 4 locomotive" would be less confusing on the eye.

4 Class 4
4. Class 4

4 Class 4 locomotive
4. Class 4 locomotive

André Kritzinger 01:25, 9 August 2013 (UTC)

You can do this for your own browser by either using a CSS2 compatible browser and adding

.tocnumber:after { content: "." }

to Special:MyPage/common.css or by adding

$('.tocnumber').append('.');

to common.js. If the JS doesn't work, then try wrapping it in "$(function(){" ... "});". But, anyway, this is a small change, but it might disturb many people. I'll look for an old discussion about this. πr (t • c) 01:46, 9 August 2013 (UTC)

That's a handy fix, but only works for the Table of Contents of each page. Use this to do the numbers in the headings themselves as well:

.tocnumber:after, .mw-headline-number:after { content: "." }

—sroc 💬 02:09, 9 August 2013 (UTC)

Ah, you're right. Thanks! I didn't notice because I have the "Auto-number headings" pref disabled, so I just assumed it was referring to the TOC. Anyway, these issues are obviously related, and the code is basically the same. :) Maybe this is a good proposal. πr (t • c) 02:24, 9 August 2013 (UTC)

I've also added the following to my CSS to reduce the size of the numbers to further help distinguish them:

.tocnumber, .mw-headline-number { font-size: 80% !important; }

Each to their own, but I think André's suggestion is a good one. —sroc 💬 02:34, 9 August 2013 (UTC)

Comment: The "section heading numbering" has caused issues with other gadgets and userscripts before. I don't think there should be any change to it without a full scale RfC to ask the community what they want to see happen. My first concern with changing this is how the change is going to effect the "Ask a question" gadget for the Teahouse. I just recently got that script fixed to not show a messy <span class="mw-headline-number">###</span> when it pulls the section title and posts it to the edit summary making the section link unusable. You can see the details of that at MediaWiki talk:Gadget-teahouse/content.js. Thanks for taking these other issues into mind before making any changes. Technical 13 (talk) 11:29, 9 August 2013 (UTC)

Providing Technical 13's valid concerns are addressed, this seems like a sensible change, But isn't it a MediaWiki issue? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:16, 9 August 2013 (UTC)

Thank you for the comments. A "personal fix" for my own browser is not the solution, though. Since it will affect virtually ALL pages, I'd rather see the boffins look into this to see whether it is doable. If it is, fine, if not, so be it. Should I refer the suggestion to someplace else or can I consider the seed as being planted and wait for it to sprout? André Kritzinger (talk) 13:56, 9 August 2013 (UTC)

Andy, if there were consensus for this change an admin could make it in our site-wide common.css without any changes to MediaWiki. Of course, the devs might want to make this the default for MediaWiki, but that's up to them. I tried it in my personal CSS, but found I preferred it without the full stops. (This is a personal preference thing. It might be because I've gotten used to the full stops not being there.) – PartTimeGnome (talk | contribs) 22:01, 11 August 2013 (UTC)

OK, so where do you okes suggest I take this suggestion now to get a community discussion going? André Kritzinger (talk) 20:03, 16 August 2013 (UTC)

Well, this is a community discussion... If you're looking to get a better idea of community support with support/oppose !votes, there's WP:Village pump (proposals). – PartTimeGnome (talk | contribs) 20:56, 16 August 2013 (UTC)

Thanks. That's what I was looking for. André Kritzinger (talk) 23:59, 16 August 2013 (UTC)

Konrad Zuse

There is vandalism on this page ("Hello konrads") that appears just above the table of contents, but doesn't appear to be part of the page's own code. Maybe it's in a template, but I can't figure out which one. Help, please. Thanks, NawlinWiki (talk) 14:37, 13 August 2013 (UTC)

It's already been reverted. Try a WP:BYPASS. --Redrose64 (talk) 15:10, 13 August 2013 (UTC)

Related observation but in the last couple of days I've dealt with about 5 OTRS tickets about vandalism and in each case cluebot had already reverted the vandalism when I looked, but the cache hadn't cleared and in 2 cases it required a null edit before the cache cleared. NtheP (talk) 10:48, 16 August 2013 (UTC)

Edit count

Being completely obsessive in too many ways, i keep a daily count of how many edits i have done. It has always been in step with X!'s counter on Toolserver, until today. I know Toolserver's going away, but has something happened to it that it managed not to count the edits i made two days ago? It's about forty shy of mine actual total, both total total and for this month. A quirk; not really important, i suppose, but an anomaly, all the same. Cheers, Lindsay 06:36, 14 August 2013 (UTC)

I believe toolserver uses a replication (copy) of the main database, it might just be that they have been slow updating the copy.--Salix (talk): 06:56, 14 August 2013 (UTC)

Mine's 144 too low. There haven't been any days recently where I've made 144 edits between 00:00 and 23:59 (UTC), so more than one day has been lost. --Redrose64 (talk) 19:39, 14 August 2013 (UTC)

Thanks, Salix; usually when there is a replication lag the tool shows it, and there hasn't been any showing for the past couple of days, that's why i assumed there might be something else. And, Redrose, it's good to know that i'm clearly not the only person tracking daily. I calculate two days' worth lost, in my case. Cheers, Lindsay 02:08, 15 August 2013 (UTC)

• I just noticed another issue today, not sure how long it's been going on. But when I go to that same edit counter tool by X!, the monthly edit numbers can no longer be expanded to show the breakdown by page space. I have my user opt-in file that I thought was supposed to facilitate that process, so something appears to have stopped functioning. Any information? --Tryptofish (talk) 20:04, 16 August 2013 (UTC)

If you mean hovering over the monthly number, Tryptofish, that seems to be working today ~ it's showing a breakdown in a little floating box, right? Perhaps this behaviour is part and parcel of Toolserver going away? Gradually. Cheers, Lindsay 18:46, 19 August 2013 (UTC)

Yes, that's what I meant. I just checked again, and it's not working for me. I'm traveling recently and using someone else's computer, which apparently is missing something in the software. When I get back to my usual computer in a couple of days, I'll check again. Thanks. --Tryptofish (talk) 18:55, 19 August 2013 (UTC)

Counting infoboxes

You may be interested to know that we have we have over 2.4 million infoboxes in article-space. Please see Misplaced Pages:WikiProject Infoboxes/Statistics, and feel free to make additions or fixes there. Would it be possible to automate the transclusion counts? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:22, 15 August 2013 (UTC)

Yet another Articles for Creation Helper Script

I am absolutely baffled by installing this script. I've checked the box on my Preferences and cleared my browser cache, yet the script doesn't show up when I open an article in the pending-AfCs category. Any ideas on what I'm doing wrong? —Theodore! (talk) (contribs) 04:14, 16 August 2013 (UTC)

What is your browser and skin? Do you have a "Review" tab at Misplaced Pages talk:Articles for creation/Kapow Pictures, or a triangle tab which reveals a "Review" link when clicked? PrimeHunter (talk) 09:44, 16 August 2013 (UTC)

Search and nonexistent pages

Go to http://en.wikipedia.org/User:DoesntExist and click the "Search for ..." link. You get back to the same place. Doesn't seem very useful: can someone see if a fix to MediaWiki:Noarticletext will break anything? — This, that and the other (talk) 11:47, 16 August 2013 (UTC)

That's odd. The search link is Special:Search/User:DoesntExist which redirects to User:DoesntExist. Normally search will only redirect when there is a matching title like Special:Search/Exist which redirects to Exist. Other namespaces give a search results page and not a redirect when there is no matching title, for example: Special:Search/User talk:DoesntExist, Special:Search/Wikipedia:DoesntExist, Special:Search/DoesntExist, Special:Search/Talk:DoesntExist. Is it deliberate or a bug for search to redirect Special:Search/User:DoesntExist? I suppose it's useful to go to a page saying the account is not registered when you enter "User:DoesntExist" in the search box. It may be less useful for a search link to do it, but consistency between the search box and search links is probably good. PrimeHunter (talk) 22:49, 16 August 2013 (UTC)

It's not just for "DoesntExist"...try User:Rfkhdj, for example. It seems that searching for a user page (Special:Search/User:Rfkhdj) will always take you to the userpage, regardless of whether or not the user exists. Theopolisme (talk) 19:33, 17 August 2013 (UTC)

Recent changes?

Not sure if I've just been unobservant for several years: has there always been a line right under the level 1 heading for Special:RecentChanges that says "Track the most recent changes to the wiki on this page."? Also, I thought calling Misplaced Pages "the wiki" was generally frowned upon. Brambleclawx 14:24, 16 August 2013 (UTC)

Indeed, Misplaced Pages is a wiki, not the wiki. The message would read better as "this wiki", which I think is what is meant. – PartTimeGnome (talk | contribs) 20:17, 16 August 2013 (UTC)

The message is from MediaWiki:Recentchanges-summary. It hasn't been customized so the MediaWiki default is shown. "the wiki" refers to whichever wiki the message is displayed at. I'm not sure it's a good idea to create custom messages for minor changes. If the MediaWiki default is changed later then we wouldn't get the change. PrimeHunter (talk) 21:45, 16 August 2013 (UTC)

how to delete excess space by a template draft

A template displays two spaces where the programming has only one nonbreaking space (one ampersand nbsp semicolon) after the pipe in an "#if" template inside the main template that I'm drafting. (I assume that if I use a breaking space it will be stripped and there'll be no space at all.) The double-space is visible in my Misplaced Pages sandbox. How do I prevent the extra space from displaying? Nick Levinson (talk) 17:05, 16 August 2013 (UTC)

Only the second space comes from User:Nick Levinson/Subscription or libraries. The first space is in User:Nick Levinson/sandbox, in the code Display: {{User: If you remove either one, only one space will be displayed. --Redrose64 (talk) 17:41, 16 August 2013 (UTC)

Oops. That wasn't quite it because I erred above in not pointing to a more specific example in a large sandbox, but even where I had typical antecedent text (as with "Oblast" in the sandbox) I spaced before the template thus causing the error you found. So I'll add to documentation that no space should precede the template. Thanks for figuring out what I should have figured out all by myself. Nick Levinson (talk) 18:56, 17 August 2013 (UTC)

VisualEditor weekly update - 2013-08-15 (MW 1.22wmf13)

Hey all,

Here is a copy of the weekly update for the VisualEditor project. This is so that you all know what is happening, and make sure you have as much opportunity to tell us when we're wrong and help guide the priorities for development and improvement:

VisualEditor was updated as part of the wider MediaWiki 1.22wmf13 branch deployment on Thursday 15 August. In the three weeks since 1.22wmf12, as well as presenting their work at Wikimania, discussing and planning improvements and new featurees, the team worked on some changes to how VisualEditor integrates with MediaWiki, a few minor feature improvements and improving the performance of the system, and fixing bugs and stability improvements.

Firstly, on the integration, the "edit" and "edit source" tabs and section edit links can now be configured more flexibly (which has been taken advantage of on the English Misplaced Pages). The labels for these "edit" and "edit source" tabs and section edit links (however they have been configured for a given wiki) will be consistent on all pages, even those that cannot yet be edited with VisualEditor like templates (bug 50402). These labels are applied before the page is sent to the user, so they no longer "flash in" for some users (bugs 50542 and 50692). Further, the section edit links both appear at once, rather than only one appearing until a user hovers over the heading (bug 50540). We also made a more prominent welcome notice that appears the first time a user opens VisualEditor (or every 30 days for logged-out users), warning them about VisualEditor being in beta (bug 52366).

In terms of new features, you can now edit references that are defined inside a <references> block (bug 51741), references defined in templates and image captions will also display (bug 51289 and bug 52427), and nested references now display correctly (bug 50749). We also made some changes to the link inspector to make it faster and simpler to use - you no longer need to press enter twice to set a link (bug 51065) or click as many times (bug 51523), and you are warned more clearly that the title you've entered is invalid (e.g. "Foo{}bar") and so won't let you set it (bug 33094). We made some major performance improvements to deleting text (bug 52013) and scrolling pages (bug 52014), which should be visible on long pages.

You can now add and edit <code> (code) and <s> (strikethrough) annotations in experimental mode on MediaWiki.org - coming to production wikis soon (bugs 51590 and bug 51610), as well as <tt> annotations with the same code (bug 52352), and a more general solution for use with similar pairs of annotations built out too (bug 52477). We added a keyboard shortcut for the "Clear formatting" tool: Ctrl+\ or ⌘ Cmd+\ (bug 51507). VisualEditor now uses the same kind of post-edit feedback message that the wikitext editor uses, for increased consistency between the different editors (bug 39632). Finally, we fixed the last known issues with Opera and so un-blacklisted it (bugs 37861, 47793 and 50813; tracked by bug 36000).

On the bug front, we fixed a number of issues. Firstly, we correct a problem where an ugly error was shown to the user on changing a template if there was an API issue (bug 52483). We now strip leading whitespace from paragraphs, so as to avoid users creating accidental <nowiki>s (bug 51462). A bug that made it impossible to save multiple consecutive references is now corrected (bug 52228), as is one that sometimes didn't get you a new edit token if your current one had expired (bug 51915). We also quickly fixed an issue where VisualEditor would crash on loading a page with a <nowiki> in it (bug 51948), and a corruption issue which led to categories getting duplicated (bug 52238).

Adding a link on an empty selection no longer crashes (bug 51404); if you press enter too quickly it still works (bug 51415); and the link inspector no longer aggressively picks a link for you in cases where there's only one suggestion (bug 52420). The save dialog briefly attached to whichever dialog you had most recently opened, rather than the main toolbar; this is now fixed (bug 52317), as has the toolbar floated to the top of the screen over the user's personal tools if a dialog had been opened (bug 52441). The link describing wikitext in the warning notice about not inserting it now opens in its own window (bug 52093), as does the link to the user guide (bug 52475). Embedded buttons' inspectors now display correctly, used in the forthcoming equation editor on large equations (bug 52845). Further, once you save the page, we re-enable the wikipage content handlers, so gadgets like those that make tables sortable will work again (bug 51565).

Finally, the Google Summer of Code work progressed well; early versions of the Math extension editor and tool for setting text language details are now available for testing on MediaWiki.org, and that for the SyntaxHighlight extension will be soon.

A complete list of individual code commits is available in the 1.22/wmf13 changelog, and all Bugzilla bugs closed in this period are on Bugzilla's list.

Ahead of the regular MediaWiki deployment roadmap, this should be deployed here two days early, on Tuesday 20 August.

Hope this is helpful! As always, feedback gratefully received, either here or on the enwiki-specific feedback page.

Jdforrester (WMF) (talk) 23:16, 16 August 2013 (UTC)

visited/unvisited pages

My personal general take on that aside and talking plainly on a technical issue that seems not to work as it should and taking the latest page I checked as an example, no matter if I check the most recent page or get the latest diff , it still shows up in green as "updated since my last visit". I'm using now chrome b/c IE is not supported anymore and still get "shit". This is not a one time issue so please fix it w/o excuses like telling me it's my fault. I got that crap before and it never was the case as told. Thanks, TMCk (talk) 01:21, 17 August 2013 (UTC)Yeah, I'm pissed b/c I've lost my patience after one screw-up after another. Sorry, but that's the way it is.TMCk (talk) 01:21, 17 August 2013 (UTC)

The "usual suspects"? Taken it personal when there is a problem and therefore critique?I really don't expect much nor am I asking for such.TMCk (talk) 01:49, 19 August 2013 (UTC)

The same system is used for email notifications and your talkpage notice, so it can't be totally crazy.... I couldn't find anything obvious while glossing over the code. The only thing i wonder about if it is perhaps a page vs talkpage issue. The source is a bit difficult to decode when it comes to that part of the logic. —TheDJ (talk • contribs) 23:13, 19 August 2013 (UTC)

BTW, the most common reasons for this problem is that people accidentally visit a page not-logged in on http (don't notice this) and then go on to read their watchlist logged in on https. The system can't know what you read when you weren't logged in when you read. —TheDJ (talk • contribs) 23:16, 19 August 2013 (UTC)

Nope, I clearly was logged in. And I didn't check if the same happens with talk pages but it sure does happen with articles as my example makes clear.TMCk (talk) 01:27, 20 August 2013 (UTC)

trouble viewing messages in Special:AbuseLog

An administrator mentioned to me something he did with edit filter 575, and I wanted to look at the log messages from it. This link correctly shows me the messages from filter 550. I changed "550" to "575" in the URL: . The changed URL shows me a jumble of messages from various edit filters. —rybec 17:37, 17 August 2013 (UTC)

I see only messages from 575 filter. Ruslik_Zero 18:06, 17 August 2013 (UTC)

Same here - 575 only. --Redrose64 (talk) 18:17, 17 August 2013 (UTC)

Filter 575 is hidden from public view. Admins like Ruslik, Redrose and I see messages from filter 575 there. Others don't. Maybe the idea is that a determined vandal could guess how to circumvent a hidden filter by comparing a list of edits that triggered it. PrimeHunter (talk) 18:31, 17 August 2013 (UTC)

It appears non-admins see the same list of all filter messages as when the Filter ID field is blank. This seems confusing. PrimeHunter (talk) 18:38, 17 August 2013 (UTC)

Yes, it is definitely confusing, especially as the software gives no indication of an error. Seems Bugzilla worthy. Theopolisme (talk) 19:29, 17 August 2013 (UTC)

Administrative rights aren't in the same package as filter editing and viewing — that's the Edit filter manager right. Edit filter managers who aren't admins can see private filters, while admins who aren't edit filters can't see them. That being said, there are very few EFMs who aren't admins, while admins can give themselves the right. Nyttend (talk) 00:52, 18 August 2013 (UTC)

Thanks, everyone. bugzilla:52977 —rybec 16:57, 18 August 2013 (UTC)

Current time lagged

A few mins ago on Time in Cambodia (before I purged the page), the page reported "Now is 10:13:09 in Cambodia (03:13 in UTC)", which was about 45 mins out of sync.

Time in Indonesia is currently saying "Now:11:32", which is 30 mins out of sync.

Im guessing this 'the time is now ....' data exists in other similarly titled article, but it isnt in Thailand, Singapore and Malaysia.

Is this a known problem? If it has been happening frequently, perhaps we need to remove unnecessary current time info from articles. John Vandenberg 04:07, 18 August 2013 (UTC)

A purge to each article "bumps" the times to their correct values; this is just the job queue being... a job queue. (I'm not really clear as to why this information is included in articles, by the way...wasn't that what timeanddate.com was for? ;) ) Theopolisme (talk) 04:23, 18 August 2013 (UTC)

It's not a job queue issue. The article uses the {{CURRENTHOUR}} {{CURRENTMINUTE}} {{CURRENTSECOND}} {{CURRENTTIME}} variables which are not updated in real time, but only when a page is edited or purged. It would seriously overload the servers to update in real time those pages which use these variables, which is why we have bots like Joe's Null Bot (talk · contribs) for those cases where knowing the current date and time is critical (for example, certain types of deletion processes require a certain time to elapse between nomination and delete). --Redrose64 (talk) 08:14, 18 August 2013 (UTC)

If we try to show current time in articles then we need to make a purge link, for example with {{Time}}. By the way, Time in Cambodia currently uses naive code which will display the time as 07:00 to 31:00. PrimeHunter (talk) 10:28, 18 August 2013 (UTC)

That's easily fixed. --Redrose64 (talk) 11:44, 18 August 2013 (UTC)

IMO, rather than having these "purge" links it would be better to replace these not-so-current times with some JS (in MediaWiki:common.js or a default-enabled gadget) that could do it more correctly, and omit the not-really-current time entirely for non-JS pageviews. Maybe I'll try to throw something together later. Anomie⚔ 12:14, 18 August 2013 (UTC)

IMO, the right thing to do is not to replace it with some JS, but rather to completely remove this silliness, and add to WP:NOT one more line: "wikipedia is not a clock, nor a world clock. קיפודנחש (aka kipod) (talk) 12:37, 18 August 2013 (UTC)

I'm totally with kipod on that one. —TheDJ (talk • contribs) 13:31, 18 August 2013 (UTC)

Ditto.--SPhilbrick(Talk) 19:14, 18 August 2013 (UTC)

Well, I don't see the point in having an article on some country state that "the current time there is ...." On the other hand: in that times on WP are reported as UTC, and an editor can reasonably want to be aware of current UTC time, but might not have his user-side time zone set correctly, it does seem reasonable to have some place for checking current UTC time. Is that available anywhere? ~ J. Johnson (JJ) (talk) 21:08, 18 August 2013 (UTC)

Preferences → Gadgets → Add a clock to the personal toolbar that displays the current time in UTC and provides a link to purge the current page (documentation) --Redrose64 (talk) 21:25, 18 August 2013 (UTC)

Search cache updating frequency

I was answering an OTRS ticket from a person who, for privacy reasons, removed unnecessary references to his own name from an article about an associate of his. I have verified that his name is completely expunged from the article, and I purged the cache for that page.

However, when his name is entered in the Search box, the article still appears in the search result. That was the reason for his complaint to OTRS.

How long does it take for the search cache to reflect this change? ~Amatulić (talk) 13:58, 18 August 2013 (UTC)

Normally once a day - very early in the morning UTC, or late evening American time. --Redrose64 (talk) 14:12, 18 August 2013 (UTC)

I've seen problems with Commons' search cache sometimes taking two days or so recently. Whatamidoing (WMF) (talk) 16:29, 19 August 2013 (UTC)

Recreation of renamed accounts via cross-wiki – possible bug?

User Unixgallery was renamed to Vvwang on July 12, but recreated automatically on July 15 and made some edits on July 29. Bug or feature? I don't see why this would be desirable, but correct me if I'm wrong. Ginsuloft (talk) 15:27, 18 August 2013 (UTC)

Since global account Unixgallery still exists, the user can login using it. When he goes to any page of enwiki, the local account is created automatically. Ruslik_Zero 15:58, 18 August 2013 (UTC)

Thanks, but you explained the "how" part, which I was already aware of, when my question was more "why". Is this a desirable effect, when the reason the user was renamed in the first place was because his username was promotional (and reported to UAA)? I mean, why (not how) can the user log in to another language Misplaced Pages, then log again back in here and continue with the original username? Ginsuloft (talk) 16:34, 18 August 2013 (UTC)

Edit issues

I bring these here because they just started a few days ago, and I cannot relate them particularly to VE, although maybe they are:

• Even though I have the option checked in Prefs, I can no longer right click on a section header to edit. I had to go back to Prefs and enable links.
• None of the symbol links on the edit page below the edit screen are working. They are visible as text, but there are no links.
• The WP search field no longer shows a dropdown box that changes with each letter I type to yield possible clickable options. Instead, this has changed to a dropdown box only when the options are pages I've searched for and have clicked on in the past.
• Although I still have the option checked in Prefs, I no longer see reference tooltips when I mouseover inline citations.

I checked my scripts and they're all okay; javascript is still enabled. I completely disabled everything Visual Editor, but the problems are still there. I use Win8 and IE10. Please leave cracks about IE at home. Any enlightenments? – Paine Ellsworth  15:29, 18 August 2013 (UTC)

This may be related to recent troubles with HotCat. Have you tried a WP:BYPASS (to persuade your browser to forget all old versions of Misplaced Pages's scripts)? --Redrose64 (talk) 16:09, 18 August 2013 (UTC)

Hi, Redrose64! I purged it all with no joy, but as usual your words led me to check something I'd almost forgotten about. For a long time I've had WP on "compatiblilty view". I just turned it off and it's all back to normal. Something's been fixed. – Paine Ellsworth  16:41, 18 August 2013 (UTC)

Did this, by any chance, start on Thursday afternoon, California time? I believe that's when a Mediawiki (not VisualEditor: that was delayed here until tomorrow) update was made. It's possible that something was changed that made compatibility view become incompatible. Whatamidoing (WMF) (talk) 16:33, 19 August 2013 (UTC)

mashing 2 lines together for unintended confusion

The layout of a box with a message, probably a template, sometimes inserts one text string into another, likely confusing some less geeky readers. Here's one as of a few minutes ago: "To list a page in this category, do not edit this category page. Instead, edit the page you want to list, adding ] at the Hide this message bottom. See FAQ/Categorization for details." I can't reach this box and don't know how to fix it if I could. It probably afflicts a lot of different boxes. I don't know if this varies according to the display platform; I'm seeing it on a laptop, not on a cell phone. But simply changing the browser's width changed the display to "To list a page in this category, do not edit this category page. Instead, edit Hide this message the page you want to list, adding ] at the bottom. See FAQ/Categorization for details." (Here, I added nowiki tags into each quotation.) The variation may create a challenge in editing a template. Nick Levinson (talk) 18:01, 18 August 2013 (UTC)

In my browser the "Hide this message" is in a smaller font and linked to Template:Editnotices/Namespace/Category, a page which instructs how to add a code to your .css page to hide that message from your view. Perhaps in some browsers the font is larger and more confusing? – Paine Ellsworth  18:26, 18 August 2013 (UTC)

Hide this message To list a page in this category, do not edit this category page. Instead, edit the page you want to list, adding ] at the bottom. See FAQ/Categorization for details.

We could put a faint border around the "Hide this message" link (see example above) to make it clearer that the text is separate from the link. --Redrose64 (talk) 18:53, 18 August 2013 (UTC)

That would help; and I don't know that it needs to be very faint. Maybe a little stronger border?

My browser is Firefox 9.0.1 and the font sizes appear to be the same. I'm not concerned with hiding it from view and I'm used to the mashing, but I think it would confuse exactly the people who don't realize they have an option to hide it.

I like the idea of the redesign.

Nick Levinson (talk) 21:31, 18 August 2013 (UTC)

Hmm, if your browser doesn't show any difference in font size, that suggests that it doesn't recognise font-size:xx-small; - which is odd, because that's one of the original styles from CSS 1.0, which predates HTML 4.0 by about three years and therefore also predates all versions of Firefox by at least five years. Anyway, the border doesn't have to be faint - plenty of other styles are available: Hide Hide Hide Hide Hide Hide Hide Hide Hide Hide Hide Hide --Redrose64 (talk) 22:22, 18 August 2013 (UTC)

I like the border; would it be possible to make the margin on the top and right consistent? Right now there is more space on the right than on the top, which looks odd. Theopolisme (talk) 00:29, 19 August 2013 (UTC)

I sugest margin-left of 5em. Added it to the example. —TheDJ (talk • contribs) 08:47, 19 August 2013 (UTC)

BTW, I find this whole 'hide this message' thing a terrible approach. It seems highly oriented at active editors and inserted without consideration for casual editors. I'd vote for removing it all together. —TheDJ (talk • contribs) 09:01, 19 August 2013 (UTC)

Oversized pictures in mobile view

This has been raised in Misplaced Pages talk:Route diagram template#Oversized icons in mobile view.

I noticed, around a week earlier, that in mobile view, pictures can be enlarged to twice the size when using displays with high device pixel ratio, like a retina display. For example, in Misplaced Pages:Today's featured article/August 19, 2013, the photo might get enlarged after the higher version is loaded. I suspect this is due to the following CSS rules:

img.tex, .image img, .thumb img {
max-width:100% !important;
width: auto !important;
height: auto !important
}

It seems that, after a higher resolution photo is loaded, the browser would try to resize that photo to its native size. However, I believe this is against the idea of providing a higher resolution photo to those mobile devices with 2x device pixels.

This might not be a serious problem for photos on TFA, but for the WP:Route diagram templates, this behaviour is undesirable and there is no way to override this behaviour, unless one remove file links (and icons would not be selected by .image img).

I saw this problem on an iOS 6.1.3 device with Retina display, in both Safari and Chrome. Can someone familiar with mobile view take a look on this? — Peterwhy 21:08, 18 August 2013 (UTC)

Ping Jon and Brion.--Jorm (WMF) (talk) 22:35, 18 August 2013 (UTC)

Try pinging Jon properly. :-) Graham87 03:32, 19 August 2013 (UTC)

It is more likely to be the use of srcset which allows the MediaWiki software to render alternate images based on the device capabilities. This was added a few revs ago. See HTML Living Standard. --  Gadget850 23:15, 18 August 2013 (UTC)

Curiously, the W3C don't describe the srcset= attribute - it's not mentioned at all in the HTML 5.0 Candidate Recommendation 6 August 2013, but it is mentioned (twice each) in the HTML 5.1 Working Draft 28 May 2013 and Nightly Editor's Draft - but is not actually described there.

Don't rely on this attribute being retained: I have noticed before that attributes or elements are added and then later dropped, such as the <command> element which was listed in the CR of 17 December 2012 but not that of 6 August 2013. An attribute or element should only be considered (semi-)permanent once the W3C doc has reached W3C Recommendation stage. --Redrose64 (talk) 07:38, 19 August 2013 (UTC)

It's in an html5 extension with draft status. —TheDJ (talk • contribs) 08:41, 19 August 2013 (UTC)

FYI... srcset is not currently supported by Safari. It was added just last week to webkit's code. You can download a nightly build to try it out. Bgwhite (talk) 09:06, 19 August 2013 (UTC)

General note: Browser and hardware information is always welcome to help reproducing it. For example I cannot reproduce this problem on a Nokia N950. --AKlapper (WMF) (talk) 09:11, 19 August 2013 (UTC)

"iOS 6.1.3 device with Retina display, in both Safari and Chrome." he did :D —TheDJ (talk • contribs) 09:23, 19 August 2013 (UTC)

Oops, I'm sorry. My reading skills on a Monday morning obviously aren't the best. :-/ --AKlapper (WMF) (talk) 10:27, 19 August 2013 (UTC)

Debugging the problem

It seems to me that this issue only affects PNGs of SVG images. Perhaps there is a bug in the polyfill script. mediawiki:HiDPI_display_support. —TheDJ (talk • contribs) 09:50, 19 August 2013 (UTC)

mw:HiDPI display support. — Peterwhy 10:12, 19 August 2013 (UTC)

Confirming my earlier belief, this problem seems to be caused by the quoted CSS rules together with a higher device pixel display. I encountered the same enlarging problem in my Firefox after setting device pixel ratio to 2.0x and 1.5x respectively (Config here), and the problematic images shrank back after disabling auto image width or auto image height. My guess is that these CSS rules overwrite the width and height set by img tag. — Peterwhy 10:00, 19 August 2013 (UTC)

Another hint is, if you check the mobile Main Page (as of now) using a high device-pixel ratio display, the image in TFA (battleship) gets enlarged but the image ITN (sports ground) does not. I guess this is because the first image has a link to its own file page, but the second image does not. Instead, the second image has a link to the file page of its uncropped version. This keeps the second image unselected by .image img. — Peterwhy 10:09, 19 August 2013 (UTC)

(e/c) Actually, I was mistaken. It seems that the problem is twofold

1. The "img.tex, .image img, .thumb img" is conflicting with the polyfill requirement of a fixed width and height.
2. Some icon templates seem to use a different transclusion logic, where the image is not linked. This avoids them falling into this "img.tex, .image img, .thumb img", but causes a cluttered display of the assembled bsicon template.

Reported the problem —TheDJ (talk • contribs) 10:24, 19 August 2013 (UTC)

The second problem can easily be solved, and modifications to de-link all icons has already been coded, only waiting to be pushed from sandboxes. And so, the example in Bugzilla might get outdated soon. — Peterwhy 11:12, 19 August 2013 (UTC)

I hope you've made sure all the icons being delinked are public domain, CC0, or another license that doesn't require attribution or notice of the license on each use? Anomie⚔ 11:27, 19 August 2013 (UTC)

No, although in my opinion most icons should be in {{PD-shape}}. And there certainly are some really simple shapes that were originally marked CC (e.g.  (STRq)). And there can't be many mechanisms that prevent people from adding icons requiring attributes afterwards. This is one of the obstacles that prevented this to be rolled out, since April.

More discussions: Misplaced Pages talk:Route diagram template/Archive 7#Route maps 3x faster by BS-overlap update but lack pictogram links. — Peterwhy 12:20, 19 August 2013 (UTC)

The linking of icons in the WP:RDT system was already contrary to guidelines, in that it is possible to overlay several icons on top of each other - but only the topmost icon would be linked, even if the top one was PD but a lower one was CC-BY-SA. --Redrose64 (talk) 18:17, 19 August 2013 (UTC)

Alternatively, keep formatting images like ]. Quite a dumb way though. — Peterwhy 13:27, 19 August 2013 (UTC)

CSS on mobile site

Meta: I often encounter issues with article display (some but not all CSS related) in mobile view, but it's not clear where to raise them. There is a mailing list, and bugzilla, but there should really be an en.WP page as a first and central location for such discussions. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:37, 19 August 2013 (UTC)

@Andy, this is because the mobile view ignores and overwrites most of the inline CSS. This is part of the mobile teams efforts to design a more responsive website. They are even pondering disallowing all inline CSS at some point in the future. In that scheme Templates would likely have their own css block/page, and all styling should be done using classes. It's not decided yet, but the mobile platform features as a testing ground for some of those ideas. They don't really care about properly displaying templates like these that use elaborate CSS hacks. They want to find 'better' ways. —TheDJ (talk • contribs) 09:50, 19 August 2013 (UTC)

I understand this is the future styling way; repeating inline style definitions for hundreds of times (even with the use of templates) is bad. I agree this would be convenient for the mass "content editors", who might not care about the exact presentation in different views. But for "template editors", this poses a headache to make things work in mobile view. Either mobile users are ignored (hence the notice box on top of WP:Route diagram template), or extra inline styles are added to overwrite what mobile teams want, sometimes even using !important to overwrite their !important. I know that is bad, and inline !important means no custom CSS can overwrites it; but what the project requests are just some simple borderless tables floating in the center. Unless there are some simple, well-accessible and secure way to define a CSS block for individual template series, or some way to opt-out the general styles, I believe such glitches will still occur. Or, meanwhile this "edit war" will still continue. — Peterwhy 10:58, 19 August 2013 (UTC)

(ec) I do hope they 'find' it before they implement it. Killing all inline CSS will kill the majority of all templates. Is there a bug requesting per-page-CSS? Without that, mobile is doomed, because I doubt editors are prepared to tailor for mobile view if it means that the only way to do so it by severely restricting desktop view. — Edokter (talk) — 11:03, 19 August 2013 (UTC)

That would be bugzilla:35704. Again, it's a long term goal that is under consideration. It wouldn't be realistic right now. —TheDJ (talk • contribs) 11:43, 19 August 2013 (UTC)

I'm not talking about only inline styles; but my point was about the need for a clearly signposted, on-wiki place to discuss such issues; rather than a desire to do so here. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:47, 19 August 2013 (UTC)

Login issue

Hello.

I seem unable to login in WP. After a seemingly successful login, it still says "Create account" and "Log in" at the top.

Has anything happened, or is this a caching issue?

46.194.141.253 (talk) 17:41, 19 August 2013 (UTC)

Maybe your browser rejects cookies, check that fist and about caching you can try to reload Wikipeidia with Ctrl+F5 in most browsers......

My1 21:08, 19 August 2013 (UTC)

It may actually be logging you in, but caching issues show you the site as if you're logged out. A hard refresh after logging in would fix this. Steven Walling (WMF) • talk 21:36, 19 August 2013 (UTC)

Template:Category TOC not clearing left

I was looking at this category page and the Category TOC template is floating to the right of the Template:Category class, instead of below it. I looked at the page in 3 different browsers, IE10, Mozilla 23.0, and Chrome 28.0.1500.95 m and it is doing the same thing. What's up? --Funandtrvl (talk) 17:54, 19 August 2013 (UTC)

The layout of ToCs has changed recently. I corrected most of the 'custom' ones that we have here on en.wp, but forgot about the small detail of clearing floating content with these custom ones. Will fix. —TheDJ (talk • contribs) 21:06, 19 August 2013 (UTC)

I strongly suspect that this edit may be relevant. --Redrose64 (talk) 21:25, 19 August 2013 (UTC)

h2 might do automatic clearing. Would explain why it's only now visible. Still, the place to fix this was on the right floated div. —TheDJ (talk • contribs) 22:21, 19 August 2013 (UTC)

Actually, this is an even more specific problem. Here, the new toc is preceded by a Table, and a table behaves like an inline-block itself... Hmm. Gonna have to sleep on this one, that's a difficult issue. —TheDJ (talk • contribs) 22:25, 19 August 2013 (UTC)

Thank you for looking into it, I wish I knew more about programming so that I could help you out! --Funandtrvl (talk) 23:08, 19 August 2013 (UTC)

Misplaced Pages:Wikipedia_Signpost/2013-08-21/Technology_report

Hey, all! I was wondering if I could get a few eyes on this, to make sure my explanations of the new features are clear, and to check I haven't misunderstood anything. I'm afraid Gerrit, Bugzilla, and the Tech Report are all pretty bad at giving context for a lot of things, so I've had to do a lot of research to try and get things right.

It's my first time doing the tech report, so, well, wouldn't mind an expert review. Adam Cuerden 18:51, 19 August 2013 (UTC)

Completed article in user space

Hi,

I have an article I've completed in my sandbox and I want to publish it. How do I do that? — Preceding unsigned comment added by Eirefrance (talk • contribs) 19:04, 19 August 2013 (UTC)

You would move the page into article space. See also WP:YFA. --Redrose64 (talk) 21:28, 19 August 2013 (UTC)

Placement of images

I'm trying to figure out how to add another image to a specific spot on the Leavenworth, Washington, page. I want it to go below the climate table and to left of the climate chart. While editing, I placed the code for this photo between the {{Weather box}} and the {{Climate chart}}, but a preview of the reading interface wasn't laid out how I wanted. Any help would be much appreciated. Jsayre64 (talk) 20:38, 19 August 2013 (UTC)

Bear in mind that +/- half our readers view the mobile version of the site, and not everyone has the same browser, screen-size, window-size, image preferences and text-size settings as you. Where you use the image isn't where other people will see it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:33, 19 August 2013 (UTC)

(edit conflict) This edit should do it. You may like to adjust the caption. I think you should also make sure that the dates in the climate chart don't fall foul of WP:DATESNO, the bit about "do not use year-final numerical date formats (DD/MM/YYYY or MM/DD/YYYY)". --Redrose64 (talk) 21:36, 19 August 2013 (UTC)

Thanks. I know there are many different screen sizes these days; I was just trying to lay it out best for a laptop. Something will always look errant on some screen. I also took care of the dates and caption. Jsayre64 (talk) 04:28, 20 August 2013 (UTC)

Session cookie name

Hi, just wanted to spread the word about a change in session cookie names:

Please note that the session cookie name on WMF wikis has changed from wiki_session to wikiSession. That is, for example, enwiki_session to enwikiSession.

This was done in response to a security issue -- we had to find some way to rapidly cause all session IDs to be regenerated. Changing the cookie name was the simplest way to achieve that. More details should become available once we are sure that the security issue is fixed.

Hope this doesn't cause anyone trouble. Sumana Harihareswara, Wikimedia Foundation Engineering Community Manager (talk) 21:09, 19 August 2013 (UTC)

I can't help but imagine this is going to affect a good quantity of tool/bot authors; at least those whose tools do login actions for the purpose of editing. For my tool, this change meant the cookie was mis-parsed, leading to invalid edit tokens being generated, and the rejection of every edit attempt (see Wikipedia_talk:STiki#Errors). I understand the need for the change, but a broad(er)(?) announcement might aid those being affected by the change. I don't know what has currently been done, but my earlier attempts to root out this issue found little documentation change across the API and other sources I use for such news. West.andrew.g (talk) 23:20, 19 August 2013 (UTC)

Special:MIMESearch

This page says, in bold text, "This page is disabled".

It actually works perfectly fine. What's up with that? Adam Cuerden 21:53, 19 August 2013 (UTC)

This was recently fixed in gerrit:67468. We have locally overridden labels that we need to correct. Taking care of it. —TheDJ (talk • contribs) 22:09, 19 August 2013 (UTC)

updating categories

Is there any way to speed up articles being added to tracking categories? WP says that it could take days to weeks, but based on how slowly a cat I created a month ago is filling up, it looks like it might be months to years, at least for articles that aren't edited. I used to add tracking categories to templates in order to find problems in our articles, and they would fill up in a few hours or at most a couple days, but this time it's been so slow that it's impractical to do this. — kwami (talk) 22:25, 19 August 2013 (UTC)

The job queue, which handles this, was changed a few weeks ago and since then, template mods which alter categorisation have, as you say, taken weeks to go through. This template mod, for example, took at least three weeks to shake out all relevant pages. --Redrose64 (talk) 23:36, 19 August 2013 (UTC)

Well, that explains it. But after 3 weeks, a mod of the language infobox was only maybe 10% categorized. Is this change going to be relatively permanent? — kwami (talk) 02:29, 20 August 2013 (UTC)

Wow, another cat triggered by the same template shows 1,300 articles in less than a week, so maybe there was s.t. odd about how the other one was coded. — kwami (talk) 08:52, 20 August 2013 (UTC)

Should an account security option be developed?

A recent RfA has highlighted a community concern that I believe could be alleviated by the technical development of a doable, I would think, security option. The angst surrounds people who are editing from an environment where an IP is shared, exacerbated when other people routinely have access to the computer an admin uses when editing. I believe we should have an option that causes the software to log the user out after a defined period of inactivity; similar to what all online banking accounts I've ever used do as a security norm.

We have an option to remain logged in for an extended period; shouldn't we also have an option to automatically log off as well? How difficult would such an option be to develop? Would anyone considering this idea be willing to help develop a proposal if it is shown to have merit? Thank you for considering this and perhaps helping to develop the idea. :) John Cline (talk) 20:19, 19 August 2013 (UTC)

This seems more like a question for WP:VPT. Ironholds (talk) 23:26, 19 August 2013 (UTC)

I agree as indicated by the move. Thanks Ironholds! :) John Cline (talk) 00:53, 20 August 2013 (UTC)

HTTPS for logged in users on Wednesday August 21st

• Misplaced Pages noticeboards
• Pages automatically checked for accidental language links