In T416775#11594022, @Bawolff wrote:

Is the issue that depth is like a 32 bit number so of the range isn't normalized everything appears white?

Why is there no comment in this task that auto-subscribe for mass message sections is now enabled? Is there an opt-out for being subscribed to all messages places when using the mass message tool? When I as an admin send an invitation ob behalf of someone else or general information to many hundred users I do not want to get hundred notifications when these messages are archived of these user pages.

Okay, I had a deeper look. This is definitely not a bot but real users. Most of them were created on the swwiki. I asked there if they know about any campaign running at the moment.

If there is no campaign advertising the ISA tool resulting in many new accounts this could be some kind of bot.

The error vanished in some way and the section is now present again.

I think the cause is this change https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1196975 from T85561

I am not aware of any usage of inputbox used on a regular wikitext page where the link is intended for searching for files. The only possibly case might be gadgets.

In T400023#11112534, @Aklapper wrote:

In T400023#11107298, @GPSLeo wrote:

I think main user pages should definitely be indexed. They are a place for contributors to represent themself.

Within the project(s') scope that makes sense, and Wikimedians know how to find a person's user page. In public, that makes way less sense to me, as user pages are not a replacement for your "internet profile".

I think main user pages should definitely be indexed. They are a place for contributors to represent themself. Abusive user pages are removed very fast. For subpages below User:Example/ indexing is often not useful as most of these pages are just personal notes or temporary maintenance pages.

In T363622#11068246, @Ladsgroup wrote:

Is it possible to take a look and remove some?

I currently have to reload my watchlist for multiple minutes to get the list and not a timeout. I am basically not able to do my task on Commons because of this.

As there are likely many more of these cases is there a possibility to scan over all files on Commons to find all files affected?

This is interesting. There is a very similar file with only minor different crop. As the clouds are the same they have to be taken withing seconds and because of the look they are also taken with the same camera. But the metadata show totally different recording time and camera model. So the archive file is not the lost file or something changed the metadata. The metadata on the archived page is in line with the file existing on Commons.

This should not have been deleted, I have restored the page. We still need to find out what happened here and if the file can be restored.

I currently get timeouts on my Commons watchlist for over 50% of the list reloads.

In T378756#10997480, @Prototyperspective wrote:

SpecialSearch I think wasn't even designed with Commons in mind.

There are only some active direct usages of <inputbox> on Commons (through transclusion the search boxes are one a huge amount of pages):

I am not aware of any usage of inputbox on Commons where using MediaSearch does make sense. The default should be the old search and MediaSearch should only be used when a parameter is set.

Why should MediaSearch ever support prefixes? Prefixes are primarily for search on meta pages. MediaSearch is made to easily find media files and not to search for content in discussion page archives.

The turned off means hidden from users without sufficient user rights. This is of course also reached if entirely turned of.

There are now over 200 uploads affected and these are only the ones not already corrected. https://quarry.wmcloud.org/query/93694

When can we expect the reload to be finished and the query service having complete and up to date data again?

There is now a decision on Commons that if the Upload dialog is not updated in a way that it is hidden to users without sufficient rights an AbuseFilter will be activated to block those uploads. As filters can not look for local rights on the Wiki where the Upload dialog is used the filter will block all uploads of users who are not autoconfirmed on Commons. We will activate this blocking filter in August and a warning filter some weeks before. (The warning AbuseFilter is technically not possible, warnings are de facto also blocking the upload in Upload dialog.)

When is this expected to be solved? Because of this problem many important maintenance and monitoring tools are broken. This should have UBN priority.

There is now a 29 hour replication lag on the cloud service replicas for databases on s4 and 25 hour replication lag for databases on s2, s6 and s7. https://replag.toolforge.org/

I am not sure if this is related to the changes made here.

The bug now appeared at Campaign:wle-tg. It did not appear anymore the the Campaign:wle-de I would therefore assume that hiding the old revisions as a hot-fix works.

I got the error multiple times the last days on Commons and now again.

One comment on filename, caption and description:

The bug appeared again and it seem not to affect all uploads they are performed at the same time. I try to hide the old revisions as a hot-fix.

The Cloud-Services project tag is not intended to have any tasks. Please check the list on https://phabricator.wikimedia.org/project/profile/832/ and replace it with a more specific project tag to this task. Thanks!

One small thing: The warning box says deleted but the warning to provide an author says removed. It should be the same for both. I think deleted is better.

I doubt the usefulness of putting the release generator directly here.

I would look at the story for Wiki Loves contests from the participant side:

• A reader of Wikipedia sees that there is a campaign on a certain topic running. They click on a link to participate create an account and upload photos in the app. In the best case there is a map where they can find objects near them. (And then hopefully continue uploading photos or editing Wikipedia after the contest.)

I would really like to have such a functionality. I would not use it for my own uploads but I would like to have it as a Wiki Loves contest organiser. From that perspective there are some very important features:

I am currently getting the following error for around the half of all my upload attempts.

Why not just keeping the database and make the sorting on every request or even on client side. Custom sorting is a feature request multiple times. This does not work for the very large categories but they are not discovered through the regular UI anyway.

I just noticed that this method is currently producing 421 errors as proxy for tile.openstreetmap.org. Other services work. I had the same issue with a non Toolforge page where adding "proxy_ssl_server_name on" to the nginx config solved the problem. But the Toolforge proxy yaml already is configured this way.

I think the word "owner" should be removed as it is very ambiguous. We have many cases of people who think they can upload a photo just because they bought a physical copy.

I do not think that this is the same bug. Here the files are indeed not deleted but in my report the API gives an error code for an action that was performed.

I am currently again experiencing lots of different error messages during file upload.

Shortening the watchlist is a bad workaround for the problem. I get this error with 217000 pages on my watchlist. More than the half are my own files and categories I manage in a project and I therefore want to see what happens to them. And there are many thousand files on my watchlist which were vandalized in the past and are likely to be vandalized in the future again. I get multiple hits on these files every day.

I think items are the most important and could be a good first step. But especially strings would also be useful to hand over identifiers.

Since several days I also experience this error message very frequently with approximately 20% of all watchlist page reloads and sometimes up to 50% affected. But the error never appeared twice in a row.

What is the status on this? The lack of IPv6 support of the webservice seems to be one of the reasons for slow connections from some internet providers. T362822

This seems to be a problem of the Deutsche Telekom network. I asked them for a statement on this. I think this can therefore become closed. But if this is not fixed soon it might be good to document this problem somewhere.

The problem is currently present again. I made some measurements with an interesting result. There seems to be some kind of insufficient peering capacity when the download comes directly from eqiad and is not on some cache in Europe.

The problem seems to be fixed for now. The loading speed is not very fast but currently absolutely usable. At the time I created this report the respond times for the pbf files were around 30 to 60 seconds.

The loading speed is currently much faster than yesterday. I especially experienced the problem with the vector tile loading on my tool https://uploadmap.toolforge.org/protectedareaseu.html.

The Cloud-Services project tag is not intended to have any tasks. Please check the list on https://phabricator.wikimedia.org/project/profile/832/ and replace it with a more specific project tag to this task. Thanks!

I see the link on fully opened diff pages. But on RTRC (https://meta.wikimedia.org/wiki/User:Krinkle/Tools/Real-Time_Recent_Changes) the links are missing.

I looked at the edits made using the affected user rights manager gadget:

I think there should also be an incident report on this as a bug blocking the deletion of files could cause very serious problems if there is a file that needs to be deleted immediately. The legal team should also comment on this topic.

I think this is the same error which causes T348375: Commons removal of last remaining caption: Caught exception of type Wikimedia\Rdbms\DBUnexpectedError.

I just noticed that all last edits on audio files are affected by this. I tested this on https://commons.wikimedia.org/wiki/File:2019-08-17_Test_file_for_TimedMediaHandler_audio_captions.ogg with the following error codes:

I got the error again and again at the file page of an audio file but this time on a Wikitext edit.
https://commons.wikimedia.org/wiki/File:Javier_Milei_-_nombre_(ES-ar).ogg
When I click the revert button on the last edit I get the following error message: [f41e10bb-593c-4ddc-a499-f8af808578fa] 2023-10-08 18:41:16: Fataler Ausnahmefehler des Typs „Wikimedia\Rdbms\DBUnexpectedError“
Same for undo: [b3f94f11-495f-400e-aec5-7db8d7f0a33d] 2023-10-08 18:42:11: Fataler Ausnahmefehler des Typs „Wikimedia\Rdbms\DBUnexpectedError“
And also for manual removal of the added Wikitext: [2ed02a9b-1877-4323-9041-d6e93abab37b] 2023-10-08 18:42:45: Fataler Ausnahmefehler des Typs „Wikimedia\Rdbms\DBUnexpectedError“

Before the "Caught exception of type Wikimedia\Rdbms\DBUnexpectedError" message there is only some kind of hash number. But when I tried to get these number again I got no error message and the edit succeeded.

I see. This seem to be a problem with the testing environment.

I think this is not linked to the error rate but it makes the need for a fix more urgent. The Wiki Loves Monuments contests started today.

Are feature requests and bug reports on this project tracked here on Phabricator, on a wiki page or on Github?

I also get many 5xx and stashfailed errors on my current uploads using python requests library.

As this does not seem to be solved in the near future it might be useful to add a link to Special:EditWatchlist/raw to the GUI of the watchlist page.

Simple webserver restart in this case.

I tried to migrate my script. As it requires the requests python package I needed to create a new venv. I followed the Instructions at https://wikitech.wikimedia.org/wiki/Help:Toolforge/Python#Kubernetes_python_jobs but when running the command "chmod ug+x bootstrap_venv.sh" I get the response "chmod: changing permissions of 'bootstrap_venv.sh': Operation not permitted". I am logged in as the tool(become toolname).

I can confirm that I got many "Invalid CSRF token." errors when uploading.
The errors did pop up random after every upload attempt or only every hundred files. (I request new tokens for every file.)

I would like to have the German GeoNutzV (https://commons.wikimedia.org/wiki/Template:GeoNutzV) license added as an allowed license. It is basically the same as CC-BY.

Update: Now it works fine for me too.

Just opening a page using the tiles like https://maps.wikimedia.org itself in a browser and looking in the network analysis tool of the browser.

Many other limits are higher for logged in users or users with higher rights then for not logged in users. Would it be possible to do the same here?