@Universal_Omega Are either of these issues reported upstream? It seems to me that the best option would be to wait until the extension has fixed the issue with the version active in T6915, and then upgrade to the fixed version (after verifying that it doesn't additionally break things further).

Question: If you do the first 250 pages, are they not removed from the list if you go back in to do the same replacement? I'm worried about having this config be exposed to the users, as too high of a value can cause significant issues.

For those of you who may still be monitoring this task, it looks like it has been resolved upstream in https://phabricator.wikimedia.org/T271047.

Cause is from Extension:CookieWarning, see https://github.com/wikimedia/mediawiki-extensions-CookieWarning/blob/0dc0e795a117e385f145ba0fbf9ff7c476a6017d/resources/ext.CookieWarning/ext.CookieWarning.less

Confirmed, something on the anon user stylesheet is setting #siteNotice to have a z-index of 1999, forcing it to display over everything else on the page, I'm searching for where this is coming from.

I can't confirm this on Chrome using the Vector skin, but I can confirm this in Edge? It appears to be a difference between logged in and logged out users.

Probably need to update https://github.com/miraheze/puppet/blob/dfc343ed456c95152844024b9f0c53570b172feb/modules/mediawiki/templates/mediawiki.conf.erb#L172
and https://github.com/miraheze/puppet/blob/29f4c3fa989d7bc65bfcd07a04b2330122601df3/modules/varnish/templates/default.vcl#L370

You may need to edit each namespace (though Special:ManageWiki/namespaces) to specifically enable Visual Editor in those namespaces.

Try going to chrome://settings/siteData?searchSubpage=miraheze and click "Remove All Shown". This should clear you cookies for all miraheze wikis, allowing you to start a fresh session and login properly.

Can we please make sure we are facilitating user requests instead of declining them when we can't do exactly what they've asked? I find it especially distasteful to link someone to a document that basically just tells them they are asking the wrong question instead of working with them to find an actual solution to the problem, or even just figuring out what the actual problem is.
(edited, not a frequent issue)

Hi, when setting your logo, you have to open up the actual image. This might not make sense at first, but if you are using https://lf13videos.miraheze.org/wiki/File:My_Drawing-15.sketchpad.png, the actual image is located at https://static.miraheze.org/lf13videoswiki/3/30/My_Drawing-15.sketchpad.png. Simply click on the image on the first page to get the actual file. You will need to set the logo to the static.miraheze.org variant in order for this to work.

Looks like missing dependencies. I've replicated this issue on a local install, and it seems to be resolvable by installing the yarn package manager and running yarn install --ignore-engine --force in the skin/Femiwiki directory.

Looks like the logo display has been overwritten by styling in MediaWiki:Common.css.

Fixed!

@Reception123 Doesn't seem to have been fixed.

See my change here. It was broken here, where it looks like you pasted the HTML output of the page into Visual Editor instead of the actual wikitext into the code editor.

It would also be a good way to avoid issues like T5827.

It's looking like a potential browser issue, my session has persisted on my current browser (same computer, using Edge instead of Chrome), and there don't seem to be any issues.

That failed too, so I'm checking now to see if it's a browser issue.

I can confirm, having logged in via both username + password and using the wiki logon that I get logged out after an hour or two consistently for these past few weeks (testing github logon now). Interestingly, this did not occur on my mobile device (where I logged in using password), and phabricator itself is still reporting that the sessions exist.

Undeleted wiki, looks like you got it just before permanent deletion.

I'll also note that attempting to change the status of deletion/locking requires multiple submissions in order to go through without error. The ManageWiki page throws an error, but no actual error code or information is provided.

This is a side effect of running rebuildrecentchanges.php and will affect any wiki the script is ran on. Running rebuildall.php won't make a difference, because it runs the same exact thing.

In T4164#107191, @Reception123 wrote:

What remains to be done is manual closure vs script which is still blocked on community consensus.

This effect is caused by the EditSubpages extension, which is installed on your wiki. It looks like that extension is poorly named, and may not be doing what you think it is doing.

Something that could/would really help with this process is exposing the RequestWikiQueue to the api so that requests could be fetched by an external process in a programmatic fashion without having to parse raw HTML. With that alone, I'm fairly sure I could build and test a dataset and implement this in a python-based bot/script.

Try adding a name to the main namespace and then deleting it.

Boldly declining, no functional implementation of a GlobalCheckUser exists, and likely won't exist for some time.

If I may clarify here:

Looking like a decline to me.

• SoundCloudTag appears to be dependent on some very Wikia specific things that we'd need to overhaul.
• InfoboxBuilder is a maybe, but it does look outdated and the code hasn't been changed much for several years.

Can this be made public now?

We've both blacklisted titleblacklistlog and disabled the functionality of the extension that generates those logs. For future reference, the wgTitleBlacklistLogHits seems to only log titleblacklist hits that prevent account creations, which reveals the IP address that attempted to create the account. This is somewhat of an edge case, but I do not believe we will need those logs for anything, nor do I believe anyone (without an NDA) should be able to access which logs that do exist (which should only be on test2wiki right now).

Resolved with https://git.io/JJeFx

Metawiki is only applying the local MediaWiki:Titleblacklist and not the global Title blacklist. See https://github.com/miraheze/mw-config/blob/master/LocalSettings.php#L3041

Resolved in https://git.io/JfpZf

I'm thinking more along the lines of

diff --git a/includes/formFactory/ManageWikiFormFactoryBuilder.php b/includes/formFactory/ManageWikiFormFactoryBuilder.php
index 6381706..25473b8 100644
--- a/includes/formFactory/ManageWikiFormFactoryBuilder.php
+++ b/includes/formFactory/ManageWikiFormFactoryBuilder.php
@@ -541,11 +541,15 @@ class ManageWikiFormFactoryBuilder {

[0b494d2c66dcce05e3467cc1] 2020-06-14 22:45:12: Fatal exception of type "MWException"

Try setting the css to .mw-body p {margin-bottom: 1em;}. CSS can be finicky when trying to get it to apply over existing CSS.

You can use Special:ManageWiki/permissions for this purposes.

There is no method to globally implement a gadget, though there is an absolutely ancient upstream task about doing so (T22153). As I don't see that being implemented any time soon, it's likely the closest you can come is by using the User:Name/global.js page to load in the script globally.

Did you perform these operations in this exact order?

Looks like this isn't possible, and there are several upstream tasks about implementing this:
https://phabricator.wikimedia.org/T243931
https://phabricator.wikimedia.org/T52329
https://phabricator.wikimedia.org/T41610

Ok, so I've been taking a look into this, and I've not been able to find much on mediawiki.org that seems all that helpful. I'm going to take a look at some methods of getting around these requirements, but we'll see if they work.

Hmm, I remember looking at this earlier, and noting that it appeared the regular expression \p{L}\p{N} did not seem to be recognized or evaluated properly, but I was just testing it and it looks like it works now. @utolee90 is this still broken on your end?

In T5321#100881, @Void wrote:

Have you attempted to first login to login wiki before logging into any other wiki?

Have you attempted to first login to login wiki before logging into any other wiki?

If you are getting a session expired error or similar, please attempt to clear your browser's cookies and try again. If that's not the error you are getting, or the method doesn't work, please provide more details on the error you are getting.

Handled by @Paladox two days ago

I'll take a look shortly. Most likely just spambot registration, and there's not all that much we can do to stop them from registering accounts. They are, however, prevented from making edits.

In T5296#100548, @Krivan wrote:

No. Now it is working properly. Thanks!

In T5294#100547, @DavidVadkerti wrote:

No, it seems it's fixed now. Thank you for the help :)

@Paladox @Reception123 this has been open for three weeks without resolution.

Resolved by @Paladox

I think raising the limit to at least 1000 might be a decent start, given that that's the point where the software starts queuing the deletion instead of handling it in the request.

This is an interesting bug that seems to be a problem with core MediaWiki (but not something all that easy to accomplish without ManageWiki), and probably something we should take efforts to prevent in ManageWiki, probably by requiring all namespace names to be completely unique.

Check to see if my latest action fixed it, and if so, we may want to take a look at this issue. (I'm thinking of forcing all saved group names to be lowercase, but this would require some migration for existing cases).

I believe I've seen this before. There seems to be a small bug in ManageWiki permissions where editing a group, but using different capitalization seems to "rename" the group to the new capitalization, removing the rights from anyone in the old group name. It can be resolved (I think) by editing and saving (without making changes) the ManageWiki/permissions page for the group with the correct capitalization.

This is possibly an issue cause by ManageWiki, specifically in the implementation of namespaces.

The talk namespace is available in the same page, but different tab of Special:ManageWiki/namespaces as its parent namespace.

For the on-wiki rename, please fill out Special:GlobalRenameRequest, thanks!

LabledSectionTransclusion is already available through Special:ManageWiki/extensions

Using, Special:ManageWiki/extensions, enable Extension:YouTube. The second link provided should include the documentation needed to use it properly.

Done!

Per ^

Looks like you are hiding the div#contentSub elements using CSS. This is where those notices appear.

This can be set by using Special:ManageWiki/permissions. To remove the edit right from the "*" group, simply uncheck the box for the right on Special:ManageWiki/permissions/* and submit the page. To add the right, go to the unassigned permissions tab, check the box for the permission, and save the page.

Is there any reason that the Math extension (https://www.mediawiki.org/wiki/Extension:Math) does not work for what you are doing? The primary reason I'm asking is that the MathLaTeX extension is likely impossible for us to use, as it is designed for use in a Windows environment.

I've deleted the pages, as they just required bigdelete.

https://github.com/miraheze/ManageWiki/pull/128