Community noticeboard

Code Editor doesn't note errors, warnings and info
@SolidBlock When SolidBlock and I edit CSS, JavaScript or Lua modules on RSWiki, the code editor does't note errors. Are there any wikis having the similar problems with Code Editor? Zes M Young (talk) 12:42, 23 September 2021 (UTC)

In addition, the following logs that may be relevant are found in the console: Content Security Policy: 页面设置阻止读取位于 blob:https://rs.miraheze.org/fce8550f-73e7-4237-97ef-c826cb8f9c02 的一项资源("script-src"). The same issue happens on Meta as well. --SolidBlock (talk) 12:49, 23 September 2021 (UTC)


 * This issue should be fixed by this but nobody has approved it yet. 13:36, 25 September 2021 (UTC)
 * Now it has been fixed. Zes M Young (talk) 13:07, 9 October 2021 (UTC)

Help, embeded content not working
I was doing well building up the content for the land wiki alliance, but recently all my embedded content stopped loading (video's from youtube and vimeo, and google sheets). It all used to work. It just says "this content is blocked. Contact the site owner to fix the issue."

Can someone tell me how to fix this? here is the wiki:

https://landwikialliance.miraheze.org/wiki/Main_Page Jono.hughes (talk) 11:00, 24 September 2021 (UTC)


 * Possibly a CSP issue. I've alerted sysadmins about it but I would recommend you also create a Phabricator task about it. Agent Isai  Talk to me! 17:00, 24 September 2021 (UTC)

I was going to make a post about this because I'm having the same issue on the Random-ness wiki and my friend's private wiki won't load them either. (On Firefox it's coming up as completely blank space.) However on the CLG Wiki the videos are loading fine, so I'm not sure what's going on. Raichu&#39;s Endless Nights (talk) 16:51, 24 September 2021 (UTC)


 * just to follow up, has this changed or been resolved? --Raidarr (talk) 09:29, 10 October 2021 (UTC)
 * Unfortunately, no, the same thing is happening, places where videos should be come up as blank. This is also happening on my own wiki as well as the Random-ness wiki I think it might have something to do with the extentions because CLG Wiki displays videos fine, and I think they use a different extention for videos. Raichu&#39;s Endless Nights (talk) 10:19, 10 October 2021 (UTC)

Import multiple images at once
Hello, I would like to know how to import several images at once, like on Fandom. At the moment, I can only import one at a time and it's quite long. Thanks in advance. Darkrai18 (talk) 09:34, 27 September 2021 (UTC)


 * If you have all the images already, what some do is enable MsUpload in Special:ManageWiki/extensions and then drag and drop the images in the wiki editor. If you're a bit more tech-savvy, consider using PyWikiBot. Hope this helps. Agent Isai  Talk to me! 13:39, 27 September 2021 (UTC)


 * Well, the images I want to import are not yet on my wiki. Darkrai18 (talk) 11:47, 28 September 2021 (UTC)
 * has this been resolved? If not, I'll ask for a bit more context to see if this can be settled. --Raidarr (talk) 09:12, 9 October 2021 (UTC)

EditTop Gadget, and Wikiplus
I am trying to add the EditTop (EN Wikipedia) gadget to my wiki (XComhghall Wiki). I imported the definition, the js page, ad the css page, but it does not show up in preferences. What is wrong, and what do I need to do?

I installed Wikiplus (EN Wikipedia), a user-maintained script (see the  discussion on MW), on  my global.js page. It was working fine in August. The edit box appeared on top of the section I edit, as show in this gif, and can be expanded and moved. Currently, Wikiplus works fine on both EN and ZH Wikipedia, but I am experiencing problems with it on my wiki. The edit box appears at the bottom of the page, cannot be moved, and has lost the original background color, border, design, etc. Do you know what the problem might be? What can I do?

Thank you very much. — XComhghall (talk) 02:34, 2 October 2021 (UTC)


 * Likely you have not imported everything, which might CSS and possibly even JS data outside the JS itself that you imported that is a wikipedia customized dependency (might integrate with something else done wikipedia side that isn't in default mediawiki), and there may be a conflict with whatever skin you're using locally for your own wiki. This is all vague-speak though - is it still an issue? If so I can try to troubleshoot more deeply, or point someone more experienced to this thread. --Raidarr (talk) 09:10, 9 October 2021 (UTC)
 * Both problems (1. the EditTop gadget, 2. Wikiplus) still exist.
 * For the EditTop gadget, I imported MediaWiki: Gadget-edittop, MediaWiki: Gadget-edittop.css, MediaWiki: Gadget-edittop.js, and MediaWiki: Gadgets-definition. However, I cannot find it in Special: Preferences.
 * Wikiplus used to work just fine on Miraheze. The only thing I imported was my global.js page.
 * Thank you very much, XComhghall (talk) 22:15, 13 October 2021 (UTC)

Could you please raise $wgExpensiveParserFunctionLimit
The default limit for expensive parser function calls is 99 and altering the $wgExpensiveParserFunctionLimit in the “Manage this wiki's additional settings” page(s) seems to require: Permissions - managewiki-restricted

Is there any way I could get the limit on my wiki raised to over 200 or higher?

One of the Lua modules in some of the templates I have ported over from Wikipedia is currently asking for 189 parser functions.

Thanks in advance. – Mitchell Gore (talk) 06:35, 2 October 2021 (UTC)


 * Has this been answered elsewhere? I'm behind on watching noticeboards, so just checking to see if it has, and if not, point the attention of someone appropriate to this thread. --Raidarr (talk) 09:07, 9 October 2021 (UTC)


 * I put in the request at phabricator and got it raised to 200, but the Template:Taxonbar I ported over from Wikipedia is still demanding a higher number of parser functions, so it’s still erroring. I have a second request in to have it raised to a higher number, but it hasn't been raised yet (going on 4 days now). – Mitchell Gore (talk) 17:25, 9 October 2021 (UTC)
 * Thank you for the notice. I'm afraid it's a waiting game from here, especially if the limit is getting particularly high (at that point they may prefer to see something less expensive used than keep upping the resources). They'll certainly reply eventually, but I know there's a few rather key tasks that just hopped on their plate, so it might be a bit. --Raidarr (talk) 09:24, 10 October 2021 (UTC)

Little question
Hello, I have a question. If I decide to change the subject of my wiki, for example change a wiki that talks about the characters of the fiction into a wiki that talks about all the fiction (i.e. characters, weapons, games...) while keeping my content, would I have the right to do so? If so, how? Thanks in advance. Darkrai18 (talk) 14:19, 4 October 2021 (UTC)


 * Are you talking about changing the wiki name? Yellowass.png (talk) 19:14, 4 October 2021 (UTC)
 * I believe they're talking about changing their wikis scope. Agent Isai  Talk to me! 19:21, 4 October 2021 (UTC)
 * I talking about scope, effectively. Darkrai18 (talk) 20:26, 4 October 2021 (UTC)
 * with a community, this must be done with consensus and a clearly defined vote/decision with community support. Without a community I believe this requires special approval to ensure it still fits with Content Policy. That said, I think the change you're making is fairly small and quite reasonable, and there should be no trouble in this case. Just to be safe I'll bring into it (sorry, I think this is the third ping I've thrown today >.>). --Raidarr (talk) 09:05, 9 October 2021 (UTC)
 * Well, keep me posted then. Darkrai18 (talk) 17:12, 9 October 2021 (UTC)

Marble House of PHP recruiting
Hello user, I have had a website I have created that has been abandoned for some time now, and I want to revive it. The Marble House of PHP is a wiki I created dedicated to storing, collecting, discussing, writing, and storytelling literature. It has been over 6 months since I created the wiki, however, there was 0 contributions or users who edited what so ever.. I have posted this topic to encourage activity in this wiki, and if you have enough activity and contributions, you can become an admin. Book and literature lovers, this site may be for you.

Link: marblehouse.miraheze.org

Best regards, Hoxen (talk) 16:28, 4 October 2021 (UTC)


 * Unfortunately wikis for creative writing on Miraheze in particular let alone in general is heavily oversaturated, and truly serious projects typically use other platforms or create their own wiki for their setting. So time in the wild has nothing to do with traction I'm afraid. --Raidarr (talk) 19:44, 4 October 2021 (UTC)
 * My intent of the wiki was to be somewhat as Wikisource, but with different measures and policies. But creative writing wikis are truly oversaturated. User:Raidarr--Hoxen (talk) 21:17, 4 October 2021 (UTC)
 * I wish you well on this; for what it's worth, perhaps you could do more to develop the structure, since refining the platform might help you get more users than it simply being offered as a 'blank slate' on its own. --Raidarr (talk) 09:00, 9 October 2021 (UTC)

Join Shaw's Nightmare wiki
Join the Shaw's Nightmare wiki which is about the Shaw's Nightmare series of first-person shooter games. I'm looking for administrators/moderators, if you are interested go to my profile and talk to me on there.

I'm still looking for editors too to help create articles. Mickey96 (talk) 16:48, 7 October 2021 (UTC)

Suggestion: search in wikidiscover
Why does Special:WikiDiscover not have search? I mean, i could use Ctrl+F but its painful as i need to navigate to every of the pages

I understand it's gonna probably be hard but this just a suggestion

Also, can someone make a physics wiki and computers wiki? Anpang (talk) 01:47, 8 October 2021 (UTC)


 * A search might be nice to further its usability. I know I've seen physics wikis around, but ironically without a search feature I'm afraid I can't help much. There's AboutPCs for computers, for what it's worth. Though you'd have to put quite a bit of effort into making it happen. In the meantime I'm afraid the Gazetteer of wikis is vaguely your best bet for what it is, and I know it's not an answer here. --Raidarr (talk) 08:58, 9 October 2021 (UTC)

How do I stop the flood of email notifications?
I'm administrator of a wiki. I keep getting email notifications whenever a user edits a page. I specifically set email options to not send me anything but I'm still getting dozens and dozens of emails.

I also tried setting global preferences to no avail.

The only thing that worked outright was to delete my email address.

Should I try anything else? Bulbizarre (talk) 01:38, 9 October 2021 (UTC)


 * Per your wiki's ManageWiki settings, you are set to receive notifications for every edit done on the wiki. To stop this, click the aforementioned link and remove yourself from Users Notified On All Changes ($wmgUsersNotifiedOnAllChanges). Agent Isai  Talk to me! 02:02, 9 October 2021 (UTC)
 * Thank you! Bulbizarre (talk) 18:00, 9 October 2021 (UTC)

Problem with DISPLAYTITLE
Hi. So here it is. I've set up the Displaytitle extension, which allows the title modified by DISPLAYTITLE to appear in categories, for example. But I would like to remove the "Category:" to show only the "Characters of". I can't remove the "Category:" directly in the DISPLAYTITLE, otherwise it doesn't work. The screenshots of my DISPLAYTITLE (above): The problem (below): Thanks in advance. Darkrai18 (talk) 08:25, 10 October 2021 (UTC)
 * Upon investigation on my own wikis, the UrlShortener special page extension is conflicting with custom uses of DISPLAYTITLE. I couldn't tell you how to remedy this so they both work together, but if you can pitch the former you may be able to do a quick solve on this issue. --Raidarr (talk) 09:53, 10 October 2021 (UTC)
 * But concretely, what do I do? Darkrai18 (talk) 10:03, 10 October 2021 (UTC)
 * You either disable UrlShortener or put in a phabricator task to see if that behavior is deliberate. I'm not sure, it might be. Either way, that's the conflict I found. --Raidarr (talk) 10:42, 10 October 2021 (UTC)
 * I disabled urlshortener, but it didn't change anything. I didn't do anything else. --Darkrai18 (talk) 11:02, 10 October 2021 (UTC)

Request for feedback regarding enabling database compression

 * The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
 * There appears to be at least a rough consensus here in favour of enabling database compression on all wikis (though we should consider not all users may full understand what this means in technical terms; nevertheless, we should not presume that to be the case and should instead assume that they do), noting that database compression is already enabled on all or most the largest wikis hosted by Miraheze (in terms of database size). While this change would effectively neuter the ReplaceText extension, there is no consensus, as of yet, on removing or otherwise effectively disabling the ReplaceText extension, so SRE is advised to explore every potentially feasible alternative with regard to allowing the ReplaceText extension to be still be used by wikis, for users not familiar with MassEditRegex syntax. Dmehus (talk) 18:16, 17 October 2021 (UTC)
 * Update: SRE has already enabled database compression, but have done so without enabling compression on the current revision of the page, which means that, so far, ReplaceText has not been effectively neutered and can still be used. It would've been nice for SRE to wait for a Steward to close this discussion, but it also nice that they've found a solution that achieves their aims whilst also allows the ReplaceText extension to remain operable. Dmehus (talk) 18:30, 17 October 2021 (UTC)

Greetings Miraheze community, SRE is requesting your feedback and input on a proposed change:

While revising our strategy of backing up wiki databases, SRE discovered that compressing wiki databases (a method used by Wikipedia and which will not lead to any database corruption at all) would result in us being able to save database backups for longer and would allow us to save resources (database compression doesn't generally impact wiki performance/loading times). The only issue is that some extensions (namely ReplaceText) do not support database compression and would break. An alternative for the extension is MassEditRegex (note that though the extension says it was last updated 2 years ago, the documentation is misleading. Last update was a few days ago in May by the developer and SRE is working to make it compatible with 1.37 and seems to be nearly done) which offers many more features than ReplaceText and is compatible with database compression. However, even so, SRE is requesting your feedback about the proposed change.

While the affected extension has a replacement, we'd still like to hear what you think about this change and about any possible concern you may have. Please reply under this thread with your thoughts on the matter. Thank you! Agent Isai Talk to me! 16:39, 12 October 2021 (UTC)


 * If incompatible content can be replaced with equal or better with a minimum of work from the user side and there are otherwise only benefits, I think it would be prudent to do this as soon as possible. Honestly I think I assumed this was being done in the first place. --Raidarr (talk) 16:43, 12 October 2021 (UTC)


 * Is ReplaceText the only extension that would stop working? Bongo50 (talk) 18:09, 12 October 2021 (UTC)
 * That's currently known of. If knows of others that would be affected, I invite him to mention them or confirm that there should be no more trouble. --Raidarr (talk) 23:27, 12 October 2021 (UTC)
 * I don't really understand what these compression stuff means but it sounds good so i support. Anpang (talk) 00:55, 13 October 2021 (UTC)


 * I 100% this change, as it is better for the farm, and it’s users.   —［ <span style="font-weight:800; padding:0.25em 0.5em;border-radius:.35em;background-color:#d2527f;background:background-image: linear-gradient(45deg,#CF121F,#F83A0C,#F83A0C,#FF6347,#FFD228); background-image: -o-linear-gradient(45deg,#CF121F,#F83A0C,#F83A0C,#FF6347,#FFD228); background-image: -moz-linear-gradient(45deg,#CF121F,#F83A0C,#F83A0C,#FF6347,#FFD228); background-image: -webkit-linear-gradient(45deg,#CF121F,#F83A0C,#F83A0C,#FF6347,#FFD228); background-image: -ms-linear-gradient(45deg,#CF121F,#F83A0C,#F83A0C,#FF6347,#FFD228); background-image: -khtml-linear-gradient(45deg,#CF121F,#F83A0C,#F83A0C,#FF6347,#FFD228););color:rgba(255,255,255,1);text-shadow:0 1px 1px rgba(0, 0, 0, 0.2)">Bukkit  ］［  Talk  |  Contributions  |  Barnstars  22:11, 12 October 2021 (UTC)


 * ReplaceText is indispensable in wiki administration. --NimoStar (talk) 01:49, 13 October 2021 (UTC)
 * Hence why we linked the MassEditRegex extension. It does all the same functions as ReplaceText and offers even more features. Agent Isai  Talk to me! 01:54, 13 October 2021 (UTC)
 * Replace_Text has last version july 2021, MassEditRegex is from 2019. SRE refused before to add extensions which have been unmantained for two years. Besides, what is statistically the real performance impact of compression in load times and administrative tasks? I reckon that if it is compressed, it needs to uncompress - that must consume server side resources, necessarily. --NimoStar (talk) 01:57, 13 October 2021 (UTC)
 * It seems that the developer hasn't had time to update the MediaWiki.org documentation to reflect the updates but the update is being currently updated and is deployed across Miraheze (Special:ManageWiki/extensions -> Special pages -> Mass Edit via Regular Expressions). As for (de)compression and load times, it would not affect it at all. Agent Isai  Talk to me! 02:08, 13 October 2021 (UTC)


 * ReplaceText does its job really great and I use it almost every day. I haven't used MassRegEdit, but it doesn't seem actively maintained which worries me, and also don't know if have all characteristics as ReplaceText. Another strong point in favour of ReplaceText is that comes by default. And what about data integrity? Handling compressed databases could lead to easier data corruption. Have you evaluated to introduce data compression support in ReplaceText? 02:18, 13 October 2021 (UTC)
 * Please see the above comments. The extension is actively maintained and is even deployed here on Miraheze. Data integrity is no issue with compressed databases so don't worry about that, it's even used by Wikipedia (see their config here which means that they have tried it out and that there is no issue on their part that would prevent them from rolling it out. We have evaluated that and we believe it will even benefit you as we'll be able to better back up your wiki and keep backups for longer. As for evaluating using data compression in Replace Text, an upstream dev would need to introduce support for it. Agent Isai  Talk to me! 02:37, 13 October 2021 (UTC)


 * Conservation of resources takes priority over the inconvenience of having to switch to MassEditRegex from ReplaceText. Wikis should be given a head's up of at least two weeks (or whatever duration deemed reasonable) in advance before the transition to database compression. --SchizoidNightmares (talk) 03:56, 13 October 2021 (UTC)
 * MassEditRegex seems to have very comparable functionality to ReplaceText, and increasing data and backup retention time is always a plus in my opinion. I should note, though, that the last real update (excluding the automated translatewiki/libraryupgrader commits) to MassEditRegex was May 2021, not "a few days ago" as the original post states. That being said, the last updated date is not always a good metric for determining the state of an extension's maintenance, as many extensions do not require much maintenance to begin with. Joritochip (talk) 05:18, 13 October 2021 (UTC)
 * Will it be possible for individual wikis to have this change reversed after it has been made? Also, a couple of notes regarding MassEditRegex: 1) it is not bundled with MediaWiki core unlike ReplaceText making it less reliable, 2) please do not try to mislead people like paid PR people in for-profit organisations, you will only lose trust that way; the last actual code change to the extension happened on May, 3) the extension does not work at all on 1.37. Also, why is this a vote?
 * PS. I get why SRE wants this change but please do not proceed with this without providing alternatives to all affected features people are using. 14:39, 13 October 2021 (UTC)
 * Database decompression hasn't been tried out before but as it only compresses MediaWiki's text table using zlib, it shouldn't be too hard to do. Now, onto your questions. 1) I will note that sometimes bundling extensions causes slower security fixes 2) I apologize for the incorrect statement. This was not done on purpose to mislead people but instead due to an oversight on my part for not fully checking the commit history and seeing that automated i18n changes were done. Indeed, the last update was done in May. 3) SRE is working to make MassEditRegex MediaWiki 1.37 compatible and seems to nearly be done in porting it over. As for the votes, I don't know why people started voting as this thread was made only for feedback and not as a vote. Agent Isai  Talk to me! 15:34, 13 October 2021 (UTC)
 * We have now updated the extension so it works with 1.37 :) ~ RhinosF1 - (chat)· acc· c -  18:59, 13 October 2021 (UTC)
 * Belated thanks, Agent and Rhinos. :) 13:29, 16 October 2021 (UTC)


 * . It looks like it would be easy to switch to the new extension to solve the lack of support from the old extension. The rest are merely upgrades in my opinion. Matthew Cenance (talk) 15:27, 13 October 2021 (UTC)
 * I've read the documentation for MassEditRegex and Replace Text, and I have some concerns about various features that MassEditRegex seems to lack:
 * Replace Text has the feature of replacing text in page titles (as in moving those pages), which MassEditRegex does not seem to have. Is there any easy-to-use replacement for this?
 * When using Replace Text, after searching for the text you get a list of checkboxes so that you can unselect pages where you do not want text to be replaced. MassEditRegex does not seem to have this feature.
 * According to MassEditRegex's documentation in the "Known issues" section, it has the issue of not being able to replace text only in certain namespaces. Replace Text does not have issues with specifying by namespace, and can even target multiple namespaces.
 * @Agent Isai
 * Considering these issues with MassEditRegex, I don't think the loss of Replace Text is okay, unless the features mentioned here can be replicated in an easy-to-use fashion. K599 (talk) 23:39, 14 October 2021 (UTC)
 * Apologies for not seeing your reply, your ping didn't show in my mentions. 1) There does not seem to be. 2) MassEditRegex allows you to specify what pages you want it to edit and what pages you don't want it to edit in it's main page. 3) It seems this only happens when using the page prefix option but I am unaware of whether this issue is still present or not. If you wish, I can forward your concern regarding the bug to SRE who has worked recently on the extension to ensure comparability with MediaWiki 1.37. Overall, while MassEditRegex may not be a one-stop replacement for ReplaceText (though they do do similar jobs and MassEditRegex supports regular expressions), we hope that the proposed change allows us to better server you as it allows us to better secure your wikis with long-term backups now that disk usage is slashed in half and better utilize resources now that disk space is freed up. While it may feel like a bit of a tradeoff, we want users to know and to give their opinions on it, especially those users who actually do utilize ReplaceText. We do hope to be able to possibly provide more alternatives in the future or perhaps be able to tweak MassEditRegex to support title renamings. Agent Isai  Talk to me! 21:28, 15 October 2021 (UTC)
 * @Agent Isai For #2, if I understand the documentation correctly, MassEditRegex only allows you to specify pages before the search, while Replace Text allows you to choose which replacements you want after the search. Therefore, MassEditRegex would require you to know what the specific pages you want to target are beforehand, while Replace Text allows you to search and get a list of replacements that you can then deselect what you want, so to me, Replace Text is more convenient than MassEditRegex in this case.
 * If the only benefit to this is long-term backups, then I don't think this is worth losing Replace Text, because the backups that I believe would be important would be backups of the page contents and edit history of wikis, and such backups of public wikis can simply be uploaded to Internet Archive, which they already are, unless I'm mistaken on any part of this. K599 (talk) 01:31, 16 October 2021 (UTC)
 * I'd like everyone in this discussion to at least be aware of the issues I've pointed out with MassEditRegex, and why it isn't really a good replacement for Replace Text, so I'm going to ping everyone here.
 * @Raidarr@Anpang@Bukkit@SchizoidNightmares@Joritochip@Matthew Cenance K599 (talk) 20:22, 15 October 2021 (UTC)
 * Perhaps could you not ping everyone?  —［ <span style="font-weight:800; padding:0.25em 0.5em;border-radius:.35em;background-color:#d2527f;background:background-image: linear-gradient(45deg,#CF121F,#F83A0C,#F83A0C,#FF6347,#FFD228); background-image: -o-linear-gradient(45deg,#CF121F,#F83A0C,#F83A0C,#FF6347,#FFD228); background-image: -moz-linear-gradient(45deg,#CF121F,#F83A0C,#F83A0C,#FF6347,#FFD228); background-image: -webkit-linear-gradient(45deg,#CF121F,#F83A0C,#F83A0C,#FF6347,#FFD228); background-image: -ms-linear-gradient(45deg,#CF121F,#F83A0C,#F83A0C,#FF6347,#FFD228); background-image: -khtml-linear-gradient(45deg,#CF121F,#F83A0C,#F83A0C,#FF6347,#FFD228););color:rgba(255,255,255,1);text-shadow:0 1px 1px rgba(0, 0, 0, 0.2)">Bukkit  ］［ Talk  |  Contributions  |  Barnstars  21:25, 15 October 2021 (UTC)
 * Well, I prefer that people are aware of issues with this, and I know that people aren't going to look at this discussion again unless someone tells them about it. K599 (talk) 01:09, 16 October 2021 (UTC)
 * You just pinged all the people Anpang   Talk  01:05, 16 October 2021 (UTC)


 * Question: Is it at all possible to make regular use of compressOld.php to only compress old revisions? This way the current revisions could remain uncompressed and accessible to ReplaceText? -- Void  Whispers 01:45, 16 October 2021 (UTC)
 * That is something we could consider to achieve what we require while causing minimal disruption to wiki users. John (talk) 11:53, 16 October 2021 (UTC)
 * Given the above post highlighting flaws in comparison to ReplaceText (which I'm frankly not familiar with), I think this is very much worth exploring. Given the utility of these changes being mainly sold for backups it's especially compelling, although I'd assume there's some loss given compression on live wikis saves a fair bit of space as well? The other thought, perhaps naive, would be changing ReplaceText to have utility on compressed data. I'd assume this is at least difficult or I'd expect it would have already been considered. --Raidarr (talk) 12:26, 16 October 2021 (UTC)


 * The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section

We need a way to report wikis and users
Until now, I didn't realize that the only obstacle to Miraheze's success was that you still need to request wikis. Even though the process is almost automatic, thanks to the CreateWiki extension, wikis still have to be approved. That all changed when I ran into difficulties requesting a wiki because it was assumed to be a duplicate. That's when I realized something. Fandom, the most popular wikifarm, has fully automatic wiki creation, but also a way to report wikis that violate their policies. If Miraheze had a way to report policy-violating wikis, it would solve the biggest problem of automatic wiki creation: the potential for policy-violating wikis to be created. There is a wiki for the Counter-Vandalism Team, at cvt.miraheze.org, but the only problem is that it's private. We need a page for user to report policy-violating wikis. It's not hard to setup. I believe it will help the growth and moderation of Miraheze. Tali64³ (talk) 23:21, 13 October 2021 (UTC)


 * The page is called the Stewards' noticeboard where you may bring violating wikis and even users to steward attention. Reports may also be done via talk page to the appropriate users and with even more discretion, via discord or IRC to appropriate users. Splitting off the process further is not necessary. --Raidarr (talk) 23:55, 13 October 2021 (UTC)
 * But what would it be like to report wikis? Within the wiki itself? That wouldn't be a good idea if that was it. Yellowass.png (talk) 00:29, 14 October 2021 (UTC)
 * cvt.miraheze.org is a private wiki meant for members of the global Counter Vandalism Team. To report problematic users and wikis, users are encouraged to report it at Stewards' noticeboard or on Discord/IRC on our CVT channel. That being said, one of my goals is to create better documentation which describes how to report vandalism and issues. Agent Isai  Talk to me! 00:36, 14 October 2021 (UTC)
 * Raidarr is correct. Wikis and users can be reported to Stewards for violations of various global policies or if there is other evidence of abuse. Please ensure your reports are both concise, but also sufficiently detailed and supported by evidence (i.e., diffs). Dmehus (talk) 03:17, 14 October 2021 (UTC)

Broken chart
The sysadmins chart in Tech:Timelines is broken 02:15, 14 October 2021 (UTC)


 * Fixed with a bit of wikitext wizardry. -- Void  Whispers 01:46, 16 October 2021 (UTC)
 * Ok! :D Anpang

Talk 12:24, 16 October 2021 (UTC)

Wiki.
i only get one more chance at creating a wiki, per Dmehus (Doug). What is a good topic? Thanks. SperosDurrell (talk) 16:16, 14 October 2021 (UTC)


 * I think you should save the only chance for later, but I'm too late now oops you already requested a wiki but it's already declined by Agent so ok. Anpang   Talk  00:39, 15 October 2021 (UTC)
 * i resubmitted it. SperosDurrell (talk) 01:11, 15 October 2021 (UTC)
 * You have to know the topic of your wiki, what you are going to post, edit, and so on. Yellowass.png (talk) 01:19, 15 October 2021 (UTC)
 * i know. SperosDurrell (talk) 01:44, 15 October 2021 (UTC)
 * ty 4 checking it out. SperosDurrell (talk) 01:45, 15 October 2021 (UTC)

Scribunto isn't in the extension list
In the extension list, there's no scribunto, just capiunto. Just trying to import the infobox template 05:27, 15 October 2021 (UTC)
 * I have infobox on the wiki where I manage. Does not need Scrinbunto, or Scrinbunto is installed automatically. You need to put MediaWiki:Common.css and MediaWiki:Common.js on your wiki and modules like : Module:Yesno and Module:Infobox and so on. Yellowass.png (talk) 20:37, 15 October 2021 (UTC)
 * Ah ok, thanks. Anpang   Talk  01:07, 16 October 2021 (UTC)

Request for feedback on disabling Citoid and Collection
Hello Miraheze community,

SRE is soliciting your feedback on the disabling of the Citoid and Collection extensions. The main issue with them is that they require 2 extra servers just for them to host RESTBase. After reviewing usage data, it was found that less than 10 users a day use both of these extensions combined out of the thousands of active daily Miraheze users. In fact, since 00:00UTC of today, 16 October, only 1 user has used Citoid and no one has used Collection. By disabling these 2 extensions, we would be able to better use those now freed up resources by repurposing them and using them in other areas (perhaps another MediaWiki server to decrease loading time, etc.).

For the reasons outlined above, SRE wishes to know what you think about disabling Citoid and Collection. We desire to know what users (especially those who use the extension on their wiki) think about the proposed change. Please let us know about any concern you have about this proposed change. This is not a vote! While you may let us know if you support or oppose this change, please do not convert this into a full-blown vote and use the Support/Oppose templates. Thank you! Agent Isai Talk to me! 19:11, 16 October 2021 (UTC)


 * Citoid is cool and I use it on the wiki where I manage (or used). You would just put a business on EditorVisual to name sites (and even give an example). Wikipedia also uses this extension. If you spend resources on the server, and I use little, then it won't be much needed for me YellowFrogger (✉ Talk  ✐ Edits ) 19:29, 16 October 2021 (UTC)
 * The cite tool in VisualEditor will not go. Just automatic citations from URLs and ISBNs. ~ RhinosF1 - (chat)· acc· c -  21:38, 16 October 2021 (UTC)
 * Hrm? How's that? Quite a few wikis use that feature, as far as I'm aware. Cyberpower678 operates an InternetArchiveBot, as I recall, that does just that thing. Not sure how often it runs, or if it runs more frequently on only a few wikis, but they should be consulted here, together with those local wiki communities. (This is in regards to Citoid. The Collection extension is probably not as widely used anymore in terms of its ability to create PDF books of wikis, but the fact it too shows as apparently under-utilized because its very nature suggests it does not need to be run that frequently.) As well, I also question the argument for removing extensions which are so infrequently used. If they're so infrequently used, they shouldn't be using too many resources. My concern here is that we might be trying to replace one apparent resource hog, RESTbase, with another resource hog, ElasticSearch, with little discernible benefit. Dmehus (talk) 00:00, 17 October 2021 (UTC)
 * Cyberpower678 has a bot that does stuff with Citations. It does not use Citoid in any way which is a service to automatically generate them from a URL or ISBN. These extensions are behind the services system & restbase so requires 2 VMs to run everything that need resources allocated to them. If there was usage and people indicated they needed it, I'd do everything I can to consider if it's worth it. ~ RhinosF1 - (chat)· acc· c -  07:38, 17 October 2021 (UTC)
 * You've identified a very compelling potential use case, of which I was not aware. I had thought Citoid was a completely behind-the-scenes extension; I did not realize it was directly interfacing with end users in terms of semi-automated lookups of bibliographic or publication details. This is definitely something I'd be very interested in for a future wiki; no idea why we're only looking at existing wikis. I have no issues with reallocating system resources, but surely we can find a bunch of our unused extensions to remove in order to save this one. Dmehus (talk) 15:35, 17 October 2021 (UTC)
 * The main trick here is that I don't believe other extensions generally require dedicated server space to use (SRE can correct me if I'm wrong), resulting in a unique draw from these extensions that removing any number of very small but mundane and mostly unused extensions would not match. But in all I think cutting to one server and seeing how it works would be a good thing to try if practical. --Raidarr (talk) 18:21, 17 October 2021 (UTC)
 * Yes, I get the rationale, but I'm not convinced of either the need nor its likelihood to be effective. I don't think SRE has articulated a clear case for what they're trying to achieve here. I would also note that John has let me know that this has not been initiated by the SRE Infrastructure team as part of a larger infrastructure needs assessment, so I'm just struggling to see what the benefit would be here in order to weigh it against the costs (and not just on recent use, but likely use that is core to Miraheze's mission). It strikes me that someone wanting to create a bibliographic database wiki, relying on semi-automated data entry population tools like Citoid would be core to Miraheze's mission. Dmehus (talk) 18:39, 17 October 2021 (UTC)
 * https://en.wikipedia.org/w/index.php?title=Wikipedia:CITEGENERATORS has various tools that can be used. ~ RhinosF1 - (chat)· acc· c -  21:30, 17 October 2021 (UTC)
 * A lot of those are based on, or use the, Citoid, extension. I'd rather see some other alternatives explored, which could including consolidating the two RESTbase VMs into one, or making some other modifications to its allocated resources. These are just a couple ideas, but I'm not really convinced here this is the only option. For example, look recently with the related ReplaceText extension, SRE was able to enable database compression on all wikis, on all but the current revision, to wiki pages, and this allowed the ReplaceText extension to still be used. I see a lot more potential use cases to Citoid than I do ReplaceText, as ReplaceText has an alternative extension in MassEditRegex&mdash;and we kept ReplaceText. Dmehus (talk) 21:40, 17 October 2021 (UTC)
 * Only 2 on there use Citoid. I'm seeing a lot of pushback but very little examples of actual use. ~ RhinosF1 - (chat)· acc· c -  07:03, 18 October 2021 (UTC)
 * I'm not satisfied with the articulated rationale for removing/disabling the Citoid extension in particular, or the potential impacts on other extensions. I'm not familiar with the other extension, so have no comment there, but I also question the data used to propose remove the Citoid extension. I'm also not really satisfied that other avenues to free up server resources were explored. Why does it seem to default to a keep/remove this or that extension? Dmehus (talk) 19:33, 16 October 2021 (UTC)
 * To the best of my knowledge, the data was collected by analyzing nginx logs and also usage logs on services3 and services4 (the 2 servers provisioned to host RESTBase on). Something that prompted this conversation was the issue we faced with some automatic processes not being done, one of which was the automatic updating a configuration file that enabled/disabled RESTBase on the wikis. During the time that the configuration was not being updated, thre was not a single user complaint in regards to this which led us to look into usage data on these extensions and caused us to find that they have very low usage. The reason it may seem that in this case it boils down to "remove this or that" is that these extensions require their own dedicated servers. If they didn't, then we'd have no issue with these extensions but they do and their usage doesn't justify the need for 2 extra servers which do nearly nothing other than serving a few requests per day (if any). Agent Isai  Talk to me! 20:15, 16 October 2021 (UTC)
 * It's not default. It's come to our attention that the usage is virtually none. ~ RhinosF1 - (chat)· acc· c -  21:11, 16 October 2021 (UTC)
 * I'd find no real use but real resource consumption to be a pretty simple equation, honestly. It sounds almost practical for SRE to find and directly poke the ones who do use it personally. Other avenues for resource saving I'm sure can be/have been explored, but essentially unused features can surely be one of them in the meantime. --Raidarr (talk) 22:17, 16 October 2021 (UTC)
 * as the only user in the about 14 hour period of logs we checked today that wasn't broken JS imported from Wikipedia that doesn't actually work or me. ~ RhinosF1 - (chat)· acc· c -  22:21, 16 October 2021 (UTC)
 * Not satisfied. Citoid seems extremely helpful to communities. I, personally, don't use it on my wiki, but sometimes on other users wiki. Bongo Cat (talk) 23:26, 16 October 2021 (UTC)
 * Could you note some of these communities? --Raidarr (talk) 00:15, 17 October 2021 (UTC)
 * For what it's worth, I've asked Cyberpower678, who operates the InternetArchiveBot, to provide input here, which will likely identify some of those communities. Dmehus (talk) 00:19, 17 October 2021 (UTC)
 * As raidarr said, can you please name them? We're not seeing usage of it. ~ RhinosF1 - (chat)· acc· c -  07:39, 17 October 2021 (UTC)
 * I have been asked about the 14 hour data collection period. As such, I will provide usage stats for as long as we retain them for... over a 13 day period the follow are HTTP code results:
 * 200: 150
 * 400: 9
 * 404: 440,832
 * 502: 8
 * This averages out to 11 successful usages per day and ~34,000 unsuccessful usages per day. John (talk) 14:29, 17 October 2021 (UTC)
 * We have now disabled collection. We're allowing more time for feedback regarding Citoid. Unfortunately, unless we see an actual use case, we would still rather see it removed until a future use case arrives, the services system is fully puppetised so would be fairly easy to restore to our mediawiki cluster if it had use. ~ RhinosF1 - (chat)· acc· c -  07:05, 18 October 2021 (UTC)

Interwiki table
I would like to request to add the prefix 'w', the url https://zh.wikipedia.org/wiki/$1, forward = yes, and transclude = yes to the interwiki table of XComhghall Wiki. Thank you very much. — XComhghall (talk) 20:16, 16 October 2021 (UTC)


 * XComhghall, ✅ per your request. Note that  now overrides the global configuration for the prefix, but you could request   be added as an interlanguage prefix for , if you wished, so you could still use   on your wiki. Dmehus (talk) 22:29, 16 October 2021 (UTC)
 * Excuse me. So how does an interlanguage prefix work?  or just  ? Thank you! — XComhghall (talk) 22:57, 16 October 2021 (UTC)
 * XComhghall, I believe you can use, but likely will run into issues in terms of determining which interwiki prefix it's for. So, for that reason, I strongly recommend using the former. Hope that helps. Dmehus (talk) 23:54, 16 October 2021 (UTC)
 * Thank you so much! I think I am fine for now. I may add an interwiki prefix of  to https://zh.wikipedia.org/wiki/$1 in the future. — XComhghall (talk) 00:47, 17 October 2021 (UTC)
 * No problem. :) Dmehus (talk) 15:36, 17 October 2021 (UTC)

How to make interlink.
I want to make interlink for Japanese wikipedia. But I do not know to make interlink. If you know that.I want to your teach. Thank you to reading. Key-Power (talk) 13:24, 17 October 2021 (UTC)
 * , ask any of the Interwiki administrators on Discord or just make the request here. Request in the format:
 * Wiki URL:
 * Requested prefix:
 * Transclude:
 * Forward:
 * Courtesy pings to and . --Magogre (talk)  13:37, 17 October 2021 (UTC)
 * Did you mean link to Japanese Wikipedia? You should use this to link to this Wikipedia: " Example " YellowFrogger (✉ Talk  ✐ Edits </b>)</b> 23:31, 17 October 2021 (UTC)