In T4557#86740, @RhinosF1 wrote:

In T4557#86728, @Levreauj wrote:

Sorry but it does not work
I think it as to do with a mistake in the variable name in the setup filek from the extension page the variable starts with "eg" and no "wg"
I've look at the commit in Phabricator.
Thanks !

I’m struggling to find where the spelling error is. Can you give me its line number?

You need to import MediaWiki:Common.css.

Fixed locally, but ideally shouldn't happen.

I've restored the bureaucrat group, which should at least allow you to manage your wiki again and reset it to where it was before.

I'm also noticing an issue where the contributions page (example) is throwing an internal error. It's probably something different, but should absolutely be looked into.

@GoddessofTirar I hate to see how long that this has gone without a response, please let us know if you are still interested in this.

@Paladox (again)

@Paladox status?

Done by @Paladox a few days ago apparently.

@Hypercane Can you confirm what protection levels you want, and what groups should have access to them?

Is there any specific error message? Might be useful for figuring out what's up.

Would it at all make sense to just add all custom protection levels to wgAvailableRights? That way they can be assigned with ManageWiki.

I've added managewiki to founder, as that's easy. TidyConfig is set by default to RemexHtml.

Is there anything else that can be done in the meantime? Such as T4260? Any space we can get is space we need.

Just got around to it.

This can be enabled using Special:ManageWiki/extensions

ParserFunctions is enabled on all wikis by default.

Please use Special:ManageWiki/extensions.

@Paladox ^

Chrome, and it only seems to appear when I have the console open on a page reload. Using Microsoft edge I instead get "CSP14307: Source ''self'' was already provided for directive 'default-src' for Content-Security-Policy."

@Paladox last person to touch CSP config.

@John purging the cache wasn't a fix, as the issue would seem to be fixed, but would return upon loading another page or reloading the same page. In fact, sometimes clearing the cache just plain didn't work.

Depending on your email host, you can probably configure a filter so that all Miraheze emails are never marked as spam.

Image dumps need to be generated by sysadmins, see J8.

I'm also noticing similar behavior on toxicfandomsandhatedomswiki (many files missing as of today), digimonwiki (several files missing), and testwiki (one file). Not sure of other wikis are affected, but it seems likely.

@Paladox ^

Hmm, seems to be the CSP. Guess we'll have to figure out how we want to do external images, when we limit the external resources that can be loaded.

https://git.io/fj3EI is likely the fix.

I can't seem to replicate using Special:ManageWikiPermissions alone. Is it possible to be leftover from when this happened before, or is there some other cause (like wiki creation)?

Fixed in https://git.io/fjOQ4

Seems like it was possible to delete it and restore it, and looks like that fixed it. Odd though, I'm not actually sure what happened there.

I've spun up https://git.io/fjmYW to fix the issue.

I spun up a quick testing environment and discovered that the issue is caused by MWP only saving perms that are visible on the page. In other words, any blacklisted perm is removed from the user group as soon as the form is submitted.

Should be resolved now, please re-open if not.

We should either move on this, or figure out another way to get more space on db4, as the disk space has been pretty much stuck in critical for some time now.

That's definitely something that deserves more investigation if possible.

No idea.

If I'm not mistaken, we're out of space again.

Once this gets merged (to configure Comments on your wiki), I believe that will be everything.

In T4222#80592, @MacFan4000 wrote:

In T4222#80585, @Void wrote:

Should also probably look at wiki.hackdown.me

That one works for me

Should also probably look at wiki.hackdown.me

Declined per @John, Fixed in this case by @Paladox.

Any updates on this?

@Reception123 status?

Accessing ManageWiki requires bureaucrat permission.

@Paladox status? (again)

You should be able to install PollNY now if you can't get AJAXPoll working.

Hmm, looks like the namespaces information is not populated @John/@Paladox mind looking into that?

1. Go into Special:ManageWikiNamespaces for the namespace in question, and make sure subpages is enabled for that namespace
2. No idea.
3. The extension can be configured, if you want. To add to all pages, you may want to look into something like MassEditRegex.
4. Wiki statistics don't update immediately, they tend to take a few minutes up to a few hours to take effect.

Sorry for the delay into looking into this, but it looks like the default value for $wgLinkTitlesParseOnEdit is true, and we wouldn't accomplish anything by redefining it.

In that case, then, would someone mind either enabling voteny or disabling blogpage on hypopediawiki?

The extension itself looks pretty simple (easy to add), although you may want to consider built in collapsible elements.

I've done a quick fix on one of the modules, as I don't believe adding wikibase alone would fix it. Would need to confirm though.

That would likely be icinga.miraheze.org (login as guest/guest), however it's odd, because the servers (lizardfs1 and lizardfs2) both seem to still have 17 GB free. Is this just not allocated to the file system? Thing number two, can we actually do something about this, even if it winds up being a temporary thing?

In T4193#80079, @CiviHosting wrote:

For the record, this is the code I have in place currently. The last part is commented out because otherwise the site won't start. Seems we have a bit of a chicken/egg problem with all.dblist...

/srv/dblist/all.dblist comes from $wgCreateWikiDBDirectory ($wgCreateWikiDBDirectory . '/all.dblist'), and the actual file is created by the CreateWiki/ManageWiki extensions.

I've installed CreateWiki/ManageWiki before, and this is the config I needed:

$wgCreateWikiDatabase = "wiki";  // Or any central DB
$wgCreateWikiSubdomain = "local.wmftest.net";  // Not sure about this one
$wgCreateWikiDBDirectory = '/srv/dblist';  // Or any other suitable place for dblists
$wgManageWikiCDBDirectory = '/var/cache/managewiki';  // Or any other location for a cache

You'll also need this at the bottom of LocalSettings.php to extract the config from ManageWiki:

$wgLocalDatabases = array();
$wmgDatabaseList = file( "/srv/dblist/all.dblist" );
// ManageWiki settings
foreach ( $wmgDatabaseList as $wikiLine ) {
	$wikiDB = explode( '|', $wikiLine, 6 );
	list( $DBname, $siteName, $siteLang, $siteExtensions, $siteSettings ) = array_pad( $wikiDB, 6, '' );
	$wgLocalDatabases[] = $DBname;
	$wgConf->settings['wgSitename'][$DBname] = $siteName;
	$wgConf->settings['wgLanguageCode'][$DBname] = $siteLang;
	$siteExtensionsArray = explode( ",", $siteExtensions );
	foreach ( $wgManageWikiExtensions as $name => $ext ) {
		if ( in_array( $name, $siteExtensionsArray ) ) {
			$wgConf->settings[$ext['var']][$DBname] = true;
		}
	}
	$siteSettingsArray = json_decode( $siteSettings, true );
	if ( is_array( $siteSettingsArray ) || is_object( $siteSettingsArray ) ) {
		foreach ( $siteSettingsArray as $setVar => $setVal ) {
			$wgConf->settings[$setVar][$DBname] = $setVal;
		}
	}
}

FWIW, attempting to do CORS requests has never worked (at least not on my end), and I first set up a testing script for it nearly two years ago (but that has to do with the API).

In that case, I'd suggest looking at Moderation. It requires that every edit be approved by an administrator before it goes live. It's not exactly what you're looking for, but unless I'm missing something painfully obvious, there doesn't seem to be an extension (that we support) to approve users before they can edit.

As far as I know, there's no easy extension you can install to get this done. Instead you need to setup editing restrictions using our existing tools.