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

Relevant pull request.

What needs to be done on this? I see that it has been reverted, but it's not obvious why.

In T5040#95894, @Jidanni wrote:

@Paladox could you please add a URL below pointing to whatever code change you made? Thanks.

https://git.io/Je5AY if no one objects.

Looks it works, but the cache needs to be purged server-side for all pages. There is a possibility this will resolve itself automatically, but a sysadmin can run purgeList.php --purge --all on your wiki.

@Figurehigh The loops extension requires that the Variable extension is enabled in order for many of its features to work.

We could try setting a default preference for all users to see if that allows this to work properly.

Access to this right was restricted as a result of T4046

Configurator is incompatible with our current setup and poses a massive security risk. If you want to make a configuration change not available through ManageWiki, it needs to go through a sysadmin.

If you wait ten to twenty minutes it should start working.

You can only request to get your own username changed, except for a few situations (generally usurpation of an unused account).

Handled by @Paladox