In T6537#128181, @Void wrote:

In T6537#128177, @RhinosF1 wrote:

ManageWiki changes can be done by stewards and requested to them.

I don't recall this being the standard, especially for items in the restricted section of ManageWiki/settings. Additionally, in this technical context, I'd recommend not having stewards change such options, especially since I have no clue what wgDefaultRobotPolicy is or how it works. (I can guess, but I'd prefer to defer to a sysadmin on this matter).

Was resolved a while ago

Remounted mw5

https://github.com/miraheze/MirahezeMagic/blob/master/includes/MirahezeMagicHooks.php#L30

In T6431#127594, @Dmehus wrote:

Do you know what the approximate cost per month, on average, for adding an additional cache proxy is

Justification for another cp covering Amercias may be justified as looking at Grafana for 7 day rolling averages for requests/s;

I'm going to liaise with @Owen to see if we can achieve this before this goal period ends. Based on last progress update from him, I think it's just a web API and then extension implementation left?

In T6434#126151, @Dmehus wrote:

@John It may not be related to the recent closures, but do we know why this was inadvertently marked as closed?

Last edit was Nov 1st, only just been reported with nothing to show that this was recent and couldn’t have been an issue related to the Nov 4th script issues.

Why is this a performance issue?

Also, the last change to the script was ~18 days before the problem was reported.

root@jobrunner1:~# php /srv/mediawiki/w/maintenance/eval.php --wiki loginwiki

$ts = (int)MediaWiki\Shell\Shell::makeScriptCommand( '/srv/mediawiki/w/extensions/CreateWiki/maintenance/checkLastWikiActivity.php', [ '--wiki', 'comiccrossroadswiki' ] )->limits( [ 'memory' => 0, 'filesize' => 0 ] )->execute()->getStdout();

Who ran the script? I see nothing in the logs - I ran it in noop mode.

In T6403#125701, @RhinosF1 wrote:

If the problem goes away and doesn't come back after a week, then yes it's invalid.

In T6403#125699, @RhinosF1 wrote:

Then the task isn't invalid, we just don't have a solution or explanation for whatever caused it.

In T6403#125695, @RhinosF1 wrote:

@John: Well, how come wikis ended up closed that shouldn't have been.

I've looked into this from every angle and I can't find the cause, but more importantly, I can't prove there is an issue. The script works 100% as expected when running it - the wikis listed above aren't inactive and the script reflects that, the wikis it did say are inactive - are inactive, and the wikis it said are eligible for closing - are.

I'm running the script as well, and all closures/inactive notices seem correct to me so far.

I've looked into this, and I can't seem to be able to reproduce the problem on *any* wiki listed above. Every wiki listed activates https://github.com/miraheze/CreateWiki/blob/6f6d3312ea7459b377b8c2c659888b770119ddd5/maintenance/manageInactiveWikis.php#L80, which does nothing as the wiki is active.

In T6412#125620, @Paladox wrote:

In T6412#125618, @John wrote:

The values in $wgConf aren’t cached

@John Well then how comes wgUseCdn is true even though it should be false? And I'm not implying they are cached in wgConf, I'm implying CreateWiki cache is causing this.

The values in $wgConf aren’t cached

There’s an inactive clusters one roo

If the DB cluster isn’t listed, it’s because it’s not configured to be a cluster. This is a configuration issue, not extension issue

In T6403#125491, @Reception123 wrote:

@John A side note question, apparently some are saying that their wiki has still been closed after I absented the script. Is that possible? If so should it be commented out in addition?

Disable the script if it’s not functioning properly, this isn’t an unbreak now kind of task. It probably doesn’t even qualify for high personally

Which wikis? Without anything to look at, I can't investigate this issue.

With the introduction of the new helper classes, I do want to look at re-designing how ManageWiki as a whole interfaces with eachother. So enabling extensions and configuring them happens as a 'step by step' method, where once you enable an extension - you can change namespaces (if any), user groups/permissions (if any) and settings (if any) before the extension is actually physically enabled.

Though I should note, running rebuildAll is the cause, which is why the script shouldn’t be ran randomly without reason. It should only be ran after an import requiring it or another major content affecting change takes place.

https://phabricator.wikimedia.org/T259265 Was upstreamed last time, nothing has practically changed

If I’m correct, I think a lot of people started experiencing this when ‘sameSite’ cookie was added I think? @Paladox can you confirm this theory?

ManageWiki behaves as is programmed in the config and does not do break the extension. This is an issue with our configuration and not ManageWiki.

Unable to reproduce using test2. Disabled an extension and cache updating, enabled an extension and cache updated. resetWiki seems to be functioning fine

Configuration only changes

I'll switch us over to mail1 potentially tomorrow or Tuesday

This is weird extension design I believe - any user who edits a page must have "embed_pdf" permissions. https://gfi.miraheze.org/w/index.php?title=Detail_-_napojenie_dvojpl%C3%A1%C5%A1%C5%A5ovej_SDK_prie%C4%8Dky_-_vlhk%C3%A9_prostredie_BD_Fuxova&diff=prev&oldid=2106 works, but then when the page is edited by someone without "embed_pdf" permissions, the page errors such as https://gfi.miraheze.org/w/index.php?title=Detail_-_napojenie_dvojpl%C3%A1%C5%A1%C5%A5ovej_SDK_prie%C4%8Dky_-_vlhk%C3%A9_prostredie_BD_Fuxova&diff=next&oldid=2106.

There are two data sources at work here.

The error which caused this has been fixed. You can now doing this locally.

In T6095#123471, @Southparkfan wrote:

@John it doesn't look like larger VARCHARs are possible. Even if you don't use the rl_id field, it does seem to be working fine at first glance, without fundamentally changing the schema (the current, old fields can stay). What do you think?

Only realistic way to minimise any impact from Wikimedia going down is to not use Wikimedia. Looking at cost/benefits, cost seems higher than benefits.

itemPage has 3 params, class pywikibot.ItemPage(site, title=None, ns=None). With ns=None being the default, it is assuming the item namespace is the main space (0), which isn't the case for Miraheze. For Miraheze it is Item: which has id 860.

This is possible in ManageWiki and had been since the feature was added.

Just an update but I'm still not able to reproduce this issue.

https://phabricator.wikimedia.org/T136207 is the upstream task for this issue.

This is an upstream task

No one has made any progress on this, and I'm unsure what such action would look like to achieve a change which wouldn't result in the response of "they were locked unfairly" when the user themselves would communicate that they were locked anyway.

Are not part of the extension, the example does not necessarily need to contain code only added by the extension as shown here. The extension added code seems to work fine as far as I can see.

It works for me, posting a comment immediately shows it and deleting the comment also works.

I can't see any Thread: prefixed pages so likely already resolved

Upstream task filed, no further action needed by us - closing task as fix will file in normally

Unable to reproduce the issues, polls seem to interact and react normally

Sounds like this is a task better placed at https://phabricator.wikimedia.org

Fixed since July https://github.com/miraheze/mw-config/pull/3147

I don't think I've heard of this happening recently

Per IRC

No evidence presented that cURL is slow, or even that ping is slow