Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://phabricator.wikimedia.org/tag/mediawiki-extensions-wikimediamaintenance below:

MediaWiki-extensions-WikimediaMaintenance

I think this is done. If there are any remaining issues, they can be split out into separate tasks.

I dropped api_feature_usage, bot_passwords and globalimagelinks in nupwiki. Someone in TSP says securepoll_log should actually exists and it's weird it's not in enwiki.

Not sure about securepoll_log but the rest of nupwiki tables missing in enwiki I'm sure needs fixing and removal.

Comparing it to enwiki, on enwiki there are following tables which are not on nupwiki:

Currently the following tables are created on wiki creation (nupwiki created in T390384):

bounce_records now fixed thanks to @Reedy and only cn_notice_projects left.

Annoyingly, sendBulkEmails.php does not emails users who have unset the allowemail user preference ("Allow other users to email me") which is not really relevant for this kind of email. So I'll use a copy of it with a trivial change:

32c32,37
< require_once __DIR__ . '/WikimediaMaintenance.php';
---
> $IP = getenv( 'MW_INSTALL_PATH' );
> if ( $IP === false ) {
> 	$IP = __DIR__ . '/../../..';
> }
> 
> require_once "$IP/extensions/WikimediaMaintenance/WikimediaMaintenance.php";
235c240
< 		if ( !$user->canReceiveEmail() ) {
---
> 		if ( !$user->isEmailConfirmed() ) {

Maybe all extensions listed as todo in T348573: All Wikimedia extensions that store their data outside the main database should use a virtual database domain can cause creation of tables in the wrong database, when the extensions is enabled at the install step.

Maybe all extensions listed as todo in T348573: All Wikimedia extensions that store their data outside the main database should use a virtual database domain can cause creation of tables in the wrong database, when the extensions is enabled at the install step.

bounce_records now fixed thanks to @Reedy and only cn_notice_projects left.

For both bounce_records and cn_notice_projects they can't be fixed because they are not migrated to virtual domains and have their own ad-hoc way.

Change #1123643 merged by jenkins-bot:

[mediawiki/extensions/ApiFeatureUsage@master] Fix wiring of schema change updates

https://gerrit.wikimedia.org/r/1123643

Change #1123643 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[mediawiki/extensions/ApiFeatureUsage@master] Fix wiring of schema change updates

https://gerrit.wikimedia.org/r/1123643

I had to drop so many tables created incorrectly in new wikis:

globaljsonlinks ['arbcom_zhwiki', 'idwikivoyage', 'kncwiki', 'satwiktionary', 'sylwiki', 'tigwiki']
globaljsonlinks_target ['arbcom_zhwiki', 'idwikivoyage', 'kncwiki', 'satwiktionary', 'sylwiki', 'tigwiki']
globaljsonlinks_wiki ['arbcom_zhwiki', 'idwikivoyage', 'kncwiki', 'satwiktionary', 'sylwiki', 'tigwiki']
cn_notice_projects ['idwikivoyage', 'kncwiki', 'satwiktionary', 'sylwiki', 'tigwiki']
api_feature_usage ['arbcom_zhwiki', 'idwikivoyage', 'kncwiki', 'satwiktionary', 'sylwiki', 'tigwiki']
bounce_records ['arbcom_zhwiki', 'idwikivoyage', 'kncwiki', 'satwiktionary', 'sylwiki', 'tigwiki']

Please do not create new wikis until this is fixed. cc @Zabe

I had to drop so many tables created incorrectly in new wikis:

globaljsonlinks ['arbcom_zhwiki', 'idwikivoyage', 'kncwiki', 'satwiktionary', 'sylwiki', 'tigwiki']
globaljsonlinks_target ['arbcom_zhwiki', 'idwikivoyage', 'kncwiki', 'satwiktionary', 'sylwiki', 'tigwiki']
globaljsonlinks_wiki ['arbcom_zhwiki', 'idwikivoyage', 'kncwiki', 'satwiktionary', 'sylwiki', 'tigwiki']
cn_notice_projects ['idwikivoyage', 'kncwiki', 'satwiktionary', 'sylwiki', 'tigwiki']
api_feature_usage ['arbcom_zhwiki', 'idwikivoyage', 'kncwiki', 'satwiktionary', 'sylwiki', 'tigwiki']
bounce_records ['arbcom_zhwiki', 'idwikivoyage', 'kncwiki', 'satwiktionary', 'sylwiki', 'tigwiki']

Mentioned in SAL (#wikimedia-operations) [2025-02-26T16:19:57Z] <Amir1> dropping incorrectly created tables in new wikis (T352113)

I don't want to close this boldly in case I'm wrong, but I think this might be able to be called resolved?

I told the script to write to a file which I forgot to chmod properly.

·

,

,

,

,

,

,

,

,

,

,

,

,

,

,

,

,

,

,

And these two:

api_feature_usage ['idwikivoyage', 'tigwiki']
bounce_records ['idwikivoyage', 'tigwiki']

unsuppressCrossWiki.php was removed from WikimediaMaintenance on 2024-08-09 (https://gerrit.wikimedia.org/r/1061066), therefore closing this task as declined.

And these two:

api_feature_usage ['idwikivoyage', 'tigwiki']
bounce_records ['idwikivoyage', 'tigwiki']

Probably charts is misconfigured, worth noting that the tables are being created on new wikis:

globaljsonlinks ['idwikivoyage', 'tigwiki', 'testcommonswiki']
globaljsonlinks_target ['idwikivoyage', 'tigwiki', 'testcommonswiki']
globaljsonlinks_wiki ['idwikivoyage', 'tigwiki', 'testcommonswiki']

Anything left to do here?

(I cleaned up the remaining whichMessage code from the Common.js of a handful of wikis that were still unconditionally loading it on all page views.)

That leaves the cleaning up of Sitesupport-url, but first, the decision to cease creating Sitesupport-url entries for newly added wikis, which is still happening.

Mentioned in SAL (#wikimedia-operations) [2024-12-06T01:32:10Z] <TimStarling> on mwmaint2002: deleting [[MediaWiki:Sitesupport-url]] pages per T379205

I suspect it's probably easier for someone in the staff global group to do it on-wiki via the API than to run a maintenance script. @matmarex did that for T375789 for example.

Any idea how we can get the local [[MediaWiki:Sitesupport-url]] overrides deleted?

Oh ho! well then I will be bold and resolve this. If it happens again feel free to reopen.

This is probably obsolete following T352113

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4