When I view my userpage today, I see that my usually neat arrangement of Barnies has been blown up, some of them ridiculously. They look awful. No relevant edit
The "pxpx bug" has now been fixed in the MediaWiki software. Thus most of the discussions below are now only of historical interest.
When I view my userpage today, I see that my usually neat arrangement of Barnies has been blown up, some of them ridiculously. They look awful. No relevant edits to the page. I'm using Firefox 2.0.0.12 on Windows XP Professional. Any help gratefully received. --Dweller (talk) 11:25, 25 March 2008 (UTC)Reply
(ec) Removing the "px" from the size parameters appears to fix the issue. {{Click}} was changed recently to use <imagemap>, which may have caused the "px" to become unnecessary. --TMFLet's Go Mets - Stats11:30, 25 March 2008 (UTC)Reply
I've suggested at the template talk page that they task a bot to go off and fix the puzzling mess lots of editors will be faced by when they next view their userspace. I've seen this problem at any number of user's user or usertalk pages already today. --Dweller (talk) 12:55, 25 March 2008 (UTC)Reply
I've responded to Dweller on Template talk:Click, but I'll move the bulk of my comments here for wider scrutiny. Given that {{Click}} doesn't seem to have been updated since February 2 (diff; it's worth noting that User:Ryulong updated the documentation to remove "px" today, though), I don't think it's to blame for the sudden change. Rather, it seems to me that the implementation of the "px" measurement is now a bit screwy throughout the 'pedia, as indicated by User:CambridgeBayWeather's post below.
I've looked through the Bugzilla reports, and it seems that there was a report made yesterday by User:FT2 concerning font scaling and "px" (bugzilla 13494). Given that this bug is listed as still being open, I don't think that the big images can necessarily be blamed on it, but it's certainly something to consider. --jonny-mt13:54, 25 March 2008 (UTC)Reply
Indeed. Check out [1] - note how all of the images with "pxpx" in their image size are displaying as if there are no sizes specified. Also check out my comment in the section below, which ties into this. --TMFLet's Go Mets - Stats14:09, 25 March 2008 (UTC)Reply
(ec) If it's a permanent change, then we may need a whole slew of bots to help out :) I've gone ahead and filed Bug 13500 in the hope of getting to the bottom of this. Hopefully Bugzilla adheres to WP:BITE, too.... --jonny-mt14:11, 25 March 2008 (UTC)Reply
Gah. I'm the one who updated the template on 2008-02-02; I even wanted to use a bot to manually correct the syntax before updating, or at least AWB, but was convinced otherwise by someone who found that it wasn't an issue (then). A bot correction run sounds good; that's the easiest solution. Nihiltres{t.l}15:21, 25 March 2008 (UTC)Reply
Are we basically saying that we need to have as many editors as possible program as many bots as possible to change [[Image:...pxpx...]] to [[Image:...px...]]?? If so, use the regex (\[\[Image:[^\]]+\|\n?\d+)pxpx([^\]]*\]\]) --> $1px$2 - I think it's pretty reliable. If the problem is elsewhere, then so is the solution :D. Happy‑melon16:31, 25 March 2008 (UTC)Reply
Tim Starling has responded to the Bugzilla report above noting that he changed the code so as not to allow resizing using "pxpx" per Bug 13436, so that confirms the root cause indicated by TMF (the specific revision has a 5:17 UTC timestamp). It seems to me that the best solution is to edit all templates using "px" by default to remove the offending markup. I imagine there will be a new wave of fun stuff to deal with if we do that, of course, but maybe it's time to go ahead and focus on a bot request? --jonny-mt16:24, 25 March 2008 (UTC)Reply
I personally think the best way would be to leave the templates alone and remove the offending "px" from its transclusion calls. Will it ultimately require more edits? Yes, but on the article level, it is more efficient in the long run IMO. (FWIW, I just spent an hour removing "px" from pages that transclude {{OHShield}}, since the template already includes "px".) --TMFLet's Go Mets - Stats16:33, 25 March 2008 (UTC)Reply
Also consider that either method is likely going to cause some type of mass article editing. Scenario: If "px" is removed from a template's code, then all the articles that correctly just had the number will need to be fixed. If "px" is left in the template, then the articles that incorrectly have "px" need to be fixed. It's pick your poison, I suppose... --TMFLet's Go Mets - Stats16:57, 25 March 2008 (UTC)Reply
OK, I have a fix available. MelonBotis in the process of creating has now created a matrix of pages at User:MelonBot/ClickFix/nnnpx, where nnn is a number between 0 and 999. This enables a simple fix:
Add the code <includeonly>{{#ifexist:User:MelonBot/ClickFix/{{{suspect_parameter}}}|[[Category:{{subst:PAGENAME}} needing ClickFix|{{PAGENAME}}]]}}</includeonly> to any template which may be affected, replaicng suspect_parameter with the name of the parameter which may be holding duplicate "px" in instances (usually something like imagesize, width, etc).
Once they work their way through the job queue, broken instances will be categorised into this category, where they can be fixed manually, or by bot using suitable regexes.
I just hit this on a number of main-page train station articles. I edited them for something unrelated, and the images went haywire. For those of us less wiki-code inclined, is there anything we can/should do to fix this? A quick glance at {{Infobox Station}} shows no references to this pxpx mentioned above. - TexasAndroid (talk) 18:31, 25 March 2008 (UTC)Reply
I removed the px from the template itself, but am currently second-guessing myself as to whether that was the correct fix. If anyone agrees, please feel free to revert me. - TexasAndroid (talk) 18:49, 25 March 2008 (UTC)Reply
Bad idea - I see it was quickly reverted. Essentially that just breaks all the currently unbroken instances, and we don't have a way to find them. Happy‑melon19:55, 25 March 2008 (UTC)Reply
I'm seeing it hit Featured Article and GA icons on userpages. Seems very widespread. Could you crank up the maxlag on Melonbot? MBisanztalk20:02, 25 March 2008 (UTC)Reply
The hit and miss looking I'm doing is finding *lots* of infobox templates with image size parameters, but the spot checks I've done so far have not found any more specific instances of these size parameters in use. As long as the parameter is empty, we are OK. But the problem is that each of these templates has many, many articles on them, and any one of which could easily be using the size parameter and hitting the problem. So far we are finding the templates where the image size parameter is in wide use. But the problem ones will be the many, many templates where most do not not use it, but a few do. - TexasAndroid (talk) 20:11, 25 March 2008 (UTC)Reply
OK, I've created Wikipedia:ClickFix, with a brief explanation of the problem, and how to fix it. It was made in an awful rush, so feel free to clean it up, expand, rewrite, etc. Do you think it's bad enough to warrant a sitenotice or watchlist-notice? Happy‑melon20:14, 25 March 2008 (UTC)Reply
Short answer, unforseen consequences from a meta-wiki coding change. Long answer, read the page attached to this talk page. It summarizes the situation better than I ever could. - TexasAndroid (talk) 21:25, 25 March 2008 (UTC)Reply
There's a coarse description of what's going on, and why, on this page's project page (Wikipedia:ClickFix). If there's anything there that doesn't make sense, do say and I'll rewrite it - it was done in a bit of a hurry. Happy‑melon21:32, 25 March 2008 (UTC)Reply
As an aside, I've added a test to Infobox Station which tries to detect non-numeric input for the image size, and leaves off the 'px' if present. Mackensen(talk)03:36, 26 March 2008 (UTC)Reply
It seems to be the same "px" problem as above. Remove them from the image size, and I'm betting you'll be fine. --jonny-mt13:36, 25 March 2008 (UTC)Reply
Based on both this and the above section, I'm beginning to believe something was changed in Mediawiki so "200pxpx" is no longer interpreted as "200px". --TMFLet's Go Mets - Stats13:41, 25 March 2008 (UTC)Reply
See T15500. The previous functionality permitting "pxpx" to be interpreted as "px" now no longer works. This mostly happens when a template uses {{{height}}}px or something and people specify height=200px. Just change that to height=200 and it will work as desired. —Simetrical (talk • contribs) 17:30, 25 March 2008 (UTC)Reply
Since the AA and KLM logos have "px" in their calls on their articles, it ends up being "pxpx", and thus the software basically voids the size specification and displays the images at their full size. There is no size specified for the Emirates logo at its article, so the size just defaults to whatever the default size is for that template. --TMFLet's Go Mets - Stats18:00, 25 March 2008 (UTC)Reply
Wow, and I thought we had a lot of railway station articles. I've gone through a bunch of the airline pages in the maintenance category, and it's already back up to the same count when I started (but the station, locomotive and rail infoboxes are down to 0 right now). I saw comments about {{Infobox park}}, but it looks like project members there are working from the template end first. Slambo(Speak)20:44, 25 March 2008 (UTC)Reply
I left a comment above. 2 of my fellow wikipedians have experienced even worse causes and I can't see a way around it. I've had to do something I didn't want to do to many other things. Chubbennaitor21:26, 25 March 2008 (UTC)Reply
Also something else. It happened around "10:00 am"ish on 25th March 2008. It happened during the time I was editing and it took me an hour of my afternoon to try and fix my userpage. Chubbennaitor21:30, 25 March 2008 (UTC)Reply
I've boldy added a notice to the watchlist and recent changes, which should increase awareness. Makes me even more embarrassed to put my name to the contents of Wikipedia:ClickFix, however - I'm going to have to rewrite a bit. Happy‑melon21:48, 25 March 2008 (UTC)Reply
How about this
Latest comment: 18 years ago2 comments2 people in discussion
If I give a code like this: {{whatever|image=wiki.png|size=15px|caption=wikipedia}}, it will be . And if this: {{whatever|image=wiki.png|size=15|caption=wikipedia}}, it also will be . Maybe it's a way to solve the problem.--PhiLiP (talk) 09:40, 26 March 2008 (UTC)Reply
I tested your solution in all three of my web browsers. And I checked the XHTML output from MediaWiki. Your solution seems to work perfectly. Very elegant. Now I am not sure if I prefer the {{px}} template solution (see below) or your solution, both are easy to use. So now we have two good solutions!
Latest comment: 18 years ago10 comments4 people in discussion
I have packaged a solution as the template {{px}}. It allows templates such as {{Infobox Airline}} to receive their image size parameter both with or without the "px" ending.
Here's what it does. Code to the left, actual rendering to the right:
{{px|40}} = 40px
{{px|40px}} = 40px
It is based on the code that MZMcBride added to {{Click}}. But I think packaging it as {{px}} makes it much easier to use. I have added it to {{Infobox Airline}} and it seems to work perfectly.
And to copy parts of PhiLiP's example above, {{px}} should be used like this:
After now having seen the {{px}} template in use in some other templates I think that its name is a bit to cryptic. I am thinking of moving the template to the more descriptive name {{add px}}. Thus making the code example above look like this:
I don't think that's necessary - by all means create a redirect, but we have some templates at pretty wierd titles without any problems. Let's be honest, {{tlx}} is not particularly intuitive! Remember that in some cases (less likely here, but could still apply) pre-expand byte-count may be at a premium, so a shorter title (which is also quicker to type and doesn't fill the edit screen as much) would be valuable. In short, redirect = good, move = unnecessary. Happy‑melon14:04, 26 March 2008 (UTC)Reply
Ah, you got a point there. So the short name stays. And I won't add a redirect since I don't like to add to the confusion when I make new templates. Besides, usually people want shorter names for my templates so they add redirects from shorter names.
By the way, the last three templates I made was {{tlc}}, {{tld}} and {{tlf}}. So I guess I am adapting to popular demand for shorter names. :))
Since {{px}} is now getting transcluded onto a very large number of pages, I've protected it as a high-risk template so only admins can edit it. Slambo(Speak)18:31, 26 March 2008 (UTC)Reply
Latest comment: 18 years ago9 comments5 people in discussion
...wouldn't it be more appropriate simply to reverse the attempted software fix? It seems to have broken far more than it mended.--Kotniski (talk) 13:46, 26 March 2008 (UTC)Reply
It was instituted to solve a completley different (and much more serious) issue whereby it was impossible to write an image caption which began with "upright", "thumb", etc, or (most relevantly) ended in "px". That's never been an issue on en.wiki, but the bug was filed after a user on w:cs: tried to write a valid image caption which ended in "px". That is, unfortunately, a more pressing problem than the issues we've got here with image sizing (although presumably the problems must be wikimedia-wide, as everyone else must have been just as lazy as us in their image captions). To be honest, I don't think that more rigorous type-checking is actually a bad thing! Happy‑melon14:01, 26 March 2008 (UTC)Reply
Fair enough. But it shouldn't be too hard just to reintroduce NNNpxpx as an acceptable sizing notation. After all, I doubt you get many words ending "pxpx", even in Czech;) --Kotniski (talk) 14:53, 26 March 2008 (UTC)Reply
Agreed -- at the least, it seems like it could be an option turned on or off for each Wiki so that languages which don't use pxpx aren't affected by the problem. Wikis should be easy to use and edit. Making people remember which templates use "px" and which don't goes against this spirit. (If I want strict checking, I'll code in XHTML) -- Myke Cuthbert(talk)19:59, 26 March 2008 (UTC)Reply
Special-casing "pxpx" is an option. Nobody seems to be doing it at present, however. It looks like things are getting pretty well fixed up without that. I'm not sure usability is a huge issue here, templates are pretty intricate anyway and you've got to be fairly hardcore to use them properly. If this had always been checked strictly, people would have just used a single format (either with or without "px") to start with, and not gotten themselves confused by mixing them up. —Simetrical (talk • contribs) 14:14, 27 March 2008 (UTC)Reply
Okay, I've fixed this in r32504. "pxpx" will now work, as of the next scap. Developers have to strike a balance between being backwards compatible, and having features work reasonably and as expected for new users. In this case we were maybe a little too inclined toward the latter. —Simetrical (talk • contribs) 14:34, 27 March 2008 (UTC)Reply
Simetrical: Are you aware of the other image tag parsing bug? The one involving empty parameters and (lack of) spaces? If not, see the discussion at Template talk:Px. That bug needs fixing too.
See my comment there. It seems unrelated. I'd assume it's much older than this commit, and people just mentioned it when it came up in the context of this Template:Px when they were already in a bug-hunting mood. —Simetrical (talk • contribs) 18:59, 28 March 2008 (UTC)Reply
Reverted?
Latest comment: 18 years ago2 comments2 people in discussion
Has this software change perhaps been reverted? I don't see anything special on the supposedly broken pages mentioned here. Ucucha14:25, 26 March 2008 (UTC)Reply
Latest comment: 18 years ago7 comments5 people in discussion
So.. 'this page in a nutshell', rather than just include some simple legacy support for old ways of specifying image sizes, editors can just go ahead and double check those 2.3 million articles real quick - make sure those templates are showing up right. Um, thanks, I'll get right on that. Brando130 (talk) 14:39, 26 March 2008 (UTC)Reply
There's an "edit" link at the top of this page just like any other. When it was written, there was no other alternative. If you want to write a section about {{px}}, you don't need to ask. Happy‑melon14:43, 26 March 2008 (UTC)Reply
'No alternative.' I just don't buy it. I think Wikimedia dropped the ball on this one, and they should be involved in fixing it. Instead editors are stuck trying to implement different solutions themselves across the entire project, and you somehow seem to have got stuck defending that. Maybe a few more donations and they've have the money to code 'workarounds' into new versions of Wikimedia that actually support old ways of interpreting Wiki markup? I'm sorry but, pathetic. Brando130 (talk) 17:44, 26 March 2008 (UTC)Reply
Absolutely. Has anyone actually done anything to sort out this problem, which appears to have affected parts of the entire encyclopedia? Please DONT tell me how to fix it – I have tried. And perhaps responses could be in plain ENGLISH, as most users don't understand a word of what is written above, on this page.
May I lend my voice to those clamouring to insist that whoever caused the problem should UNDO the coding which caused the glitch in the first place – and quickly, please.
Agendum, it appears that the issue on the page you were editing was that the infobox parameters were also specifying an image height; removing the height parameter and removing the px from the width parameter brings the image down to a more reasonable size. I've made these edits to that page. Slambo(Speak)18:22, 26 March 2008 (UTC)Reply
200px wide image? No.
I partly agree with the complaints. The MediaWiki code could parse the parameters for images much smarter than they do now. On the other hand, it is pretty strange for a "function" like [[image: ...]] to accept faulty input. But as we have seen, it is hard to know for people if they should feed image size as "40" or "40px" and when that is done in several layers through calls between templates it can end up as "40" or "40px" or "40pxpx" depending on where along the chain the "px" is added to the number. So yeah, in this case there probably should be an exception. MediaWiki should probably take the numbers and chop of the ending characters, at least on the first parameter that starts with numbers and that comes after the image name. Problem is that the parameters are unnamed and are allowed to be written in any order, thus it is hard to really tell which one is the image size. Look at the code I used for the thumbnail image to the right:
Not so easy to decide on a proper parser function that correctly guesses which parameter is the image size and which is the caption if the function should allow faulty image size input.
Let's not forget that this change is only causing a problem because we've all been so lazy for five years. If this had been in MediaWiki from day one, there would have been absolutely no problem: if you add an image to an article and it appears a wierd size, try it with or without "px" on the size parameter, and you'll find what works. This is now the case for new image additions - it is only the existing images that are a problem. These will eventually sort themselves out, and we can continue as normal, with the added benefit of being able to write an image summary ending in "px" if we choose to do so. To the editor who wrote something to the effect of "don't tell me to fix it" above, I can only ask "Why are you here?" The editors are there for the encyclopedia, not the other way around. You want the fix in a nutshell? "Try adding or removing "px" from image parameters". It's a Wiki: if the answer is not obvious, experiment until you find it. Similarly, if you think you can write a better image parser, MediaWiki is open content just like Wikipedia. Anyone can propose MediaWiki revisions, just like anyone can propose changes here. Go on, I think it's somewhere in here. Happy‑melon21:11, 26 March 2008 (UTC)Reply
The bugfix: Can it be made more flexible?
Latest comment: 18 years ago1 comment1 person in discussion
Can the bugfix that brought this syntax issue to the surface be modified so that it is more lenient about whether the size is designated with nothing, with px, or with pxpx? --SSBohio21:51, 26 March 2008 (UTC)Reply
We need more spaces
Latest comment: 18 years ago1 comment1 person in discussion
There seems to be more problems with the image tag parsing than just the "pxpx" bug. Under some circumstances lack of spaces inside the image tag makes it fail. See discussion at Template talk:Px.
Latest comment: 18 years ago3 comments2 people in discussion
I see Bratislava with a huge image, however if I edit the page, make no changes and then preview it looks fine. I am sure this is related to this problem somehow.
Latest comment: 18 years ago1 comment1 person in discussion
I just noticed that the "pxpx bug" has now been fixed in the MediaWiki software here at the English Wikipedia. MediaWiki now again tolerates image parameters like "40pxpx" and "40x40pxpx".
However, those of you who need to handle multiple image size parameters and/or default sizes should still have good use of the template {{px}}.
Informasi ini disarikan dari Wikipedia dan disajikan kembali untuk tujuan edukasi. Konten tersedia di bawah lisensi CC BY-SA 3.0. Kami tidak bertanggung jawab atas ketidakakuratan data yang bersumber dari kontribusi publik tersebut.
The information displayed on this website is sourced in part or in whole from Wikipedia and has been adapted for the purpose of restating it. We strive to provide accurate and relevant information, however:
There is no guarantee of absolute accuracy. Wikipedia is an open, collaborative project that can be edited by anyone, so information is subject to change.
It is not intended to constitute professional advice. The content displayed is for informational and educational purposes only. For important decisions (e.g., medical, legal, or financial), please consult a professional.
Content copyright. Wikipedia is licensed under the Creative Commons Attribution-ShareAlike License (CC BY-SA). This means that content may be reused with appropriate attribution and shared under a similar license.
Responsible use. Any risk arising from the use of information from this website is entirely the responsibility of the user.