Wikipedia talk:Twinkle/Bugs/Archive 5

Archive 1

←

Archive 3

Archive 4

Archive 5

TW-B-401

Status:  Resolved

Resolution:  Fixed

When requesting page protection nothing appears to happen. The page appears to be frozen. -- Lil_℧niquℇ №1 | talk2me 20:30, 13 September 2010 (UTC)

Ive also been experiencing this. Started last week. - (CK)Lakeshade - talk2me - 22:28, 13 September 2010 (UTC)

Issues occuring with AfD, RFPP etc. -- Lil_℧niquℇ №1 | talk2me 22:55, 14 September 2010 (UTC)

Nothing wrong with AfD, as far as I can tell. RFPP-problem was fixed yesterday. Amalthea 14:51, 15 September 2010 (UTC)

TW-B-402

Status:  Resolved

Resolution:  Fixed

If I try to report a user or IP-address to WP:AIV and leaving everything at default (all checkboxes disabled, all white text boxes blanked, except for the optional comment box), I get a space and "dot" after the dash — see 1 and 2. But if I specify something, like activating the checkbox saying that the user vandalized after final warning, the dot does not appear — see 3. /HeyMid (contributions) 20:31, 15 September 2010 (UTC)

Fixed this particular instance, but full stop handling in Twinkle is generally pretty wonky. Amalthea 13:53, 26 September 2010 (UTC)

TW-B-403

Status:  Closed

Resolution: Server issue

Nothing's working at all. All processes lock up on the first step: unlink, tagging files/articles for deletion, etc. Ten Pound Hammer, his otters and a clue-bat • ^{(Otters want attention)} 22:02, 16 September 2010 (UTC)

Yep, same problem. Reverting just locks up; When tagging for Speedy Deletion I get "Checking if page exists: It seems that the page doesn't exists, perhaps it has already been deleted" after a long period of no action even though the page is still there. --Fiftytwo thirty (talk) 23:04, 16 September 2010 (UTC)

For what its worth, UAA reports are working. --Fiftytwo thirty (talk) 23:36, 16 September 2010 (UTC)

CSD and AIV are working for me.— Train2104 (talk • contribs • count) 01:12, 17 September 2010 (UTC)

Yeah, Everything's back to normal now -- At WP:AN#Twinkle Issue 7 said that the issue was related to a javascript problem with Wiki servers and not Twinkle. --Fiftytwo thirty (talk) 02:50, 17 September 2010 (UTC)

TW-B-404

Status:  Resolved

Resolution:  Fixed

Endorsing an already WP:PRODded article no longer works after the changes made to the PROD-tagging on TW; see [1], where I attempted to use the PROD feature on TW to endorse a prod (i.e. adding {{prod-2}} below the current {{dated prod}} template); it just added another PROD template on top instead of detecting that a PROD template was already there and asking me if I wish to add a {{prod-2}} instead. –MuZemike 17:08, 19 September 2010 (UTC)

Thanks, works again. {{dated prod}} was renamed to {{proposed deletion/dated}}, to keep me busy. Amalthea 14:26, 22 September 2010 (UTC)

TW-B-406

Status:  Closed

Resolution:  Invalid

When I used Twinkle to nominate a redirect for deletion, it placed the page on WP:MfD instead of WP:RfD. --- cymru lass ^{(hit me up)}⁄_{(background check)} 05:23, 28 September 2010 (UTC)

It will file it as whatever you select in that dropdown. It should default to RfD, and does so for me on Benedikt XVI., and I note that others still can file RfDs via Twinkle, so I'd assume you accidentally changed the selection in the dropdown (maybe just by pointing at it and using the mousewheel, depending on your OS/Browser).
From all I can say, there's no Twinkle bug here. Amalthea 08:27, 28 September 2010 (UTC)

All right. Thank you! I was pretty sure I selected RfD, but I guess I was wrong! Thanks --- cymru lass ^{(hit me up)}⁄_{(background check)} 22:17, 28 September 2010 (UTC)

TW-B-407

Status:  Closed

Resolution: Not Twinkle's fault

I think I've tracked a problem I've been having for a year or two down to Twinkle. Pages with a large number of links, such as List of chess books, A-L take 35-45 seconds to load. A diff or pulling up the page to edit can take longer. In the HTML source for the page, the slow ones were missing "saved in parser cache". I found that if I have Twinkle off, these pages are OK; if Twinkle is checked, they are terribly slow. Can this be fixed? Bubba73 ^{You talkin' to me?} 16:49, 29 September 2010 (UTC)

See old VP discussion: WP:Village pump (technical)/Archive 54#Some pages extremely slow if logged in, fast if not. Bubba73 ^{You talkin' to me?} 17:05, 29 September 2010 (UTC)

Exactly. Why do you think it's Twinkle? My guess would be that it only depends on whether you get a cached version or whether it's being rendered for you. The page you mention has a huge amount of citation templates, which make MediaWiki quite slow. I.e., if I purge that page, it takes the server 54 seconds to render and deliver the page (as can be seen from the very end of the page source, like you said). Refreshing the page afterwards is quick since it can be served from the cache, even with Twinkle enabled.
Page display can be slow if you have non-standard preferences that affect the content of the rendered page (like style of red links, numbered headers, …) since many pages will have to be rendered just for you. Gadgets don't affect the served page content though.
Amalthea 17:15, 29 September 2010 (UTC)

I was doing quite a bit of experimenting, and usually (but not always) if Twinkle was on, it was slow, and vice-versa. I reset preferences to the default and the problem cleared up. I started adding them back and the problem seemed to start again when I added Twinkle, stopped when I removed it, etc. But not always. People said that the problem was probably something on the Gadgets page.

I have links always underlined and a few things like that. Bubba73 ^{You talkin' to me?} 19:05, 29 September 2010 (UTC)

So does WP cache a version of each page for each combination of preference settings? That is, if someone with the same set of preferences has requested a page since it was last changed, I will get the cached page; but otherwise it will have to format the page, which can take a long time? Is that what is happening? Bubba73 ^{You talkin' to me?} 05:46, 30 September 2010 (UTC)

For each combination of certain preference settings. "Always underline links" for example is handled through CSS, so it shouldn't affect the parser cache. Gadgets also only change the page head, which is (for logged-in users) generated each request anyway, so it doesn't affect pure page load time either.
I can guarantee that ticking the Twinkle box is not at fault for causing extremely long load time on template-heavy pages. Twinkle may slow down page load if, for example, the server is overloaded and can't hand out all the script pages in a timely fashion, but that would show the same delay on all kinds of articles. Twinkle doesn't look at the rendered page content, and certainly not during page load, so there shouldn't be any effect on long pages there either.
Altogether, I'm certain there's no Twinkle bug here.
You mention that you "start adding" your preferences back. What preference changes are you making, exactly? Amalthea 09:28, 30 September 2010 (UTC)

OK, the ones I've changed (at present) are always underline links, format broken links, show TOC, and in gadgets: add a "*" to purge cache, display assessment, and add [edit] link for the lead. Sometimes I still have the slowness problem, but not as bad as before. Bubba73 ^{You talkin' to me?} 15:43, 30 September 2010 (UTC)

TW-B-410

Status:  Resolved

Resolution:  Fixed

Requests for page protection using the RPP link appear above section header templates on Wikipedia:Requests for page protection. See, for example, [2]. me_and 15:09, 12 October 2010 (UTC)

There was a space in that marker that was not anticipated by the regex.
Marker repaired, regex yet again made more robust. Amalthea 16:45, 12 October 2010 (UTC)

Thank you The prompt response is very much appreciated!

TW-B-411

Status:  Resolved

Resolution:  Fixed

(from Wikipedia_talk:Twinkle#ReptoAdmins:_Sockpuppet_option): I think that the current form of the "sockpuppet report" option on Twinkle is rather unintuitive and needs improvements. First off, the sockpuppet investigations page advises against notifying suspected socks of their investigation, in the event they learn from their mistakes and come up with better ideas of dodging scrutiny. I think an additional checkbox option to opt out of notifying the socks would be in order. Secondly, I prefer to report a sock on the immediate instant that I see him/her instead of having to track down the sockpuppeteer to report him/her. If there can be an option to report the sock and list the sockmaster, instead of doing it the other way around, that'd be great. :| TelCoNaSpVe :| 11:19, 18 October 2010 (UTC)

First half is fixed. T. Canens (talk) 03:02, 19 October 2010 (UTC)

Second half is fixed as well. But I admit it is rather inelegant... T. Canens (talk) 03:18, 19 October 2010 (UTC)

TW-B-413

Status:  Resolved

Resolution:  Fixed

Minor typo in 'Report IP (Report IP to Administators)' for ARV tooltip
Steps to reproduce

1. Navigate to an IP's talk page
2. Open the drop down Twinkle list
3. Hover mouse over ARV option until tooltip appears

Expected outcome

Text should read 'Report IP (Report IP to Administrators)'

Actual outcome

Text reads as 'Report IP (Report IP to Administators)'
Note: This is only observed for anonymous/IP users --Topperfalkon (talk) 16:17, 3 November 2010 (UTC)

Fixed [3]. Magog the Ogre (talk) 01:50, 11 November 2010 (UTC)

TW-B-417

Status:  Closed

Resolution:  Invalid

I was fiddling around with the unlink function in my sandbox and when I hit the submit button it cleared the window like it usually does with TW functions, but instead of putting up message like "Unlinking backlinks: completed" or anything like that, it just simply stalls(I closed the window after 30 seconds and tried it again and it didn't work). My web browser is Safari on Mac OS X 10.6.4. Usb10 ^Connected? 01:41, 11 November 2010 (UTC)

D'oh! Of course it didn't work; there aren't any links to my sandbox, so how could it have unlinked them! Self-closing as invalid. Usb10 ^Connected? 22:49, 18 November 2010 (UTC)

TW-B-419

Status:  Resolved

Resolution:  Fixed

At this edit, Twinkle placed a request for protection above the header for that section on the page. Fortunately I was right there to fix it, but still, I figured it's something that may be worth looking into. elektrikSHOOS 02:51, 15 November 2010 (UTC)

Works for me with that revision. What browser and OS are you using? Amalthea 21:39, 18 December 2010 (UTC)

I use Chrome right now, though if I recall at the time I was using Safari. Both are under OS X Snow Leopard. elektrikSHOOS 02:18, 26 December 2010 (UTC)

It happens for me as well with Safari 5.0.3 under Snow Leopard. -- Eraserhead1 <talk> 23:11, 27 December 2010 (UTC)

If there is a source control for Twinkle somewhere I may well be able to fix this myself. -- Eraserhead1 <talk> 10:17, 28 December 2010 (UTC)

This happens to me as well. Usb10 ^Connected? 02:03, 30 December 2010 (UTC)

I've made a fix with this diff. I haven't managed to test it with Firefox as Firebug isn't behaving itself today, but this code works in Safari, and should be much simpler and work in other browsers too. -- Eraserhead1 <talk> 12:31, 29 January 2011 (UTC)

Y Applied, thanks! FWIW, the regex was rather complex since the RFPP page sported a hidden comment at the section top that needed to stay there along with the template.
Cheers, Amalthea 22:28, 8 February 2011 (UTC)

TW-B-421

Status:  Resolved

Resolution:  Dupe of #361

When tagging an article, the tags are not being properly combined. See, for example, this edit, where I'd have expected the {{orphan}} tag to be rolled into the {{multiple issues}} template. —me_and 17:50, 22 November 2010 (UTC)

TW-B-422

Status:  Resolved

Resolution:  Resolved

When I try to report a username, it feeds this error, "Processing UAA request: Failed to retrieve edit form." I looked at the archive, and someone said it was a problem with the HTML code, and that they reported it to the developers. I wasn't sure what I should do now though, as that was in 2009, so I reported it here. Endofskull (talk) 18:20, 18 December 2010 (UTC)

Y Fixed the editnotice at fault. MediaWiki is still having that problem, I'm afraid, so editnotices need to be valid XHTML. Amalthea 21:27, 18 December 2010 (UTC)

TW-B-423

Status:  Resolved

Resolution:  Fixed

When using Twinkle to nominate files for speedy deletion when they are on Commons with the same or different name, the files are not being sorted into dated deletion categories, but instead are assigned to categories with unknown date. Kelly ^hi! 23:48, 25 December 2010 (UTC)

Y Fixed. — This, that, and the other (talk) 21:40, 21 February 2011 (UTC)

TW-B-424

Status:  Resolved

Resolution:  Fixed

Using Twinkle to create an AfD for a previously AfDed article resulted in the wrong link being added to the notification. The article in question is Bands Against Bush, and Twinkle correctly created Wikipedia:Articles for deletion/Bands Against Bush (2nd nomination), but as seen here the notification linked to the long-closed original AfD nomination. Note that the page creator has been identified correctly; the article is old enough to predate the restriction on IP editors creating mainspace pages. — Gavia immer (talk) 22:32, 26 December 2010 (UTC)

Another example: a correctly created nomination followed by an incorrect notification. Any chance of at least having the bug acknowledged? — Gavia immer (talk) 12:42, 3 February 2011 (UTC)

I'll look into this. — This, that, and the other (talk) 23:11, 19 February 2011 (UTC)

Thanks. — Gavia immer (talk) 23:18, 19 February 2011 (UTC)

There appears to be a simple typo on line 820 of User:AzaToth/twinklexfd.js: this.params.numbering is used instead of self.params.numbering. This should be fixed soon. — This, that, and the other (talk) 10:39, 21 February 2011 (UTC)

Thanks for the analysis, should be fixed. (WP:BYPASS!). Cheers, Amalthea 11:51, 21 February 2011 (UTC)

TW-B-425

Status:  Resolved

Resolution:  Dupe of #419

Twinkle doesn't put new RFPP requests in the right place

At least with Safari 5.0.3, Twinkle doesn't put new RFPP requests in the right place and puts them before the page notice. This is annoying. -- Eraserhead1 <talk> 20:04, 27 December 2010 (UTC)

Apologies, this is a duplicate. -- Eraserhead1 <talk> 23:12, 27 December 2010 (UTC)

TW-B-427

Status:  Resolved

Resolution:  Fixed

If a Twinkle message you type into the box ends with a full stop (or other punctuation) then Twinkle shouldn't auto-append one itself. As with the bug I filed above if I can have access to the source I may be able to fix this myself. -- Eraserhead1 <talk> 23:24, 3 January 2011 (UTC)

this is a patch for this issue. -- Eraserhead1 <talk> 18:42, 9 February 2011 (UTC)

Whoops, missed it. Applied now, thanks! Amalthea 12:31, 21 February 2011 (UTC)

TW-B-428

Status:  Resolved

Resolution: Dupe of #36

When an AFD reason contains a blacklisted link, Twinkle says that the discussion page is created, but it really is not. This happened to me when I linked to Lulu.com in a deletion reason due to a book not being notable. Logan _Talk ^{Contributions} 01:04, 17 January 2011 (UTC)

TW-B-429

Status:  Resolved

Resolution:  Fixed

uw-logoutblock was deleted, see Wikipedia:Templates_for_discussion/Log/2010_October_6#Template:Uw-logoutblock, yet remains in the drop down causing an unexpanded subst template to be placed.--Doug.^{(talk • contribs)} 23:02, 17 January 2011 (UTC)

Y Done, thanks Doug. Amalthea 23:37, 17 January 2011 (UTC)

TW-B-431

Status:  Resolved

Resolution: none

Is Twinkle supposed to automatically mark new pages as patrolled when applying a CSD or PROD tag. and if it is, why does it sometimes not work? The reason for the question is that DashBot looks for pages with CSD & PROD that have not been manually marked as 'patrolled' and marks them automatically; this can have awkward consequences if the creator then removes the CSD or PROD out of process and it goes unnoticed. --Kudpung (talk) 09:11, 21 January 2011 (UTC)

Already does if you come from the NPP log, the API function to find the proper parameters has been removed a while back due to performance concerns. Amalthea 09:59, 25 January 2011 (UTC)

TW-B-432

Status:  Resolved

Resolution:  Fixed

{{db-policy-notice}}, as used when notifying for CSD T2 (admittedly, a rare criterion that I think should be abolished due to its infrequency of use), doesn't actually exist. See this diff for an instance of its erroneous use by Twinkle. — This, that, and the other (talk) 08:52, 25 January 2011 (UTC)

I've created it, thanks. Amalthea 09:59, 25 January 2011 (UTC)

TW-B-433

Status:  Resolved

Resolution:  Fixed

{{db-foreign}} or {{db-a2}} does not prompt for a source link, causing an error when tagging a page using Twinkle. Logan _Talk ^{Contributions} 22:24, 26 January 2011 (UTC)

Y Fixed. — This, that, and the other (talk) 21:39, 21 February 2011 (UTC)

TW-B-434

Status:  Resolved

Resolution:  Resolved

This was probably already reported, but I can't find it. When adding {{puf}}, TW used the log parameter instead of the date parameter. As explained here the text shown by {{puf}} when using the log parameter, directs you to add an incorrect line to {{pufc}}. --Muhandes (talk) 01:25, 28 January 2011 (UTC)

Sigh, I should have reverted the introduction of that date parameter when I saw it, it's nothing but problems.
Anyway, this shouldn't typically be an issue with Twinkle since Twinkle does notify the creator anyway. I fixed the template though so that it now properly offers the template code for the notification even if the log parameter is used. Thanks for the report, Amalthea 01:03, 20 February 2011 (UTC)

Thanks. --Muhandes (talk) 06:41, 20 February 2011 (UTC)

TW-B-435

Status:  Resolved

Resolution:  Fixed

When tagging a redirect, the page that results from the tagging should be the redirect in the index.php?redirect=no style rather than the page that the redirect redirects to so that the user can make sure that the tagging was performed properly. Logan _Talk ^{Contributions} 18:48, 29 January 2011 (UTC)

This can be fixed by modifying User:Ioeth/friendlytag.js: replacing the line (very close to the end)

Wikipedia.actionCompleted.redirect = wgPageName;

with the code

if (isRedirect) Wikipedia.actionCompleted.redirect = wgServer + wgScript + "?title=" + encodeURIComponent(wgPageName).replace(/\%2F/g, '/') + "&redirect=no";
else Wikipedia.actionCompleted.redirect = wgPageName;

I will make an editprotected request. — This, that, and the other (talk) 04:32, 19 February 2011 (UTC)

Y Done, thanks (I used a slightly different logic though, this can probably be useful in other morebits scripts). Cheers, Amalthea 00:48, 20 February 2011 (UTC)

TW-B-438

Status:  Resolved

Resolution:  Fixed

In a similar way to bug 427. Double punctuation still occurs with the normal reversion code. -- Eraserhead1 <talk> 20:03, 21 February 2011 (UTC)

And here's the patch. -- Eraserhead1 <talk> 20:05, 21 February 2011 (UTC)

Thanks, applied (with minor modifications). Cheers, Amalthea 19:08, 22 February 2011 (UTC)