Wikipedia

Wikipedia:Village pump (technical)/Archive 9

< Wikipedia:Village pump (technical)
Village pump (technical) archive  

This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Defining new CSS classes or IDs?

Previously asked but unanswered at Wikipedia:Help desk

Is there any way to create a new CSS class or ID in a single page, but have it apply to all viewers? The only thing I can find is to modify my own monobook.js, which would apply only to me, or a site-wide change to MediaWiki:Common.css which is obviously not an option. I tried using <style></style> tags but MediaWiki seems to escape them out. I can't just use inline CSS style="" attribs because common classes are overriding it. —dgiestc 23:21, 29 November 2007 (UTC)

No, there is no other way. Use inline CSS - it should override classes (care to give us an example where it doesn't?) ∴ AlexSm 00:05, 30 November 2007 (UTC)
I believe there are separate css files for each of the seven skins, in the MediaWiki namespace. I hope that we're not talking about some unilateral change that noticeably affects everyone. -- John Broughton (♫♫) 00:42, 30 November 2007 (UTC)
I absolutely am not asking for a unilateral change, but can someone figure out how to override list-style-image for bulleted lists (class li)? —dgiestc 03:52, 30 November 2007 (UTC)
You could, I think, use inline styles, but you would have to fully use html - no wikimarkup using * or anything. So, raw <ul> and <li> tags. Because if you use *, that comes with its own (entirely plain) <ul> tag. —Random832 04:21, 30 November 2007 (UTC)
Also, you can't actually change the image with a manual <li style="">. The mediawiki xml whitelist doesn't allow image stylings in wikicode because it would allow you to bypass [[image]] syntax and even hotlink, it gets censored right out. What you *can* do is something like:

<ul><li style="list-style-type: circle; list-style-image: none;">Bar</li></ul>

  • Bar
See this thingy for more info. --Splarka (rant) 08:36, 30 November 2007 (UTC)
Ah, good point about security. I figured there must be a good reason. Thanks. —dgiestc 16:50, 30 November 2007 (UTC)
Any chance of a feature being added to allow CSS image references to wikipedia images? e.g. list-style-image: wiki_image_url("example.png",10) —Random832 14:55, 30 November 2007 (UTC)
That's not legal CSS. To support something like that we'd need some sort of JavaScript hook to examine CSS properties and rewrite them as proper URLs. —dgiestc 16:50, 30 November 2007 (UTC)
Neither is <br> valid XHTML, but the parser takes care of it. MediaWiki could replace wiki_image_url() with url(), just as it replaces Image:Example.png with an <img> tag with this src. GracenotesT § 18:20, 30 November 2007 (UTC)
To clarify, What I was asking for was for mediawiki to replace that with a url reference to the proper image file, in the same section of the code where it currently blocks url references. —Random832 21:06, 7 December 2007 (UTC)
But do we really need it? I mean there are so many special things we could account for in mediawiki, but should we really try to. It gets so humongously complicated. --TheDJ (talk • contribs) 21:26, 7 December 2007 (UTC)

BetacommandBot

On http://en.wikipedia.org/wiki/User_talk:BetacommandBot there are several recent entries about this bot mistakenly identifying images as orphaned. What's the history of this bot, and why is it seemingly broken? - Bevo 02:45, 1 December 2007 (UTC)

yes there was a problem with the API that caused BCBot to tag some images by mistake as orphan. βcommand 03:09, 1 December 2007 (UTC)
Is there any residual effect of that mistake? Can we just disregard the notices that it put out once we affirm that they are not orphaned, and are proper to use within the articles that include them? - Bevo 03:51, 1 December 2007 (UTC)
you can ignore the notices that said the image is orphaned, but in regard to any other notices those are valid. and are proper to use within the articles that include them? cannot be judged by a bot. when ever you include a non-free image in a article make sure that you have a good rationale βcommand 03:57, 1 December 2007 (UTC)
Well, this will be a good test of whether admins deleting BCBot-tagged images actually review them, eh? =] GracenotesT § 04:15, 1 December 2007 (UTC)
all of the image tags have been reverted, from the bot errors. βcommand 04:16, 1 December 2007 (UTC)
Ah, great; thanks. WP:BOT does recommend such reversion. GracenotesT § 04:22, 1 December 2007 (UTC)
Would you mind elaborating upon exactly what problem with the API caused the malfunction? A "problem with the API" is rather nondescript, and I would like to ensure that the problem has indeed been corrected and will not repeat itself. AmiDaniel (talk) 09:32, 1 December 2007 (UTC)
I dont know exactly what happened, it appears that the normal HTML API request was giving less data than normal, the standard request for an orphan image is either 19 or 20 lines, I forget off hand which it is. (I dont have my code handy). But for some reason the API was give less than that for every request. βcommand 23:20, 5 December 2007 (UTC) —Preceding unsigned comment added by Betacommand2 (talk • contribs)
I'm wondering if it would be possible to, every time the bot starts up, or every hour or so if it runs continuously, do a sanity check by e.g. looking to see if an image (doesn't have to be a non-free one) that you know will never be orphaned shows up as orphaned; and if it does, due to another API error, the bot could shut down. And various similar checks for other assumptions it makes about API responses.—Random832 21:46, 7 December 2007 (UTC)

Rollback for regular users

Hi all,

I've been working on resolving some lingering security issues with the rollback permission in the software, which I've now completed. Included in this is a limit on use of the rollback permission to a few times per minute (depending on server settings) just as edits are limited, and preventing any old person with the rollback permission from hiding edits from recent changes (this is now only assigned to sysops). In particular, rate limiting ensures that reverting can occur at only a slow pace (probably 1-3 per minute) by regular users (NOT admins), and thus mass-rollback by a new user is no faster than manual reversion (since manual reversion is limited to something like five edits per minute, which can be done much quicker using a tabbed browser).

Since these issues have been resolved, I've discussed with Tim Starling (the senior developer) the possibility of enabling rollback for broader classes of users, likely autoconfirmed, logged-in, or all users. Tim and a number of other developers have agreed that this is a sensible idea, and my current intention is to, by default, enable the rollback permission for all logged-in users in a few days.

I want to know what the general consensus is on this issue. I understand that it's particularly sensitive for those of you who are vandal-fighters (particularly administrators), but I believe that my improvements are sufficient to make quick reversion for vandalism a reality for those vandal-fighters who find it frustrating to be denied access to this useful tool, especially seeing as this is already possible with only two more clicks, or a javascript tool.

— Werdna talk 07:54, 3 December 2007 (UTC)

The undo button is already right there, and I was using rollback with javascript well before adminship. Sounds like the features that really should be admin only (mass rollback, hiding from recent changes) are still admin only, I don't see any problem enabling it for autoconfirmed users. I wouldn't really support putting the bar any lower than that, though, very few anons or brand-new users would be making good use of the rollback button. We'll also have to likely improve education on acceptable and unacceptable uses of rollback, but I think that can be done. Seraphimblade Talk to me 08:03, 3 December 2007 (UTC)
Concur. A typical edit-warrior reverts on a limited set of pages, so throttling would be of little use in preventing him from warring. Rollback for everybody will simply introduce another kind of edit-wars: when two (or more) users revert each other in one article using this tool. Another problem to consider is that we expect admins to know when to use automatic rollback and when not. Can we we expect the same from novices? MaxSem(Han shot first!) 09:01, 3 December 2007 (UTC)
This seems scary at first glance, but it's really not any worse than giving the undo button to everyone. Further, every couple of days I see someone revert vandalism on an article with undo or a javascript tool, leaving their edit on top but vandalism in the article; this happens when there's an intervening edit to a different section of the article which gets merged instead of edit-conflicted (example: [1] [2] [3] [4] [5]). This cannot happen with rollback. —Cryptic 09:42, 3 December 2007 (UTC)
It seems like a good idea to me, for autoconfirmed users SQLQuery me! 10:41, 3 December 2007 (UTC)
As stated, this seems essentially useless - there is a proposal that is gaining some traction to allow _full_ use of rollback (no rate limits, still does the recent changes thing) for a limited class of users (would have its own permission bit) specifically trusted with this tool, such as anti-vandalism bots (e.g. Cluebot). Is there a way to do both? I.e. enable your idea for normal users, and allow a separate group, or maybe the bot group, access to the "sysop rollback" tool? —Random832 15:08, 3 December 2007 (UTC)
It is probably still possible to add a group with the full rollback powers. FunPika 21:07, 6 December 2007 (UTC)
  • Not sure on this, but am sure that that entry barrier should be AT LEAST autoconfirmed. — xaosflux Talk 13:25, 4 December 2007 (UTC)
    • There is no category that is between "admin" and "auto-confirmed" (account is four days old). Auto-confirmed could be kicked up a bit (proposals to increase it to, say, at least 25 edits have not been successful); creating a class of trusted/privileged/special regular editors would be a huge change. -- John Broughton (♫♫) 20:11, 4 December 2007 (UTC)

I've spoken to brion, and suggested the following rate limits:

  • FIVE rollbacks per TWO minutes for new users.
  • FIVE rollbacks per ONE minute for autoconfirmed users.
  • NO limit whatsoever for administrators.

Barring some significant objection that I haven't thought of before, this change will be live in a day or two, once brion's set up the limits, and given the go-ahead for me to make the change. Thanks for the input, — Werdna talk 04:43, 5 December 2007 (UTC)

Will this apply to en.wp only? – Mike.lifeguard | @en.wb 22:36, 5 December 2007 (UTC)
Can we get consensus first before this is implemented, I think there's some quite legitmate concerns here that need to be addressed first. Ryan Postlethwaite 22:43, 5 December 2007 (UTC)

In the absence of substantive objections, this change has been effected in r28193. Both Brion Vibber and Tim Starling have approved of the change, and Brion has applied the rate-limits listed above. All users should have access to rollback functionality when the MediaWiki software is next synchronised to the Wikimedia Foundation's servers. Thanks to those above for offering input into this change. — Werdna talk 04:41, 6 December 2007 (UTC)

I think you'll find there's no support for your proposal, so I would appreciate it if you didn't implement it. Ryan Postlethwaite 00:25, 7 December 2007 (UTC)
I support it, and would be grateful if you would implement it. DuncanHill (talk) 00:30, 7 December 2007 (UTC)
I don't particularly see any consensus for the change to happen, and in fact a consensus against it, and that should be respected. Ryan Postlethwaite 00:36, 7 December 2007 (UTC)
I don't see a consensus against it in this thread. It woul dbe extremely useful to those of us who watchlist certain pages subject to frequent vandalism. If someone misuses it they can be dealt with just like anyone misusing any editing function. DuncanHill (talk) 00:41, 7 December 2007 (UTC)
There's a greater consensus against if you look above. Rollback edits are marked as minor, so they don't show up in some RC feeds and watchlists, so a vandal could quite easily go on a spree of blind reverting random users contribs quickly - there could be quite a mess caused by this. It might be helpful for some in the right hands, but it's seriously not a tool to be messed with, and in the wrong hands, could do a lot of damage. Also it is highly likely to be used in edit wars, allowing far greater escalation of them. Ryan Postlethwaite 00:46, 7 December 2007 (UTC)

Um, did everybody forget the sheer scale of discussion around WP:RFR not so long ago, coupled with a 300-person poll? Please don't accidentally forget about that aspect of things by collecting a couple of vaguely nodding heads on this quiet backwater! Splash - tk 00:48, 7 December 2007 (UTC)

I agree. At worst it's an experiment to see if it is as bad as the naysayers imagine. If so, it can always be undone. While discussion and consensus are wonderful tools, they're often not as effective at diving reality as a pertinent experiment. —EncMstr 00:49, 7 December 2007 (UTC)
This is an experiment with the potential to cause serious problems. Ryan Postlethwaite 00:51, 7 December 2007 (UTC)
Never saw WP:RFR - was it publicised much? DuncanHill (talk) 01:04, 7 December 2007 (UTC)
Enough that 300-odd people participated at Wikipedia:Requests for rollback privileges/Poll... Splash - tk 01:06, 7 December 2007 (UTC)
So I see - and rather more supports than opposes too. DuncanHill (talk) 01:09, 7 December 2007 (UTC)
Not enough by far to effect what at the time was an ambitious proposal to create whole new classes of user and processes to grant and revoke the right. Werdna has the advantage that, instead of having to construct a technological proposal which makes minimal development demand and effectively transfer the angst to the community, he is able to take on the technological issues and thereby minimise the impact on the community. For example, any on-wiki proposal containing the limits in Werdna's patch would be - rightly - shot down immediately as being far too overambitious on the development front and therefore pointless. Arising instead by someone writing the code to do exactly as they like, that aspect of things immediately vanishes. Splash - tk 01:16, 7 December 2007 (UTC)
I think it'd at least useful if we could take rollback away from a user (such as in cases of using it in content disputes). John Reaves 01:51, 7 December 2007 (UTC)
Any administrator should be able to disable the rollback ability of any editor (not administrator), for me to support this proposal. Otherwise, we'd be forced to block them, and that isn't a Good Thing in many cases. Daniel 01:55, 7 December 2007 (UTC)

I've started a centralized discussion at Wikipedia:Rollback_for_regular_users. Any comments on the rollback decision can be left there, including any proposals to change who gets it, the number of reverts per minute. Support or opposition for the plans can be left there. Nick (talk) 01:57, 7 December 2007 (UTC)


I made this software change (read: the change was to the MediaWiki software that happens to run the English Wikipedia, not the English Wikipedia itself) to all Wikimedia wikis with the permission and support of Brion Vibber, Chief Techology Officer of the Wikimedia Foundation, and Tim Starling, generally considered to be "second-in-command" on issues relating to software development. As a courtesy to the users of English Wikipedia, from whom I anticipated problems on the issue. After giving these users three days to show cause as to why the change should not be made, I received no substantive objections. As such, I made the change. I am somewhat bewildered as to why this mass of objections has suddenly appeared, given the lack of objection I had to the very very similar (undo) modifications. In any case, I think Rick's point about minor edits is a good one, and as such I've made software amendments (r28238) so that rollbacks by users not entitled to mark edits as minor are not marked as minor. As for edit wars, (undo) is just as bad. It is my suggestion that English Wikipedia's consensus should not dictate MediaWiki developmental decisions. Therefore, I suggest that disabling rollback for ordinary users should be done in the site configuration, and therefore a consensus should be formed on English Wikipedia, and a bug filed with bugzilla, as with requesting configuration changes of any other kind. I do ask that you wait and see how it works for the next few weeks — and work with more restrictive rate-limits before disabling rollback entirely, if problems occur. — Werdna talk 09:40, 7 December 2007 (UTC)

It think that MediaWiki developmental decisions shouldn't interfere with content management decisions inwiki. →AzaToth 14:39, 7 December 2007 (UTC)
I think you got little feedback because it was posted only here, where few people saw it. WP:AN or WP:VPP might be better shots. However, I agree that the development of Mediawiki need not depend on enwiki's views and equally, enwiki's adoption of those developmental features where there is serious contest should be made switchable. Which appears to be exactly how you've done it. Otoh, if it's just going to be switched off and then a requirement for a demonstration of the want to turn it off, that's less optimal. Splash - tk 16:08, 7 December 2007 (UTC)
  • Enabling Rollback for non-admin users should be decided by each wiki per rev 28248 (where the line of code enabling rollback for all users has been removed). FunPika 22:03, 7 December 2007 (UTC)
How is a new user going to understand that rollback is more of an undo than undo is. Very confusing wording there. That would be a problem. Prodego talk 22:28, 7 December 2007 (UTC)

Pop-up probs

My pop-ups seem to have stopped working. I added a "sort watchlist" thingy to my monobook, that didn't seem to work, so I reverted my monobook to where it was before, but now my pop-ups don't work. I am by no means adept at monobook stuff, so any help or advice would be much appreciated. Thanks, DuncanHill (talk) 13:55, 5 December 2007 (UTC)

They seem to have started working again :) DuncanHill (talk) 13:58, 5 December 2007 (UTC)
For changes in your user scripts or CSS to take effect, you must bypass your browser cache (typically hold "shift" while reloading a page) once.—Random832 18:29, 7 December 2007 (UTC)

Inserting a non-numbered item in a numbered list

In a number-bulleted list, how do you include a non-numbered bullet without causing the numbered bullets from starting over at 1?

The Transhumanist (talk) 18:36, 5 December 2007 (UTC)

  1. First
  2. Second
    • Second and a half
  3. Third
  4. Fourth
— Edokter • Talk • 18:39, 5 December 2007 (UTC)


Is there a way to do that without indenting? I don't want my entry to look like a reply to a specific numbered item. The Transhumanist (talk) 18:51, 5 December 2007 (UTC)

I'm afraid not. Nesting lists (of anykind) always results in some indenting. — Edokter • Talk • 19:15, 5 December 2007 (UTC)
I'm pretty sure I've seen a way to do it somewhere. I just can't find it. The Transhumanist (talk) 19:21, 5 December 2007 (UTC)
Here's one way:
  1. First
  2. Second
    Second and a half
  3. Third
  4. Fourth
Not exactly what you're wanting, but that's the only method other than what Edokter mentioned (to the best of my knowledge). EVula // talk // ☯ // 19:28, 5 December 2007 (UTC)

You can do it with HTML, but then you lose the benefits of using wiki markup. For example:

  1. first thing
  2. second thing

blah blah blah

  1. third thing
  2. fourth thing

--- RockMFR 19:28, 5 December 2007 (UTC)


Expanding on EVula's example:

  1. Number one
  2. Number two
    •Something else
  3. Number 3
  4. Number 4
— xaosflux Talk 05:09, 6 December 2007 (UTC)

...or even:

  1. One
  2. Two
  3. Two-and-a-half
  4. Three
  5. Four

—Ilmari Karonen (talk) 04:40, 8 December 2007 (UTC)

link for PDF in less than two clicks

Is it true that there is no civilized way to link to some internal PDF file so users can read the PDF in one click without having to first visit a logo file (short of having to hardwire fullurl:{upload server cached hash filename} etc.)? Jidanni (talk) 21:34, 6 December 2007 (UTC)

My browser has some problems with PDF files but I think Media:LGBTPressKit.pdf will work for others. PrimeHunter (talk) 21:53, 6 December 2007 (UTC)
Right. The "Media:" pseudo-namespace provides a direct link to the file rather than linking to an image description page. (Whether the file will display for you, is of course a browser issue) —Random832 17:13, 7 December 2007 (UTC)

#ifexist limit

This announcement was also posted to wikitech-l, archived here.

Werdna's #ifexist limit feature is now live. In response to complaints of template breakage, I have increased the limit on Wikimedia wikis temporarily, from 100 to 2000. Barring a coup, it will stay at 2000 for about a week, and then we'll lower it to 100.

Please use this one-week period to check pages and templates that use #ifexist heavily. Look in the HTML source of the preview or page view. There will be a "limit report" that looks like this: 

<!--
Pre-expand include size: 617515/2048000 bytes
Post-expand include size: 360530/2048000 bytes
Template argument size: 51168/2048000 bytes
#ifexist count: 1887/2000
-->

This is the limit report from commons:Template:Potd/2007-12, one of the pages that will break. Another example of a page that will break is this very page (WP:VPT), with a #ifexist count of 202.

At the end of the week, any pages which have a #ifexist count of over 100 will cease to be rendered correctly (after the next edit or cache clear). All #ifexist calls after the hundredth will be treated as if the target does not exist.

In some cases it may be possible to rewrite your templates so that they still do the same thing, but with less #ifexist calls. In other cases, you will need to remove template features. Removing features is always sad, as a sofware developer I know that, but sometimes it is necessary for the good of the project. This is one of those times.

-- Tim Starling 08:13, 1 December 2007 (UTC)

Could developers draft a list of pages (e.g., as a Special page) that, when run through by Parser.php, have #ifexist calls that exceed the 100 limit? One would be very useful at this point. GracenotesT § 08:39, 1 December 2007 (UTC)
Some of these are fairly well hidden. On this page, 100 ifexists come from {{Archive list}}. Where do the rest come from? Gimmetrow 08:48, 1 December 2007 (UTC)
I'll see what I can do. -- Tim Starling 09:17, 1 December 2007 (UTC)
One of the issues here is that current template/expression processing is fully recursive. This has the effect that on #if and #switch constructions the parser fully expands all branches, and not just the relevant forks. This is one of the effects that significantly increases the number of calls being made. Unfortunately, since the recursion is part of the parser, I don't see anyway to change that from within the ParserFunctions extension, such branching logic would have to be incorporated into the Parser itself. Dragons flight 09:32, 1 December 2007 (UTC)
The new preprocessor expands only followed branches of #if and #ifeq. #switch and #ifexist will hopefully follow at some stage. So when we finish working the bugs out of it and deploy it, the #ifexist counts will drop, in certain cases. This will hopefully be in the next day or two. -- Tim Starling 10:10, 1 December 2007 (UTC)
No fair reading my mind and getting out in front.  :-) Dragons flight 21:33, 1 December 2007 (UTC)
In some fraction of the cases, #ifexist is used solely to hide redlinks. In other words, constructions like {#ifexist:foo | foo | }. This limited functionality can be implemented with a CSS class, e.g.
.hidden-redlink A.new { display: none; }
Which would remove any redlinks appearing within a hidden-redlink class from being shown to the visitor. In other words, the functionally equivalent code would be <span class="hidden-redlink">foo</span>. Computationally this isn't a huge improvement over using ifexist, but there is caching for link processing and there isn't any caching for ifexist processing. So, I am proposing we add the above class to Mediawiki:Common.css. Of course, it doesn't help with the many more complex ifexist constructions that are also used. Dragons flight 22:00, 1 December 2007 (UTC)
PS. The same construction can also be used to hide missing images since a missing image is simply another redlink. Dragons flight 22:11, 1 December 2007 (UTC)
That is just HiddenStructure all over again. It won't hide links for everyone, particularly Google caches and it will break the transfer of wikimarkup into other wikis that don't have that CSS class enabled. The problems with HiddenStructure, along with the server resources used by templates like {{qif}}, were the exact reason why parser functions were created. Graham87 03:56, 2 December 2007 (UTC)
Is it enough to just hide the links? Or would you want to hide the separators as well? -- Tim Starling 07:09, 2 December 2007 (UTC)

A request was made at Template:Archive list to reduce the # of calls from 101 to 10 in light of this discussion. Should that wait until the week's over or should it be done now? SkierRMH (talk) 23:57, 1 December 2007 (UTC)

The point of the week is to make changes now, before the limit is fully implemented and breaks everything. Dragons flight 00:03, 2 December 2007 (UTC)

Suggestion: how about adding something to the site notice, so that when templates do break, there is a centralized reporting page for registered users and IPs alike? GracenotesT § 02:22, 2 December 2007 (UTC)

It should go in the watchlist notice, if anywhere. Readers don't need to know about these problems, editors do. --MZMcBride 02:37, 2 December 2007 (UTC)
Readers will know about the problem if they see an article messed up from too many #ifexist calls. And they will report the problem to many places: here, other village pumps, the help desk, Talk:Main Page, to the article's talk page, in the article itself, and a host of other decentralized places. If the site notice says "Due to a recent software change, articles may not be formatted correctly. Please report problems to Wikipedia:Insert relevant title", this bug becomes shallow, fast. I do not suspect that many pages in mainspace will be affected, though. GracenotesT § 02:55, 2 December 2007 (UTC)
On second thought, the above wording is somewhat vague. But something like this seems like a good idea – at least to me :) GracenotesT § 03:00, 2 December 2007 (UTC)
Actually, the Watchlist notice should possibly be written now to encourage people to reduce the use of #ifexist before things break. Dragons flight 03:05, 2 December 2007 (UTC)
Good idea – here's the notice page. GracenotesT § 03:16, 2 December 2007 (UTC)

A list of pages with a #ifexist count over 100 is here. Pages are added on parse, and there's no duplicate filtering, so it might get big in a day or two. Pages with a #ifexist count over 2000 are already broken. -- Tim Starling 05:07, 2 December 2007 (UTC)

OK, so I see one source of problems is {{archive box}} and {{archive box collapsible}}, which use {{archive list}} and {{archive list long}}. However, these are inside an if, and above it's claimed that soon if branches will not be expanded unless followed. So does this need to be fixed? If so, what's the best approach: fork the template into auto and non-auto, or disable the auto feature entirely, or something else? Gimmetrow 05:32, 2 December 2007 (UTC)
Another source is {{TemplatePAGENAME}}, which is used in the complex system of {{precision1}} and {{coord}}. These will break articles. Gimmetrow 06:11, 2 December 2007 (UTC)

I've disabled {{Backlognav}}. This is unfortunate, since it was a useful system, but it's loaded with #ifexist calls =[ GracenotesT § 05:38, 2 December 2007 (UTC)

Any news on the status of the preprocessor update mentioned above? I'm trying to beat down the number of #ifexist calls on WP:LOCE/R, and I don't think it's going to be possible without this update. Happy‑melon 15:00, 3 December 2007 (UTC)
Please wait lowering the limit of 2000 to 100 until some time after the preprocessor update is operational and more is known about it. That way adaptations can be made taking also the preprocessor update into account.--Patrick (talk) 11:20, 6 December 2007 (UTC)
Absolutely. Do not lower the limit until the new preprocessor is up and running. —Remember the dot (talk) 20:19, 6 December 2007 (UTC)

To be fixed

  • Template:Infobox Former Country
    Number of calls lowered from 194 to 92, and will be subject to further revisions. -- Domino theory 21:32, 2 December 2007 (UTC)
  • Template:Geobox Mountain Range - heavily uses Template:Geobox link
    I don't think Geobox Mountain Range and Geobox link are problems, are they? Gimmetrow 08:37, 2 December 2007 (UTC)
    Each transclusion appears to have 131 ifexists uses. --- RockMFR 08:50, 2 December 2007 (UTC)
    So the 131 in Sawatch Range come from this? OK. Gimmetrow 11:33, 2 December 2007 (UTC)
    Right, many of the problems here come from convenient "autolinking", something like {{#ifexist:{{{param}}}|[[{{{param}}}]]|{{{param}}}}}}. This can be fixed by making the parameter itself a link. GracenotesT § 18:40, 2 December 2007 (UTC)
    If I understand the new pre-processor correctly this (and 'Geobox river' below) should be self-correcting when it is installed. {{Geobox link}} has a #if: condition which only calls the #ifexist when parameter 1 is set non-blank. Right now both branches of #if: get evaluated and count towards the limits... with the new preprocessor only the displayed branch will get evaluated. So instead of always having exactly 131 #ifexist calls this should drop to the number of calls which actually have parameters set. Instead of always calling #ifexist for each of 'country1' through 'country9' it will only call it twice if the mountain range only has two country parameters set. I doubt any of the templates actually have anything close to all 131 parameters set and thus they will probably all fall under the 100 #ifexist limit. --CBD 13:56, 5 December 2007 (UTC)
    The typical number of uses typically seems to be about 130 in the ones I have specifically looked at in the generated HTML. By converting these to {{Geobox|Range}}, the number of ifexist calls drops to between 12-20. I have been working on converting these over in the past few days and hope to be done in the next day or two. RedWolf (talk) 22:48, 8 December 2007 (UTC)
  • Template:Archive list - lots of possibilities here - could use number of archives as parameter, could use display:none on redlinks, could split into multiple templates, etc
  • Template:Archive list long
    Once the change is implemented where only the relevant branches of #ifexist are followed, this template should only make as many #ifexist calls as there are archive pages. Tra (Talk) 13:18, 2 December 2007 (UTC)
  • the dependency of {{Archive box}} on *both* {{Archive list}} and {{Archive list long}} was causing a number of the Talk pages to be identified in Tim's list. As a quick fix I've limited it to use only {{Archive list long}} which has 36 #ifexists versus 100 in {{Archive list}}. This isn't a permanent solution of course, but that should cut out a lot of entries on Tim's page. -- Fullstop (talk) 01:19, 5 December 2007 (UTC)

G*d and Wikipedia:Articles for deletion/G*d

Am I the only one who gets a "bad title" error when trying to access that redirect or the AfD associated with it? Oddly enough, it works properly as a URL without any %2a or whatever escaping of the asterisk:

http://en.wikipedia.org/wiki/G*d

The AfD actually does exist and several other people have been able to comment on it, see WP:AFD/Y#G.2Ad. Thanks, cab (talk) 01:29, 7 December 2007 (UTC)

Those 4 links all work for me. -- Quiddity (talk) 06:51, 7 December 2007 (UTC)
Seems to be a browser-specific issue, I guess? It also works for me at home (under Firefox), but not from here at the office (using Internet Exploder). cab (talk) 08:37, 9 December 2007 (UTC)
Works OK for me with both IE-6 and Firefox 2.0.0.11. Haven't tried it with IE-7. -- Boracay Bill (talk) 09:29, 9 December 2007 (UTC)

CSD backlog nav templates broken?

Is there something wrong with these templates? They're all showing up as empty (except the replaceable fair use one, which is a separate template) when there are plenty of files in the actual backlog categories. I tried to add parameters to let you manually specify a backlog that's "fallen off the back of the list", but then I realized there's no reason the one I was looking at shouldn't have been showing up.—Random832 16:58, 7 December 2007 (UTC)

It's the #ifexist limit, I believe; the templates were modified to try to deal with it. (The count on CAT:CSD is still 102, 2 over the limit, so they haven't entirely succeeded.) --ais523 17:44, 7 December 2007 (UTC)
And the count was nearly 3000 a week ago. Quite an improvement, I think! I've contacted RockMFR (talk · contribs), who rewrote {{backlognav}} to the current efficient version, to see if any further improvements can be made. GracenotesT § 18:12, 7 December 2007 (UTC)

Looking at now... --- RockMFR 18:29, 7 December 2007 (UTC)

There is no problem right now. The ones with no backlogs really do have no backlog. Only things older than 7 days (or 5 days for prod, or 0 days for replaceable) are considered to be backlogged. The limit hasn't been dropped to 100 yet, so everything's good right now. --- RockMFR 18:32, 7 December 2007 (UTC)
I thought that everything was supposed to show up. Incidentally, why don't all items show up in CAT:CSD? I think breaking them up into days is sometimes less than helpful, are there "all" subcategories? Is there any objection to me creating such subcategories? —Random832 18:37, 7 December 2007 (UTC)
Things are not considered deletion candidates until a certain number of days have passed. There is no reason to start going through the categories until a week (or 5 days for prod) has passed. Also, for now, I've dropped two ifexists from the prod template so CAT:CSD will be within the limits. --- RockMFR 18:42, 7 December 2007 (UTC)
Doesn't this still mean that any article containing one {prod} and one other #ifexist will fail to render properly? {prod} and the other deletion tags need to use close to 0 #ifexists. (Honestly, why can't it just say "this article has been proposed for deletion"?). Splash - tk 20:33, 8 December 2007 (UTC)
We're talking about the various templates used only on CAT:CSD, not the templates used to tag articles. --- RockMFR 23:19, 8 December 2007 (UTC)

You do not have permission to do that

I wanted to see a previous version of one of the sections included by template in the Main Page , so I selected view source to see what the template was called. The page I got back began with with words:

You do not have permission to do that, for the following reasons:

This was followed by about 20 lines of stuff about the page being protected from editing, after which it said:

You can view and copy the source of this page:

and there was the source I wanted. Obviously, the software was assuming I was trying to edit the page -- but the link I selected is called view source, and it's kind of rude of the software to tell me I don't have permission to do something I wasn't trying to do.

The explanation, of course, is that the view source link goes to http://en.wikipedia.org/w/index.php?title=Main_Page&action=edit (note the emphasis). Why not also support an action=view, which would present the source without the irrelevant words about edit protection, and make the view source link go to that?

(Of course, if an action=edit URL is used despite this change, the behavior should be the same as now; as well as a deliberate attempt to edit a protected page, this might also happen if someone used an edit this page link from a copy of a page cached before it was protected.)

--207.176.159.90 (talk) 02:59, 8 December 2007 (UTC)

There already is an action=view, it's the one used implicitly when no other action is specified. Maybe action=viewsource? -- Tim Starling (talk) 03:51, 8 December 2007 (UTC)
If the wording is a problem, why not change that? In MediaWiki:Permissionserrorstext, "do that" can be made "edit". So long as that system message isn't being used for something else, that is. action=raw (and the API) works for viewing just a page's source, although it doesn't come with the pretty GUI. GracenotesT § 04:12, 8 December 2007 (UTC)
It probably is; I think (but am too lazy to verify right now) that the same message is used if, for example, a non-administrator attempts to delete a page (by going to an URL with action=delete). Tim's suggestion of an action=viewsource sounds practical to me. —Ilmari Karonen (talk) 04:26, 8 December 2007 (UTC)
That yields the message "The action you have requested is limited to users in the group Administrators." Trying to delete a MediaWiki page, however, does seem to produce that error message :[ Now, action=viewsource is a good idea, but if a page is protected while you still have a tab to edit it, you'll still have to deal with producing the correct system message somehow. GracenotesT § 05:02, 8 December 2007 (UTC)
Answering both of Grace's items at once: it's not the wording that's the problem, it's the assumption that I meant to edit when the link I followed was not an edit link. And if I actually did follow an edit link somehow, there's nothing wrong with the present behavior. --207.176.159.90 (talk) 05:24, 8 December 2007 (UTC)
Oh, I see. Thank you for the explanation. Given that, this seems like a good idea, so long as there's not too much duplicate MediaWiki code that results from it. GracenotesT § 05:35, 8 December 2007 (UTC)
Well, if the assumption is the problem, maybe MediaWiki:Viewsource should be changed to something like "Attempt to edit" or "edit (protected)". After all, the protection level of a page might change between a person loading the page (or cached version of the page) and clicking the action=edit link, so it seems best to keep the link the same (as is done) and simply use less ambiguous alternate text. --Splarka (rant) 08:24, 8 December 2007 (UTC)
I think the assumption might be a problem there as well – that would result in pages which are not supposed to be mass-edited, e.g. the Main Page, having a tab that says "attempt to edit". Someone not familiar with MediaWiki might find this a problem, and either way, more people will click on the link, get a "You can't do that" message, and be confused. GracenotesT § 22:54, 8 December 2007 (UTC)

Hmm... I just took a look into adding action=viewsource. The relevant code is mostly in OutputPage::readOnlyPage(), but that function seems to have grown rather gnarly over the years and really ought to be refactored — I suspect Brion wouldn't like me simply tacking one more special case onto the existing mess. Other than that, the fix does seem fairly straightforward. —Ilmari Karonen (talk) 22:36, 8 December 2007 (UTC)

Just committed the first step towards this as rev:28287. This was just cleanup, the refactoring comes next. —Ilmari Karonen (talk) 00:20, 9 December 2007 (UTC)

Important: "x people have donated" counter broaken?!

Hi, there's already not the first time, when I notice difference between numbers that are shown in "tiny" view of the counter(with green-white bar) and its "full version"(with white-green persons' pictures). Currently the numbers are 38,102 and 35,078 respectively. I find the same issue on pages of sub-projects in at least 3 different languages: English,Russian & Hebrew. This is consistent across both different computers, different OS's (at least,WinXP Home & Professional) and different browsers (at least, IE6 & IE7 & Firefox 2.*). IMHO, this inconsistency may harm brutally in the trust people give currently to Wikipedia. It creates an illusion, that organization doesn't really success to manage itself (concerning donations accepting management) and doesn't really value the contribution of its grassroots. Personally, I don't believe, that's the reason of an issue, but I've been asked too much times in recent days why that's happening. Please fix it. Stypex (talk) 15:51, 9 December 2007 (UTC)

The lower total excludes donations < $1, which feels more honest since there have been a number of people throwing pennies at us. I'd encourage a dev to set both totals equal to this, if they get a chance. Dragons flight (talk) 05:38, 10 December 2007 (UTC)
10x for explanation. It really should be the same. And I agree with you, it should show lower counter on both. If it helps, plz explain me how to connect directly with devs and I'll ask for it too. Maybe greater demand will make them do the job quicklier(I mean before current fundraising ends):) --Stypex (talk) 08:16, 11 December 2007 (UTC)

Format help

Does anyone know how to format the 2 templates used in Charles Wesley so that the "methodism" template sits neatly below the bio template because it encroaches left into the text? Not very nice. Thanks ww2censor (talk) 01:32, 10 December 2007 (UTC)

Note: I see this with both Firefox and IE6 if the displayed text-size is made small enough so that the two templates overlap vertically. -- Boracay Bill (talk) 03:16, 10 December 2007 (UTC)
I checked out both Firefox and Safari on Mac and only if I enlarge the text several times, on a 1280 x 854 resolution laptop setting, the text eventually becomes large enough to push the 2nd template below the first. Hopefully someone knows a trick that would format the templates one below the other without having to alter text size. Thanks ww2censor (talk) 03:49, 10 December 2007 (UTC)
I did a few tweaks - basically the trick is to wrap both boxes into a table, so that they can be aligned as a group. How does this edit look? Dl2000 (talk) 04:00, 10 December 2007 (UTC)
That looks great. I have seen this issue on several other page before and thought there must be a fix. However, I am not sure the Template:Methodism editors will be happy but I have no problem with it. Thanks ww2censor (talk) 04:45, 10 December 2007 (UTC)
As a {{Methodism}} editor (albeit the most recent one), I can live with that :-) Haven't heard any negative feedback yet; hopefully that change is widely considered an improvement. Also there are other techniques in WP:BUNCH that could be considered in future cases where infoboxen go astray. Dl2000 (talk) 02:56, 12 December 2007 (UTC)

Section [edit] links overlapping main article text

Hi - Does anyone have an idea of why in this is happening and how to fix it? On the page for Splash Mountain - some of the [edit] links that are usually above each section are not in their correct location and are grouped together near the middle of the page, overlapping some of the main article text.

I think it has something to do with the many infoboxes, but I was not able to find the answer by looking through the help pages.

Thank you! --Linda (talk) 05:43, 11 December 2007 (UTC)

PS. - I'm using Firefox. --Linda (talk) 05:45, 11 December 2007 (UTC)

This is a common problem in articles: see Wikipedia:How to fix bunched-up edit links. I'll see if I can fix it on Splash Mountain. GracenotesT § 05:58, 11 December 2007 (UTC)
Cool, it looks great! I read the help article you linked and looked at how you fixed it, so I understand what to do if this happens again later. Thank you so much! --Linda (talk) 06:48, 11 December 2007 (UTC)

+/- counter on my watch list

Hi, could anyone plz explain, what's the meaning of counter
that is assigned to every entry on my watch list.
There're entries with both extremely high and low counters there.
Is it counter related to me/my activity or smth other?
10x
--Stypex (talk) 08:25, 11 December 2007 (UTC)

Sorry for bothering you all. Already found the answer in FAQ at the top.
Can I explicitly delete this post or it's saved in logs forever? --Stypex (talk) 08:33, 11 December 2007 (UTC)
Anything you edit on Wikipedia is saved in the history, unless it is deleted or oversighted (in which case, it's just hidden from users with various access levels, or lack of them). It's alright to keep this, a bot will archive it when tihe time comes. x42bn6 Talk Mess 17:57, 11 December 2007 (UTC)

Date autoformatting/linking

There is currently another rip-roaring discussion about the date preferences autoformatting over at MOS:DATE's talk page. Mostly, there is a perception that the current system results in overlinking since a date must be wikilinked in order to be autoformatted according to user preferences. Proposed date autoformatting changes received no traction when raised at Bugzilla. A date autoformatting method seems essential to support WP:CSB and to discourage edit/policy battles over whose date format to use. How can we encourage progress towards MediaWiki enhancements to support non-linked autoformatted dates, plus the ability to properly format date ranges, and resolution of any other date formatting complaints? Dl2000 (talk) 03:38, 12 December 2007 (UTC)

Inconsistent limitations?

Why is there an upcoming limit of 100 #ifexist calls, while (fortunately) more than 100 template calls can be used in a page? Just checking existence can hardly be more work than transcluding a page. Is this related to caching?--Patrick (talk) 01:12, 9 December 2007 (UTC)

See above: #Abuse of #ifexist parser function, ##ifexist limit. There is an upward limit on transclusion: see Wikipedia:Template limits. GracenotesT § 01:38, 9 December 2007 (UTC)
I have seen that, but it does not answer my question. In the case of large pages the pre-expand include size limit is similarly strict, but for small pages it is odd that just checking existence is more restricted than transclusion. Is it just because such limitations are inevitably somewhat crude and arbitrary? Or is checking existence perceived as less useful than transclusion? Or is there a technical reason?--Patrick (talk) 02:15, 9 December 2007 (UTC)
The reason for the limit is that the present code for ifexists makes a separate database query for each call. It would be possible, although technically somewhat complex, to make it more efficient. But unless someone writes the code, or convinces the developers it's a higher priority than the many other things that need to be done, it's going to be a while. In the meantime, the limit is a straightforward way to address the resource limitations.
So to answer the question, I think it's a combination of an arbitrary limitation (100 vs 200 vs 1000) and the perception that it shouldn't be necessary to have more than 100. There is ongoing work that will allow some things that currently use more than 100 to fit within the limit, for example the archive box. — Carl (CBM · talk) 02:24, 9 December 2007 (UTC)
How does this compare with calling a template? Doesn't that also require a separate database query?--Patrick (talk) 09:41, 9 December 2007 (UTC)
Unique templates are always more expensive than #ifexist. The reason there's no limit on unique template transclusions is because we haven't gotten around to it yet. I had considered putting a limit on both simultaneously because of the risk that people would substitute #ifexist for an equivalently functioning transclusion, which would of course be a change for the worse. It's about usage patterns -- we were seeing some usage patterns for #ifexist that were making certain pages extremely slow, and slowing down the site as a whole. We didn't anticipate this usage pattern when we approved the feature. -- Tim Starling (talk) 14:28, 9 December 2007 (UTC)
I see, thanks.--Patrick (talk) 09:07, 12 December 2007 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)/Archive_9&oldid=1138369126"