User Details
- User Since
- Aug 8 2016, 22:25 (238 w, 6 d)
- Availability
- Available
- IRC Nickname
- Voidwalker
- GitHub User
- The-Voidwalker
- Miraheze User
- Void [ Global Accounts ]
Wed, Mar 3
@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).
Thu, Feb 25
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.
Feb 2 2021
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.
Jan 31 2021
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.
Jan 17 2021
Jan 4 2021
You may need to edit each namespace (though Special:ManageWiki/namespaces) to specifically enable Visual Editor in those namespaces.
Dec 11 2020
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.
Dec 1 2020
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)
Nov 23 2020
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.
Nov 12 2020
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.
Oct 25 2020
Looks like the logo display has been overwritten by styling in MediaWiki:Common.css.
Sep 3 2020
Fixed!
Sep 1 2020
@Reception123 Doesn't seem to have been fixed.
Aug 12 2020
Aug 2 2020
It would also be a good way to avoid issues like T5827.
Jul 27 2020
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.
Jul 25 2020
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.
Jul 24 2020
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.
Jul 23 2020
Jul 21 2020
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.
Jul 10 2020
Jul 9 2020
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.
Jul 7 2020
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.
Jul 5 2020
Jul 3 2020
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.
Jul 2 2020
If I may clarify here:
Jul 1 2020
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.
Jun 28 2020
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
Jun 26 2020
Jun 24 2020
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
Jun 23 2020
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 {
Jun 22 2020
Jun 14 2020
[0b494d2c66dcce05e3467cc1] 2020-06-14 22:45:12: Fatal exception of type "MWException"
Jun 11 2020
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.
May 15 2020
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.
May 6 2020
Apr 13 2020
Did you perform these operations in this exact order?
Apr 11 2020
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.
Apr 2 2020
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?
Mar 12 2020
Mar 11 2020
Have you attempted to first login to login wiki before logging into any other wiki?
Mar 10 2020
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.
Mar 9 2020
Mar 5 2020
Handled by @Paladox two days ago
Mar 3 2020
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.
@Paladox @Reception123 this has been open for three weeks without resolution.
Mar 2 2020
Mar 1 2020
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.
Feb 21 2020
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.
Feb 10 2020
This is possibly an issue cause by ManageWiki, specifically in the implementation of namespaces.
Jan 25 2020
The talk namespace is available in the same page, but different tab of Special:ManageWiki/namespaces as its parent namespace.
Jan 23 2020
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.
Jan 19 2020
Jan 12 2020
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.
Jan 6 2020
I've deleted the pages, as they just required bigdelete.