FWIW and in case anyone's interested, on bgwiki we have a Python daemon that does the job for us for a few years now: https://github.com/wikimedia-bg/git-sync

@So9q Thank you so much for sharing this! I had the same problem and the culprit turned out to be Extension:ConfirmEdit. It is enabled by default, at least in the Wikibase Docker images. Had a gut feeling about this extension before, but only after I found your info did I decide to test it, which confirmed my suspicions. I haven't looked at its code, but I wouldn't be surprised if it isn't compatible with Wikibase, because of the different UI (or code paths).

Thank you very much again everyone! Really appreciate your help!

Many thanks again, everyone! :)

In T299224#7646882, @RhinosF1 wrote:

Not sure why it was missed

In T299224#7622492, @kerberizer wrote:

In T299224#7622488, @RhinosF1 wrote:

I read over the consensus. I understand VE should be enabled too and indexing disabled. Is that correct?

Yes, that's indeed correct, thank you! :)

In T299224#7646449, @Juan90264 wrote:

@kerberizer: The Draft (NS:118) and Draft_talk (NS:119) namespace are working.

In T299224#7622488, @RhinosF1 wrote:

I read over the consensus. I understand VE should be enabled too and indexing disabled. Is that correct?

Thank you very much, @gh87 ! I really appreciate it that you continue to take care about the problems. @Urbanecm , would it be too difficult to, say, redirect all requests for pages in the main NS to МедияУики:Sitenotice? Or maybe even all requests (obviously, without requests to the sitenotice itself, unless we want some funny recursion :D)—I'd be fine even with the discussions hidden from view. I saved the important ones in the web archive, so there is a “backup”.

In T233322#6659039, @Urbanecm wrote:

In T233322#5522411, @StevenJ81 wrote:

I'm going to take ownership for the moment, and set the status to "stalled". We're looking into just a little further steward cleanup here on possible copyvios. When that is finished, I will create a subtask for the redirect.

I propose to close this task as resolved. Wikis are never really deleted (ie. the content stays at the servers), and unless the content would cause us some trouble, I think it should just stay as-is.

In T247782#5973542, @Lucas_Werkmeister_WMDE wrote:

Sorry, I messed up the title (and in such a way that it caused Herald to add an extra subscriber).

Many thanks to everyone working on this and to @Nullzero in particular for the helpful notice!

In T233322#5521587, @Urbanecm wrote:

No remark is stupid :). In [my previous patchg(https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/538662), I've added bgwikinews to closed.dblist, which is used - among other places - in groupOverrides. My patch basically means that instead of my custom configuration (that allows sysops to edit, not just stewards), the default configuration for closed wikis will be used.

@Urbanecm Don't have much experience with MW, so sorry if it's a stupid remark, but wouldn't this patch also remove the stewards' access? I think @StevenJ81 might possibly want them to still be able to do some additional cleaning.

As I wrote on my talk page on Meta, I'm basically ready with the cleanup, so I guess the wiki could be further locked, but this is really up to @StevenJ81 to decide/request.

Thank you very much, @Urbanecm!

In T233322#5516587, @Urbanecm wrote:

Hello everyone,

I'm a bit surprised that the project is "closed" using a filter. if this is that urgent so it can't wait a while, feel free to ping me at #wikimedia-tech IRC channel, I'd be happy to introduce the restriction quickly.

Now, I'm wondering what's the required next step from the sysadmins: properly close the wiki? Restrict editing to just admins?

FWIW, I've also removed the previous sitenotice, which I had put to warn the users about the ongoing discussions and the possible closure of the project. I won't be posting anything in its place, until (possibly) instructed to do so.

Completely forgot how AbuseFilter could also prevents deletions, which may be also desirable at this moment, and restricts even the sysops themselves. So, excellent idea, indeed, thanks again!

In T233322#5516478, @MF-Warburg wrote:

Hmm. Is not an edit filter a better temporary solution?

As nobody on the project seems to care about the Board's decision, happily continuing to edit, I decided to exercise my still valid sysop privileges and sysop-protect all existing pages with the following message:

This project is being closed per WMF LangCom's recommendation to the Board of Trustees. For details, see: https://meta.wikimedia.org/w/index.php?oldid=19405704 and https://phabricator.wikimedia.org/T233322

@StevenJ81 seeing how there has been very active editing as soon as half an hour ago, I could possibly, as a very first step, fully protect all pages on the wiki (via the API) with some appropriate comment in the protection message?

FWIW, Google's robots.txt parser is now open source

@Dcljr: fulfilled... sorry for not being clearer

@Jdforrester-WMF Thank you very much! Judging by those discussions, we seem to be on the right track here, especially given the very low level of activity on bgnews.

FWIW, it might be interesting to know how this option is configured for the Wikinews projects in other languages.

@Daimona bgwiki done

In T206944#4664396, @Aklapper wrote:

Closing as declined as it cannot be reproduced and no code change was identified.

In the meantime, the problem went away.

{
    "batchcomplete": "",
    "query": {
        "users": [
            {
                "userid": 79518,
                "name": "Pankoantchev"
            }
        ]
    }
}

In T187749#4628282, @Izno wrote:

Being able to hack Lua modules elsewhere might be nice also.

This seems to have been fixed.

I don't think TemplateStyles is going to solve the root problem. Sure, theoretically it will give the ordinary users much more flexibility in styling their tables, but it isn't reasonable to expect that most will want to deal with full-blown CSS. Currently, the best way of achieving per-column alignment seems to be defining specific classes that should cover all possible cases: col-1-center, col-2-right, etc., and then adding them to the table header, e.g. {| class="wikitable col-3-right col-4-right". This is cumbersome, especially for larger tables, but at least it doesn't require technical knowledge from the ordinary editors.

In T192895#4157575, @Urbanecm wrote:

Deployed and tested (https://bg.wikipedia.org/wiki/%D0%9F%D0%BE%D1%82%D1%80%D0%B5%D0%B1%D0%B8%D1%82%D0%B5%D0%BB:Martin_Urbanec/sandbox). If you want to have the tracking category ("Pages with maps") translated, please edit https://translatewiki.net/wiki/MediaWiki:Kartographer-tracking-category/bg and wait (only approved translators can edit, if don't know one, add the translation as a comment to this task).

As for the concatenation, it was a rather crude method to insert comments for each domain (as it needs an explanation why it was added). I'll think of an alternative way to do this, so that the regex could become a single string.

@ori, the contains_any approach is arguably simpler, but wouldn't it lead to false positives, e.g., if I understand correctly how it works, contains_any(added_links, "my-site.com", ...) would fire also on yummy-site.com.

BTW, since this is a regex for websites, I might actually split it in 28 parts: one for each starting letter of the alphabet and one each for when the domain name starts with a number or with a Cyrillic letter, i.e. forbidden_regex_A, forbidden_regex_B, ... forbidden_regex_Z, forbidden_regex_NUM, forbidden_regex_CYR. Then obviously it'll be something like added_links irlike forbidden_regex_A | added_links irlike forbidden_regex_B | ... | added_links irlike forbidden_regex_CYR. Which actually would be more efficient server-wise: as large as possible regexes, but not too large to cause breakage, or many smaller OR-ed regexes?

Sorry that our filter has caused trouble on your side. I've split it in two parts as kindly suggested by @ori. Just one question though: is there any way to know what is the maximum regex length? The thing is, this filter may be extended in the future, and we might hit the same problem. Of course, we may just split it into three regexes right away to have larger margin for error, but still some clear indication of when a regex is too large would be nice. Could for instance a check be made when the filter is saved so that whoever was updating it would know immediately that they need to split it into even smaller fragments?

@hashar, thanks. I had already added it for the Morning SWAT, but if the EU mid-day SWAT is more convenient for you, it's totally fine by me (hadn't added it there, as all the 8 slots seemed taken). I think I'll also be available in IRC if the need arises.

@hashar, could you please add anyone who might be interested in keeping track of this task or, better yet, who might want to claim it, as I don't know the devs unfortunately. For myself, while I'd very much like to help, I'm afraid it isn't likely to happen very soon, considering that I do very little programming overall, and have almost zero experience in PHP. Still, I'll keep an eye on it. Thanks! :)

@hashar, much appreciated indeed! I'll see to push it tomorrow.

In T146908#2674525, @Reedy wrote:

Please feel free to submit a change request on gerrit to the operations/mediawiki-config repository :)

In T146908#2674452, @Reedy wrote:

I see numerous blank lines before line 423 in https://en.wikipedia.org/robots.txt