- User Since
- Mar 15 2017, 2:19 AM (313 w, 6 d)
- LDAP User
- MediaWiki User
- Jeff G. [ Global Accounts ]
Jan 17 2023
Affects Commons, too. :(
Jan 15 2023
Jan 14 2023
Nov 8 2022
This amounts to a request to increase the default $wgMaxArticleSize of 2048 (kilobytes) on production wikis. It was authored Feb 21 2006, 7:55 PM in rSVN13070 by timstarling (now @tstarling). Much has changed in user environments in the 16 years since then.
Nov 1 2022
Oct 24 2022
It happened again with edit https://commons.wikimedia.org/w/index.php?title=Commons:Help_desk&curid=523680&diff=698609678&oldid=698605975 00:49 24 October 2022 EDT -0400 (04:49 24 October 2022 UTC). Note also that there are three other edits to the Commons Help desk that falsely show as "updated since your last visit" too.
Oct 23 2022
Here is how that 05:20, 23 October 2022 EDT -0400 (09:20, 23 October 2022 UTC) edit looks on my watchlist with grouping.
On the third hand, it did not happen with my next edit https://commons.wikimedia.org/w/index.php?title=Commons:Administrators%27_noticeboard/User_problems&diff=698405102&oldid=698403797 .
Oct 20 2022
Oct 17 2022
Same for en.wikipedia.beta.wmflabs.org.
Sep 17 2022
Aug 29 2022
How can file revisions go missing? Don't we have backups? Why can't we delete a file, even though one or more file revisions is missing? What can we do to prevent file revisions from going missing in the future, and to compensate for their missing status in the present?
Jul 28 2022
May 18 2022
On-wiki error report: https://commons.wikimedia.org/w/index.php?title=MediaWiki_talk:Gadget-AjaxQuickDelete.js/auto-errors&diff=prev&oldid=657064030
On-wiki discussion: https://commons.wikimedia.org/w/index.php?title=MediaWiki_talk:Gadget-AjaxQuickDelete.js#Renaming
This has been autoreported 11 times so far on https://commons.wikimedia.org/wiki/MediaWiki_talk:Gadget-AjaxQuickDelete.js/auto-errors , starting "Wed, 18 May 2022 08:35:19 GMT".
Apr 22 2022
Nov 22 2021
Aug 19 2021
That would work for me. The consensus has now been archived to c:Commons:Village pump/Archive/2021/07#Page creation logs.
Aug 6 2021
Aug 5 2021
Jun 8 2021
Jun 2 2021
Another victim, this time at 6MB: https://commons.wikimedia.org/wiki/File:Age_of_sail_.jpg
Apr 6 2021
The third upload attempt (a retry with extra comment) completed.
The status of the checkbox appears to be dimmed only after the attempted upload starts.
I sometimes get sequences like the following, which is also concerning (indicating a stuck status for upwards of 30s):
00995: 11/86> in progress Upload: 100%
01110: 11/86> upload is stuck
01111: 11/86> Connection seems to be okay. Waiting one more time...
01115: 11/86> upload is stuck
01116: 11/86> Connection seems to be okay. Waiting one more time...
01120: 11/86> upload is stuck
01121: 11/86> Connection seems to be okay. Waiting one more time...
01125: 11/86> Chunk uploaded
The second attempt failed with stash 188ub70n674k.lpxppz.122116.webm and the following (trying again with the original formulation):
05171: 86/86> Server error 504 after uploading chunk:
Response: upstream request timeout
05171: 86/86> upload in progress Upload: 100%
05235: FAILED: internal_api_error_DBQueryError: [95e6982b-cd9d-4b4c-a124-ce7a1ca45c8b] Caught exception of type Wikimedia\Rdbms\DBQueryError
I tried to publish the file in my UploadStash anyway using a community tool, it said to try back tomorrow. I also started another upload of the same file with "use stash and async (recommended for large videos and photos)" unchecked, and I will check progress after I sleep.
Mar 27 2021
There are also 1,101 pages in https://commons.wikimedia.org/wiki/Category:User_talk_pages_where_template_include_size_is_exceeded .
Jan 28 2021
See also https://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard#Deletion_requests_issue . That section was archived to https://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/Archive_83#Deletion_requests_issue without further comment. https://commons.wikimedia.org/wiki/Category:Pages_where_template_include_size_is_exceeded stands at 289 pages and rising.
Jan 12 2021
See also https://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/Vandalism/Archive_14#TRANSCODE_STATUS .
Dec 6 2020
Nov 27 2020
Another victim: https://commons.wikimedia.org/wiki/File:Jilemnick%C3%BD_h%C5%99bitov_Jind%C5%99ich_Ambro%C5%BE_n%C3%A1hrobek.jpg
Nov 19 2020
This appears to be happening again with https://commons.wikimedia.org/wiki/File:Standard_Model_of_Elementary_Particles_Euskaraz.jpg - please see https://commons.wikimedia.org/wiki/Commons:Help_desk#An_uploaded_image_can't_be_seen_at_any_given_wiki for details.
Oct 15 2020
Oct 12 2020
No tokens found. :(
Aug 3 2020
Jul 7 2020
Strangely, this is happening with my (proxied) Puffin Browser Pro, but not with Chrome, on the same iPad with the same connection.
Apr 9 2020
Mar 14 2020
This could be extended to all presentations of video thumbnails. See also https://commons.wikimedia.org/wiki/Commons:Help_desk#Changing_default_thumbnail_for_a_video.
Mar 1 2020
The discussion of the display of https://commons.wikimedia.org/wiki/File:Ambigram_New_York_Rich_Man.png was archived automatically to https://commons.wikimedia.org/wiki/Commons:Help_desk/Archive/2020/02#Thumbnail_doesn%27t_display and now I get the following:
Request from 22.214.171.124 via cp1086 frontend, Varnish XID 520356410
Upstream caches: cp1086 int
Error: 500, Internal Server Error at Sun, 01 Mar 2020 14:32:22 GMT
Feb 17 2020
Sep 11 2019
Jul 22 2019
Jul 14 2019
However, as of this diff 07:59, 14 July 2019 (UTC) it is still happening.
Jul 9 2019
Jul 5 2019
As of this diff 07:48, 3 July 2019 (UTC), it is thankfully no longer shuffling parameters on my user talk page on Commons.
Jun 22 2019
Jun 18 2019
It is still happening for me today. In the attached screenshot, I am "User:Jeff G." and my edit of 18:41 (UTC-4, EDT, 22:41 UTC with screenshot taken around 23:00 UTC) should have marked all the previous edits to c:Commons:Help desk as read, but it didn't.
May 3 2019
The problematic files included https://commons.wikimedia.org/w/index.php?title=File:Bareg5.jpg , https://commons.wikimedia.org/w/index.php?title=File:Toyota_Bus-Train_01.jpg , and https://commons.wikimedia.org/w/index.php?title=File:Toyota_Bus-Train_02.jpg ; all had to be deleted.
Apr 21 2019
A workaround is to start with [[Special:Log/block]] or https://commons.wikimedia.org/wiki/Special:Log/block instead.
Apr 2 2019
The same goes for https://tools.wmflabs.org/geocommons/ .
Mar 28 2019
Mar 25 2019
Mar 23 2019
Mar 22 2019
I found out in the past couple of days that when I unwatch and then watch a stubborn bolded page, that resolves the symptom for the current revision of that page better (with a higher success rate indistinguishable from 100%) than refreshing and purging. Of course, that is just a workaround and it doesn't scale.
Mar 20 2019
Mar 18 2019
This is also happening on Commons, see https://commons.wikimedia.org/wiki/Commons:Village_pump/Technical#Pages_visited_via_diff_remain_bolded .
Mar 12 2019
See also https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals/Archive/2016/08#Rfc:_Should_we_request_a_configuration_change_to_shut_down_cross-wiki_uploads?.
Mar 3 2019
Another example: https://commons.wikimedia.org/wiki/File:Miguel_Baptista_Benedict.jpg
Feb 15 2019
Can this tool please be configured to not import under 10 bytes file description page revisions, or at least to pad the ones under 10 bytes with spaces or the 10 byte string "Padded4AF4"? Alternatively, can it be configured to back off importation of revisions which fail any AF and import the rest (unless the latest revision fails)?
Feb 12 2019
Jan 31 2019
Jan 19 2019
Dec 29 2018
Sometimes, the rotation sought is not around the center point, but around the central vertical or horizontal axis (sometimes called mirroring, flipping, or flopping). This should be doable losslessly. See also c:MediaWiki talk:Gadget-RotateLink.js#Mirroring as Rotation.
Dec 20 2018
More examples: https://commons.wikimedia.org/wiki/File:East_Huntington_Bridge_Looking_Downstream.jpg and https://commons.wikimedia.org/wiki/File:East_Huntington_Looking_Downstream.jpg
Nov 24 2018
Nov 19 2018
Sep 13 2018
Aug 3 2018
Finding and fixing the problem would be great; automating the restart would be a close second.
Jul 2 2018
Can you try putting it back as a test? How big was it?
Jul 1 2018
This problem also appears to be affecting StalkToy and CrossActivity at https://tools.wmflabs.org/meta/stalktoy/ and https://tools.wmflabs.org/meta/crossactivity/ .
This has been happening on Commons, too. This edit by Bsadowski 1, who has Local user-groups Image reviewers, File movers, Rollbackers and Autoconfirmed users and Global user-group Stewards, appears unpatrolled in my watchlist. As a member of Image reviewers, that user should inherit the Autopatrolled group rights. https://commons.wikimedia.org/wiki/Special:ListGroupRights confirms that five groups have the right "Have one's own edits automatically marked as patrolled (autopatrol)": Image reviewers, Autopatrollers; Bots; Patrollers; and Administrators. See also https://commons.wikimedia.org/wiki/COM:VP#Unpatrolled rollbacks.
I suggest merge with T198449.