Commons:Village pump/Technical

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
Community portal
introduction
Help deskVillage pump
copyrightproposalstechnical
Administrators' noticeboard
vandalismuser problemsblocks and protections

Shortcut: COM:VP/T · COM:VPT

Welcome to the Village pump technical section

This page is used for technical questions relating to the tools, gadgets, or other technical issues about Commons; it is distinguished from the main Village pump, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with {{section resolved|1=~~~~}} may be archived; for old discussions, see the archives.

COMMONS DISCUSSION PAGES (index)


Please note
 

ogg bug[edit]

Please look at File:En-uk-Crawley.ogg. When I click on the page itself, it's only 0.2s long and plays nothing but noise, but when I open the source file, it is complete.--Roy17 (talk) 19:08, 11 January 2019 (UTC)

No issues with any Mediaplayer on my box, ~1.5s, not 0.2 as indicated here, and certainly no 284 kbps or similar. Maybe report it on phab:, nobody knows how many vintage 2002 OGG files might be affected.:-(84.46.53.198 09:58, 6 February 2019 (UTC)
Format                                   : Ogg
File size                                : 7.15 KiB
Duration                                 : 1 s 486 ms
Overall bit rate mode                    : Variable
Overall bit rate                         : 39.4 kb/s

Audio
ID                                       : 30844 (0x787C)
Format                                   : Vorbis
Duration                                 : 1 s 486 ms
Bit rate mode                            : Variable
Bit rate                                 : 24.0 kb/s
Channel(s)                               : 1 channel
Sampling rate                            : 22.05 kHz
Compression mode                         : Lossy
Stream size                              : 4.35 KiB (61%)
Writing library                          : libVorbis 1.0 (UTC 2002-07-17)

Wrong section in Special:SpecialPages[edit]

Hello.How useful "Wikibase" section in Special:SpecialPages?Should not it just appear in Wikidata?Thank you --ديفيد عادل وهبة خليل 2 (talk) 09:56, 22 January 2019 (UTC)

The section is not “wrong” because these special pages exist locally. Another problem is that some of the things don’t work as expected but again, if this wiki technically has these Special: titles, then they must be included into SpecialPages. @ديفيد عادل وهبة خليل 2: please, avoid usage of the adjective “wrong” when cite your personal taste and preferences. Incnis Mrsi (talk) 12:41, 22 January 2019 (UTC)
@Incnis Mrsi: There is no taste or preferences but this is a belief and a surprise. Thank you for reply --ديفيد عادل وهبة خليل 2 (talk) 12:46, 22 January 2019 (UTC)
Hmm, some of them are actually functional, like Special:SetLabel, which sets the captions. I wonder what Special:MergeItems would do. Nothing good, probably. --ghouston (talk) 10:59, 26 January 2019 (UTC)

Image update didn't take[edit]

I was trying to update File:EF DI2 (FR12).jpg, but for some reason, it still shows the old version. You can see the new version if you go to the file page, but clicking the image or putting it on a page displays the old version and file history shows looks like I uploaded the old version as well, as does the link to it on Wikipedia (2nd row of the table). For reference, here is the source for the new version: https://www.spc.noaa.gov/efscale/2.html. Is there a way to fix this so that the new version of the image is displayed properly? TornadoLGS (talk) 03:23, 23 January 2019 (UTC)

@TornadoLGS: en:Wikipedia:Purge. Incnis Mrsi (talk) 03:36, 23 January 2019 (UTC)
@TornadoLGS, Incnis Mrsi: For future reference, please see COM:FAQ#PURGE.   — Jeff G. please ping or talk to me 23:42, 23 January 2019 (UTC)
Thanks. I tried purging the page, but that did nothing. But It displayed correctly after I cleared the cache in my browser. TornadoLGS (talk) 01:44, 24 January 2019 (UTC)
A user should eliminate his client problems before declaring that “it still shows the old version”. I won’t even look at this substandard JPEG stuff. Incnis Mrsi (talk) 13:12, 24 January 2019 (UTC)

PAGESINCAT malfunction?[edit]

Compare {{PAGESINCAT:Flickr review needed|R|files}}=43, and the number shown on Category:License review needed, with the actual number of files in Category:Flickr review needed. The count is off by 42, i.e. when there are zero files in the category, the count is 42 somehow. I first noticed this yesterday (Jan 24).--Roy17 (talk) 07:49, 25 January 2019 (UTC)

The usual tricks (null edit and ?action=purge) don't help, maybe report it on phab:. Presumably some "perennial" issue (older than 2011), but a bug is a bug no matter how old it is. –84.46.53.198 09:33, 6 February 2019 (UTC)

How to propose a change to the MediaWiki software?[edit]

Because of Commons:Village pump/Technical#file contains HTML or script code, we need support for IE6 and IE7 to be dropped. (or disable logins on those browsers) As long as those old turds are listed on mw:Compatibility#Browser support matrix, developers will refuse to remove stupid workarounds for Internet Exploder. Saying "Internet Exploder" is not childish in this case, these old IE versions exploded our ability to upload perfectly fine photos like those from https://www.flickr.com/photos/tinto/.

How can such a change be proposed? I can't seem to find a proposals page or anything like that on MediaWiki. On mw:Communication there is this cryptic message "Wikimedia's Meta-Wiki was formerly where documents were managed and proposals were discussed before this site was started. There is still a lot of content there that has yet to be moved.", but it fails to tell where stuff can be proposed now.

I'm not sure we can deal with this at Commons:Village pump/Proposals, I'm sure we would have an easy majority there. - Alexis Jazz ping plz 11:32, 25 January 2019 (UTC)

@Alexis Jazz: You can file a technical RfC in Phabricator to stop checking for security vulnerabilities in uploaded files, but I would point out that there's no way we're dropping basic security controls like this, sorry. You could file a Phabricator task suggesting that MediaWiki strip it on upload, but I don't know how feasible that would be; given the security implications, it'd probably take a few months to do. As a work-around, you can trivially strip the problematic content from the image with a tool like imagemagick or similar. Jdforrester (WMF) (talk) 15:57, 25 January 2019 (UTC)
@Jdforrester (WMF): don't use words like "no way we're dropping basic security controls like this, sorry". Are you still supporting Netscape Navigator 2.0? This is not a "basic security control". It's a flawed check for a theoretical threat for a crapsack browser that Microsoft hasn't even supported itself for two and a half years with a market share of 1.4% (IE6 and IE7 combined) that can't be used in a secure way to begin with. You actually break features for regular users to support a browser that isn't even on life support but already pronounced dead two and half years ago and buried.. I like ranting. - Alexis Jazz ping plz 16:24, 25 January 2019 (UTC)
Oh, and about stripping the offending content: no, that is not trivial. First of all, one would have to download thousands of photos from Flickr somehow. After that, process all of them with a tool. Then, upload. Then, because the checksums no longer match, FlickrevieweR is going to fail them and human license reviewers need to waste their time on them. All of that to support Wikimedia users with an account (because there is no threat to those who don't log in) using IE6 or IE7. - Alexis Jazz ping plz 16:33, 25 January 2019 (UTC)
Can't the upload process automatically remove the data prior to upload or simply ignore it? Or can't it be whitelisted exclusively for uploading tools? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 23:00, 25 January 2019 (UTC)
@Donald Trung: removing the data comes with complications. The file will no longer be identical to the source, which is the standard. Also, FlickreviewR will fail them. The idea of ignoring the data is basically what caused all the recent events. Whitelisting for upload tools doesn't seem to make much sense. If someone had an incredibly poor evil plan to hack an IE6 user, would it matter whether they uploaded their image directly or uploaded it to Flickr first so they could import it? - Alexis Jazz ping plz 04:50, 27 January 2019 (UTC)
Hi, I agree that it looks pretty silly to block uploading such files, by all possible means available. Regards, Yann (talk) 18:44, 28 January 2019 (UTC)
This problem makes it difficult for licence reviewers. For example, File:Humphreys Peak, San Francisco Peaks.jpg is a scaled down version of a PD file that contains html codes. A licence reviewer is forced to download the image, edit the problematic EXIF, upload it, and manually approve it (example: File:Milky Way over the San Francisco Peaks.jpg). It adds so much unnecessary work, just for preventing some unimaginable security risks. A wikipedia user (7.5 mil/4.2 bil < 1% of world Internet users) has to use an 10+-year-out-of-date IE on Windows (market share<<1%) to visit such a file on Commons (=x/60mil) and try to display it in IE. Not to mention most problematic codes are not baits for attacks but just inclusion of self promoting URLs.--Roy17 (talk) 11:22, 1 February 2019 (UTC)

Tech News: 2019-05[edit]

18:14, 28 January 2019 (UTC)

Section closed with support for changes, however changes do not seem to have been implemented correctly.[edit]

The discussion on a proposal to update the padlock icons linked as follows ( https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals&oldid=337030076#Update_padlock_icons_that_Wikimedia_Commons_use_to_the_ones_that_the_English_Wikipedia_uses ), closed with support for the changes. The changes hower do not seem to have taken affect as seen on these pages if viewed (as a non-admin since I am not a admin, and it is protected for being only editable by admins), https://commons.wikimedia.org/w/index.php?title=File:Ukrainian_Wikipedia_15_logo_v01.svg&action=edit Aceing Winter Snows Harsh Cold (talk) 21:31, 30 January 2019 (UTC)

@Aceing Winter Snows Harsh Cold: The message there uses File:Padlock.svg, but I'm not sure why.   — Jeff G. please ping or talk to me 23:32, 30 January 2019 (UTC)
Pictogram voting keep.svg Fixed Next time just ask me directly Aceing Winter Snows Harsh Cold. There are hundreds of random uses of the old image scattered throughout the project. Most of which I can't actually see without logging out or by using another device. I was attempting to wait for the file usage list to update so I can clean up the leftovers but that is taking a little while longer than I expected it to. --Majora (talk) 17:09, 31 January 2019 (UTC)

Duplicate template misidentifies tagger[edit]

https://commons.wikimedia.org/w/index.php?title=File:Tirana_bikes.jpg&diff=337034090&oldid=337034004

"This file has been tagged by Smooth O"

https://commons.wikimedia.org/w/index.php?title=File:Tirana_bikes.jpg&diff=next&oldid=337034090

"This file has been tagged by SteinsplitterBot"

No, it was still tagged by Smooth O. (and incorrectly, because the so-called duplicate was higher quality and had EXIF unlike the "original") - Alexis Jazz ping plz 11:07, 31 January 2019 (UTC)

Help with Wikidata auto-categorization[edit]

Category:Ice hockey team is populated by 15 subcategories, despite the fact that it is a redirect to Category:Ice hockey teams. None of these 15 subcategories contains a link to the incorrect category, but each of them contains {{Wikidata infobox}}, so I presume that is where the category link is coming from. However, I can't track down the source of the error in Wikidata. Can anyone figure out where the incorrect link is coming from, and fix it? --R'n'B (talk) 15:05, 1 February 2019 (UTC)

Pinging @Mike Peel.   — Jeff G. please ping or talk to me 18:21, 1 February 2019 (UTC)
this should have fixed it, once the cache updates. Thanks. Mike Peel (talk) 23:42, 1 February 2019 (UTC)
Seems, only 1 category went alone. 14 null edits later now the redirect is empty. — Speravir – 01:42, 2 February 2019 (UTC)
The first one was a null edit by me, the cache does take a bit longer to refresh on its own. For background info (now I'm not on mobile), Category:Buffalo Sabres was being added to the category as Buffalo Sabres (Q131206) has award received (P166)=Presidents' Trophy (Q250246), and that then had category for recipients of this award (P2517)=ice hockey team (Q4498974) - that last part was wrong, and the edit to add that (by @LesserJerome:) is what I reverted. Thanks. Mike Peel (talk) 02:04, 2 February 2019 (UTC)

Tech News: 2019-06[edit]

17:11, 4 February 2019 (UTC)

Gallery mode="slideshow"[edit]

This ugly hack to get a slideshow without horizontal scrollbar floating with a {{wikidata infobox}} on the right is rather bizarrre:

  1. Why is there no style= or at least width= in Template:Wikidata infobox?
  2. Why does gallery style="max-width:66%" use this for its canvas, but still scales up the images to require a horrible scrollbar?
  3. Why does gallery heights="600px" not work for mode="slideshow", undocumented in Help:Gallery tag?
  4. Who does still know "Wilbur" aka HTML 3.2 to get what they want anyway?
  5. What is the effect on mobile devices? (Untested, "armed with Chrome" is too poor.)

84.46.53.198 20:58, 5 February 2019 (UTC)

Help with a bug stopping CC licensed data being stored on Commons[edit]

We can nearly use CC licensed datasets stored on Commons in our Wikidata queries and maps and graphs on Wikimedia projects using Wikidata data. YAAAYYY

We can't quite yet because of a bug that was started over two years ago. BOOOO

https://phabricator.wikimedia.org/T155290?fbclid=IwAR3FYWU8eTHOzf_R3_bni93Sx7wjFg4571j2WxbqiKc5-4ip-KWKMawqzSY

  • Wizards: please could you help fix the bug?
  • Muggles: please subscribe to the task to let people know its important to you

I've written some instructions to help people make maps on Wikimedia projects using Wikidata data but its not usable till this gets fixed...

Thanks

--John Cummings (talk) 10:23, 6 February 2019 (UTC)

@John Cummings: I commented on that task on 15 October 2017.   — Jeff G. please ping or talk to me 10:43, 6 February 2019 (UTC)
Thanks @Jeff G.:, yes part of my frustration is the age of the issue... I've found that awarding tasks a token seems to encourage other people to look at it. John Cummings (talk) 10:50, 6 February 2019 (UTC)

How can I archive multiple messages using the OneClickArchiver?[edit]

Usually on Mondays I receive both Tech News and Wikidata's Digest (or newsletter), preferably I would like to archive both at once. How can I archive multiple messages at once, I saw some users do that but I don't know how to do it myself, I attempted using the button at "More" but that kept giving me these error messages, what can I actually do to archive more than one message at a time? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:08, 11 February 2019 (UTC)

Tech News: 2019-07[edit]

18:44, 11 February 2019 (UTC)

Edittools JS errors[edit]

Hi, Currently Edittools above the editbox doesn't work for me (tested in Vector and Monobook). It appears randomnly once in a while with a lot of Javascript errors. Does anyone see this? The errors appear only very shortly, but I managed to make a screenshot: File:Edittools JS errors.png. Chrome Version 71.0.3578.98 (Official Build) (64-bit) on Windows10. Regards, Yann (talk) 15:47, 13 February 2019 (UTC)

JS console

Active resource loading counts reached a per-frame limit while the tab was in background. Network requests will be delayed until a previous loading finishes, or the tab is brought to the foreground. See https://www.chromestatus.com/feature/5527160148197376 for more details
load.php?debug=false&lang=en&modules=ext.CodeMirror.lib|jquery%2Coojs-ui-core%2Coojs-ui-widgets&skin=monobook&version=0byho8z:396 JQMIGRATE: Migrate is installed with logging active, version 3.0.1
VM47:75 This page is using the deprecated ResourceLoader module "jquery.ui.position".
(anonymous) @ VM47:75
VM47:35 This page is using the deprecated ResourceLoader module "jquery.ui.widget".
(anonymous) @ VM47:35
VM47:884 This page is using the deprecated ResourceLoader module "schema.UniversalLanguageSelector".
See https://phabricator.wikimedia.org/T205744 for migration info.
(anonymous) @ VM47:884
load.php?debug=false&lang=en&modules=startup&only=scripts&skin=monobook:4 Use of "wgAction" is deprecated. Use mw.config instead.

maybeLog @ load.php?debug=false&lang=en&modules=startup&only=scripts&skin=monobook:4
index.php?title=MediaWiki:Edittools.js&action=raw&ctype=text/javascript:109 Uncaught TypeError: $toolbar.wikiEditor is not a function
    at Object.makeToolbarButtons (index.php?title=MediaWiki:Edittools.js&action=raw&ctype=text/javascript:109)
    at index.php?title=MediaWiki:Edittools.js&action=raw&ctype=text/javascript:164
    at dispatch (load.php?debug=false&lang=en&modules=ext.CodeMirror.lib|jquery%2Coojs-ui-core%2Coojs-ui-widgets&skin=monobook&version=0byho8z:324)
    at elemData.handle (load.php?debug=false&lang=en&modules=ext.CodeMirror.lib|jquery%2Coojs-ui-core%2Coojs-ui-widgets&skin=monobook&version=0byho8z:320)

VM47:30 This page is using the deprecated ResourceLoader module "jquery.ui.core".
Please use OOUI instead.
(anonymous) @ VM47:30
load.php?debug=false&lang=en&modules=ext.CodeMirror.lib|jquery%2Coojs-ui-core%2Coojs-ui-widgets&skin=monobook&version=0byho8z:571 IconElement: Widgets with iconTitle set are deprecated, use title instead. See T76638 for details.
OO.ui.warnDeprecation @ load.php?debug=false&lang=en&modules=ext.CodeMirror.lib|jquery%2Coojs-ui-core%2Coojs-ui-widgets&skin=monobook&version=0byho8z:571
load.php?debug=false&lang=en&modules=ext.CodeMirror.lib|jquery%2Coojs-ui-core%2Coojs-ui-widgets&skin=monobook&version=0byho8z:571 IconElement: setIconTitle is deprecated, use setTitle of TitledElement instead. See T76638 for details.
OO.ui.warnDeprecation @ load.php?debug=false&lang=en&modules=ext.CodeMirror.lib|jquery%2Coojs-ui-core%2Coojs-ui-widgets&skin=monobook&version=0byho8z:571
VM74:1 This page is using the deprecated ResourceLoader module "schema.EditAttemptStep".
See https://phabricator.wikimedia.org/T205744 for migration info.
(anonymous) @ VM74:1

The error is here

maybeLog @ load.php?debug=false&lang=en&modules=startup&only=scripts&skin=monobook:4
index.php?title=MediaWiki:Edittools.js&action=raw&ctype=text/javascript:109 Uncaught TypeError: $toolbar.wikiEditor is not a function
    at Object.makeToolbarButtons (index.php?title=MediaWiki:Edittools.js&action=raw&ctype=text/javascript:109)
    at index.php?title=MediaWiki:Edittools.js&action=raw&ctype=text/javascript:164
    at dispatch (load.php?debug=false&lang=en&modules=ext.CodeMirror.lib|jquery%2Coojs-ui-core%2Coojs-ui-widgets&skin=monobook&version=0byho8z:324)
    at elemData.handle (load.php?debug=false&lang=en&modules=ext.CodeMirror.lib|jquery%2Coojs-ui-core%2Coojs-ui-widgets&skin=monobook&version=0byho8z:320)
@Yann: Odd. The error is saying that the wikiEditor object isn't attached to what it thinks $toolbar is; I can't replicate locally as I don't have whatever settings you do to get this code to execute, but my local $( '#wpTextbox1' ).wikiEditor definitely exists… No recent changes on-wiki or in-code that seem relevant. Possibly a race condition that you're now triggering more frequently due to reaching some boundary condition with other stuff? Jdforrester (WMF) (talk) 19:36, 13 February 2019 (UTC)
Which may be as simple to fix as switching off some extensions or closing some tabs. Chrome has a task manager under 'more tools', take a look there. In my current chrome session I had a background tab that was unexpectedly hogging processing power, no idea why, just a not-very-good website. -- (talk) 19:46, 13 February 2019 (UTC)

Tech News: 2019-08[edit]

23:13, 18 February 2019 (UTC)

Flickr2Commons down[edit]

Flickr2Commons has been stuck at "Loading..." since yesterday. According to the JavaScript console, there is a problem loading an API key: https://tools.wmflabs.org/fist/file_candidates/api.php?meta=all&action=get_flickr_key

Anyone know when this is going to be resolved? Ixfd64 (talk) 17:35, 21 February 2019 (UTC)

@Ixfd64: I created https://bitbucket.org/magnusmanske/flickr2commons/issues/59/loading-forever for you, as "The maintainer doesn't read" Commons talk:Flickr2Commons.   — Jeff G. please ping or talk to me 23:43, 21 February 2019 (UTC)

Global user rename and caching[edit]

m:Special:GlobalRenameProgress/Nngobl shows that renaming is complete, but File:Logo_des_Championnats_d'Europe_de_cyclisme_sur_route_2016.png #filehistory straggles behind (note that I deliberately didn’t try action=purge to showcase the bug). Shouldn’t global rename invalidate caches for all dependent pages? Incnis Mrsi (talk) 18:16, 21 February 2019 (UTC)

@Incnis Mrsi: It's probably stuck in the job queue.   — Jeff G. please ping or talk to me 23:35, 21 February 2019 (UTC)

Structured data and Special:UploadWizard, Structured data and file[edit]

Hello! Please, help me about Structured data menu for all users when we start Package Uploading company using Special:UploadWizard. Why do new users need this option while loading the file? They make a mistake and put the file description in the Structured data: Ex. (It was necessary to fill in the file description field). How to hide this menu when loading a file? Thanks! — Niklitov (talk) 18:51, 22 February 2019 (UTC)