Community noticeboard

Request for feedback on disabling Citoid and Collection

 * The following discussion is an archived discussion. Please do not modify it.
 * After a full week of this thread being opened, it appears that no one has raised any objections to Collection being removed thus it appears that there is no opposition to SRE to remove Collection. As for Citoid, one of the strongest arguments in opposition to this raised concerns about the possibility of future use of the extension saying that it would not be fair for those who may want to use Miraheze in the future. A few alternatives were demonstrated to the user by SRE which do similar jobs. Additionally, concern was raised in regards to the statistics displayed by SRE to demonstrate that Citoid is not used very much. The statistics were called by at least 2 users to be lacking however, due to limitations, the maximum amount of available statistics of 13 days were released to the community for usage statistics. One other user raised a serious concern saying that they were worried about it being removed but later clarified on Discord that they confused it for the Cite extension. The only other comment on this thread said that it was a cool extension. No further objection was raised on Discord or any other platform even after a mass ping on Discord and a thread being made too to address any concern. Some users on Discord signaled that they found it ok to remove it and as it appears that more are in favor of removal than against. After carefully weighing the singular strong oppose versus the general lack of opposition, and the support that was given to this, it appears that there is no strong opposition to removing Citoid and Collection and that SRE may remove it.  Agent Isai  Talk to me! 20:07, 27 October 2021 (UTC)

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)
 * honestly, I only use this when i'm on mobile - it's a good extension, and I like it, and would be more in favour of allocating fewer resources than getting rid of it entirely, however I still have to do a lot of editing to get citations the way I want. is there a planned replacement/known similar extension that does this? or will all citations have to be manually done after this? Amazingakita (talk) 16:19, 21 October 2021 (UTC)
 * Hi, There's some tools linked at https://en.wikipedia.org/w/index.php?title=Wikipedia:CITEGENERATORS that you may want to evaluate for usefulness. Please let us know what you expect and how you use Citoid (That's the automatic tab only) so we can work on advising you best. ~ RhinosF1 - (chat)· acc· c -  16:22, 21 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)
 * ''The above discussion is preserved as an archive. Please do not modify it.

Looking for documentation for the "Whitelist Read ($wmgWhitelistRead)" setting
I am considering setting a small number of pages on a private wiki to be pages anyone may view. I see the setting "Whitelist Read ($wmgWhitelistRead)" on the Permissions tab of "Manage this wiki's additional settings" that appears to be what I want... but I don't see any documentation on how to list the pages.

Is this a field that I have to enter pages into one at a time, or do I enter a string listing multiple pages? If the latter, what is the syntax and maximum length of the string?

Can I list files to be displayed on the pages that I want to make public? If yes, do I specify them as "file:foo.jpg", "media:foo.jpg", or "foo.jpg", or something else?

What is the maximum number of entries that I can add to this field? Robkelk (talk) 23:42, 25 October 2021 (UTC)


 * You should get a dropdown with a list of pages according to our config. You can insert as many as you like. The limit will be as much as can fit in the DB without running out of room in the settings column which is a very big number. ~ RhinosF1 - (chat)· acc· c -  07:57, 26 October 2021 (UTC)

How about a incubator wiki for Miraheze?
Don't be confused with Incubator Plus 2.0 Wiki.

I am thinking of an incubator wiki design to avoid "trash and bad" wikis (means not suit our standards) to reduce the burden of wiki creators. Since "incubator" was taken, I will use "nest" as the domain link, since nests are the place eggs are. The request wiki task number is 21138. Emojiwiki (talk) 10:12, 26 October 2021 (UTC)


 * About privs: Meta Wiki wiki creators will get admin privs whenever possible (this should be done via config or extension, or bot if this is impossible), and be revoked when his/her wiki creator priv revoked.
 * About test wiki structure: The wiki's page will use this structure:
 * Wiki root page:
 * For example: Main page of  should be:
 * Note that MediaWiki messages should be placed in:, but they won't be applyed yet (except main page setting, we will apply it by templating)
 * Wiki extra settings in the wiki's : , written in PHP inside syntax highlighting Wikitext blocks, or written as a list contains all requirements
 * Restrictions:
 * Translations between Chinese Simplified and Tranditional will be disabled, but seperated and created wikis can enable them themself.
 * Emojiwiki (talk) 10:30, 26 October 2021 (UTC)
 * If I understand this correctly, what you suggest is too big to just make a wiki request for, and would be more in line with the Request for Comment process since it would be changing wiki creation policy. But tbh I don't entirely understand what this is for and why. --Raidarr (talk) 12:15, 26 October 2021 (UTC)
 * About why:
 * Currently the create wiki request is slow, I think a reason is there are a lot of requests.
 * Changing the create wiki policy:
 * This does not require at the start. This will be a test project until its scripts (needs a lot of scripts to manage eggs) and contributing environment (including policy and guidelines)
 * Emojiwiki (talk) 23:06, 29 October 2021 (UTC)
 * Personally, I feel that wiki request handling time is very good, especially in comparison to a few years ago and even a few months ago too. A few years ago when wiki requests took weeks or even months to do, I would have totally supported this idea, even advocated for it, but right now it feels like we don't exactly need an Incubator wiki. While checking the Farmer log, I noticed that very rarely does a wiki request go more than 12 hours without it being handled, in fact, most are handled in 6 hours or less with many handled in less than 3 hours, some even within minutes to an hour! If a user is impatient about having to wait a few hours for their wiki to be created then I think they'll totally get frustrated with how long it takes to actually build up a wiki. Agent Isai  Talk to me! 23:22, 29 October 2021 (UTC)
 * Even though I am misunderstanding the timing of creating a wiki, there are also two major goals:
 * Decine bad wiki requests clearly
 * Nowadays, wiki creators can only guess what the wiki requester wants and will he follow the policy. By adding a nest wiki, they can clearly look inside the box and approve or decline clearly.
 * A place for waking up wikis
 * Sometimes, when a wiki is hibernated and nearly to be deleted, someone wants to continue it. Our hibernate policy allows us to do so directly, but that is not a good choice. The community needs to be rebuilt, and a direct continuation of the old hibernated wiki may cause another hibernate. The nest wiki can be a good place to do so.
 * BTW: Request comment updated, go to the request queue page to know more. Emojiwiki (talk) 23:46, 29 October 2021 (UTC)
 * Again, please note that this idea cannot be approved in the request queue or by any individual. This discussion must be held somewhere else. Since it is so expansive, it should be done through the Requests for Comment process with a full description of what you intend it to do so the community can decide to use it. --Raidarr (talk) 08:37, 30 October 2021 (UTC)
 * If this to move forward, it needs a formal RfC. This nor a wiki request is not the venue for such a major change. This thread may continue to facilitate drafting such an RfC but I advise caution as I think it is extremely unlikely to succeed and would need significant technical work which would in any case take quite a while. ~ RhinosF1 - (chat)· acc· c -  08:50, 30 October 2021 (UTC)

Interwiki table
I would like to request to in the interwiki table of XComhghall Wiki. Thank you very much. — XComhghall (talk) 15:23, 26 October 2021 (UTC)
 * Set  of the prefixes   and   to  ,
 * Add the prefixes  and   to , and
 * Add the prefix  to


 * This is ✅ at this time Ugochimobi (talk) 20:32, 27 October 2021 (UTC)
 * Could you please
 * Add the prefix  to , and
 * Add the prefix  to  ?
 * Thank you very much. — XComhghall (talk) 19:36, 28 October 2021 (UTC)

Reference Tooltips, EditTop Gadgets, Wikiplus
I would like to add the Reference Tooltips and EditTop gadgets to my wiki, XComhghall Wiki. But Reference Tooltips requires the dependencies mediawiki.cookie and jquery.client, and MW: Extension: Gadgets. And EditTop requires the dependencies user.options and mediawiki.util. What can I do? Could you please help me?

Regarding Wikiplus, here is a previous conversation on the community noticeboard: https://meta.miraheze.org/w/index.php?title=Community_noticeboard&oldid=208443#EditTop_Gadget,_and_Wikiplus.

Wikiplus is working fine on Wikipedia. I just imported it to my global.js page. This is what I did on both Wikipedia and Miraheze. It was working fine on Miraheze in August, but currently it is not working on any Miraheze wikis, even my own wiki, where I am the bureaucrat, sysop, autoconfirmed, and confirmed.

It is supposed to show an edit window above the section edited, and can be expanded and moved. But currently on Miraheze, it shows a shrunk edit box at the bottom of the page, without background color, border, design, etc., and cannot be moved.

What should I do? Could you please help me?

Thank you very much. — XComhghall (talk) 16:01, 26 October 2021 (UTC)


 * The two gadgets you want can be handled by yourself, They can be installed on your wiki as a gadget too, plus, the libraries you mentions are what are already on MediaWiki and as such, you don't need to install them separately. You only need to enable the mw:Extension:Gadgets on your wiki.


 * For the latter, you should confirm if Wikiplus is currently not broken on English Wikipedia, if it is then it's not our fault, it's coming from upstream. After looking through the codes, I doubt if it will work on here when it's not locally installed though, tbh. Ugochimobi (talk) 20:41, 27 October 2021 (UTC)
 * I just confirmed that Wikiplus works fine on the English and Chinese Wikipedias, Wikisources, and Wikinews. It used to work fine on Miraheze too. — XComhghall (talk) 19:34, 28 October 2021 (UTC)

what does "The database name may not contain non-alphanumeric characters." mean when i request a miraheze
same as title.

i would show a pic but i cant for some reason ZX-EXE (talk) 18:35, 28 October 2021 (UTC)


 * This may be because you entered something like 'yourwikiname.miraheze.org' instead of 'yourwikiname' when putting in a subdomain. Only offer the subdomain name, miraheze.org is not required. If this isn't the case, please mention what you tried for the wiki's subdomain since this is what it means by database name. --Raidarr (talk) 18:50, 28 October 2021 (UTC)
 * A request was made, so it appears this issue was resolved. --Raidarr (talk) 19:10, 28 October 2021 (UTC)

1. Gadgets, and 2. Template Styles and Content Model
I have a few gadgets set as default in my wiki's MediaWiki: Gadgets-definition:. If I do not enable MW: Extension: Gadgets, will the default gadgets still work fine, or will they be disabled along with the Gadget extension?

A template I created with MW: Extension: TemplateStyles is not working. Its styles.css page does not seem to be in the Sanitized CSS content model. How can I enable ? What can I do?

Thank you very much! — XComhghall (talk) 17:58, 29 October 2021 (UTC)
 * , hello. You need to enable the TemplateStyles extension (enable on your wiki) and change the content model of Template:Block/styles.css into sanitized CSS (use Special:ChangeContentModel on your wiki to do that). The template should work properly, then. Ma͡gogre (talk) 18:54, 29 October 2021 (UTC)

Ask a question to an administrator
Hi, To which active administrator could I ask a question (or more precisely, request permission)? Dmehus is not active at all, neither on Miraheze nor on Discord. Do you have someone to advise me? Thanks a lot. Darkrai18 (talk) 14:51, 31 October 2021 (UTC)
 * Hello, you can ask genuine questions and request permissions at AN. Though you can also request on the talk page of a recently active administrators, I'd recommend you to use AN. --Magogre (talk) 15:02, 31 October 2021 (UTC)
 * Hello, if this is an extension of the question posted here, the most appropriate place is the Stewards' noticeboard so any Steward may easily find it and/or so a knowledgeable enough community member can advise you. If it is another inquiry I'd need to know what it is as it may go to another place. Dmehus is active in sprees and engages in order of priority; I want to say he'd likely address your concern within a few days (just one is not enough in most cases I'm afraid). It's also worth noting he has distinctly less activity on Discord as a platform, and if you wish to reach him by chat then IRC is more reliable (relayed via #miraheze-relay and related channels on Discord). For a general Steward inquiry though, the given noticeboard is preferable. The location posted above (AN) is if you request something from the local administrators on Meta. --Raidarr (talk) 15:07, 31 October 2021 (UTC)
 * Followup; Dmehus is available today and has replied to the inquiry I referenced on his talk page. --Raidarr (talk) 15:50, 31 October 2021 (UTC)

Problem with duplicate wikis
Recently, I noticed that there are many duplicate wikis on Miraheze. While wiki requests that seem similar to existing wikis are likely to be declined, already existing duplicate wikis and wikis with similar topics still exist. This is a problem that needs to be corrected. As quoted on Fandom's help page about duplicate wikis: "Where multiple wikis on the same topic exist, however, fans split their efforts and compete with each other for readers, editors and authority. The duplicate content they create is penalized by search engines such as Google, especially when a new wiki copies pages of an existing wiki. As a result, both wikis will appear lower in search results, receive fewer visitors and attract fewer community members." So, if duplicate wikis were merged with the original wikis, they would rank higher in search results and thus attract more contributors. We need to find and merge these duplicate communities, so that one wiki can move forward. I have several wikis that could be considered duplicates. I'm merging these with the original wikis.

Proposed merging process

 * 1) A request to merge is presented to the founder or active bureaucrats and admins on a wiki.
 * 2) *If there are no active bureaucrats and admins, go ahead to step 3.
 * 3) *If there is no response in a week, go ahead and start moving content.
 * 4) If the request is denied, the wiki stays separate.
 * 5) If the request is accepted, the community of the wiki to be merged votes on whether their wiki should be merged into the other wiki.
 * 6) If at least a 2/3 majority of the community of the wiki to be merged votes in favor of the merger, the wiki's content would be transferred to the wiki that receives the merge. Voting must remain open for a week before the results can be considered valid.
 * 7) The wiki to be merged is closed and deleted, and its URL is redirected to the wiki that receives the merge.

List of duplicate wikis
These are some of the wikis that are duplicates of others. These should be merged first.
 * Duplicates of Mirapedia (no notability guidelines encyclopedia):
 * Allpedia
 * Anypedia
 * Duplicates of Good Software Wiki (good software):
 * Great, Amazing and Useful Software Wiki (Focuses on useful software, which is usually good.)
 * Duplicates of Windopedia (wiki about Windows, the operating system by Microsoft):
 * Everything Windows Official Wiki
 * Duplicates of Free Editing Wiki (anything goes wiki)
 * Anything Goes Wiki

Wikis with overlapping topic and scope
These are the wikis with overlapping topic and scope. Their topics are not related enough to categorize them as duplicates, but they overlap in scope.
 * Trollpasta/Bad Creepypasta Wikis:
 * Trollpasta Wiki (primarily about trollpastas, but also has several thousand bad creepypastas. Famous examples of bad creepypastas may be kept, but others should be moved to Bad Creepypasta Wiki)
 * Bad Creepypasta Wiki (primarily about bad creepypastas, but also has a number of trollpastas. Famous examples of trollpastas may be kept, but others should be moved to Trollpasta Wiki)
 * Reading/Writing Stories:
 * Stories Wiki (This is a wiki of mine in which users can read and write stories. I've banned fanfiction to prevent overlap with any fanfiction wikis. I can't think of anything that needs to be changed, but there may be one or two.)
 * Short Stories & Prompts (This wiki focuses on stories and writing prompts, while Stories Wiki just focuses on stories. I've already contacted the founder of this wiki about merging this wiki with Stories Wiki, and we ended up coming on an agreement where we could mirror each other's content. My plan for this wiki is to make it about writing prompts only and move the stories on Stories Wiki.)
 * Stories about an existing character in a franchise (fanfiction):
 * Fanfiction Wiki (Fanworks) (Primarily about writing fanfiction and chatting about it.)
 * My Fan Fiction (Focuses solely on fanfiction. I think Fanworks should be rebranded to "Fanfiction Wiki" or something similar, and this wiki should be merged with that one.

If you can think of any other topics or other duplicate wikis with already existing topics, please post them! Tali64³ (talk) 18:50, 2 November 2021 (UTC)

Updates
This process, I believe, will stop most instances of abuse of merging. Tali64³ (talk) 22:35, 2 November 2021 (UTC)
 * I've been informed that duplicate wikis actually aren't against the Content Policy. Still, you should merge them with other wikis to help the communities. That's why I propose this process to merging wikis:
 * A request to merge is presented to the founder or active bureaucrats and admins.
 * If the request is accepted, the community of the wiki to be merged votes on whether their wiki should be merged into the other wiki.
 * If at least a 2/3 majority of the community of the wiki to be merged votes in favor of the merger, the wiki's content would be transferred to the wiki that receives the merge. Voting must remain open for a week before the vote can be considered valid.
 * The wiki to be merged is closed and deleted, and its URL is redirected to the wiki that receives the merge.
 * While I don't have specific links and am working off the top of my head, I know there are multiple wikis for aggregate worldbuilding (putting any kind of worldbuilding stuff in one place), creepypastas, and 'do whatever' types that may be found even through the Gazetteer of wikis. From a policy perspective however, an overlapping or duplicate-ish premise isn't strictly against Content Policy; its most relevant clause is:
 * "An example of hinderance caused to other wikis is a direct fork of another Miraheze wiki where little to no attempts have been made to mediate situations on the existing wiki or existing community. If mediation has been attempted and failed, contact a steward who will be able to support the community through any follow up processes deemed necessary including but not limited to acceptance of a fork wiki as an exemption to this clause. "
 * In the generic wiki responses for approval through the request wiki function, one specific statement is provided: "Please be advised this approval does not preclude other wikis from being approved and created that share this topic, provided they aren't 95-100% content forks of your wiki." I do think up to 95% is exceedingly generous and maybe should be reduced since even 3/4ths identical is enough to invoke the condition you describe, and is enough to substantively be a direct fork. However I think it's worth distinguishing between overlapping premise and what these clauses talk about (word for word page lifting and identical scopes); not much action may be taken if the respective wikis you link do go their own way managerially and have somewhat distinctive content of their own, even if I agree they fill essentially the same niche and in my opinion a much too broad one. Either way seeing them come together to actually collaborate in community building would be welcome, even if Miraheze deliberately tries to avoid forcing wikis together the way fandom does. --Raidarr (talk) 19:55, 2 November 2021 (UTC)
 * I respect your opinion, but what about the community? It's inconvenient for users to have to look to another wiki for one page that could have been easily found on a more active wiki. And even if the less active wiki isn't a content fork of the more active wiki, the less active wiki should be merged into the more active wiki. And I see your point about how Miraheze keeps duplicate wikis together. Even Fandom doesn't merge wikis for certain reasons, as can be seen on the page I quoted in my post. Also, do you have any specific wikis that are duplicates or have similar topics to other wikis? Tali64³ (talk) 22:24, 2 November 2021 (UTC)
 * Much of the above was addressing from a practical action perspective; my opinion is actually largely agreement, since I do think communities are better off coming together to do something than splintering into forks that cover the same ground for both the editing base and potential viewers and I do think the 'weaker' wikis without a truly discernible function should merge into more complete ones for a better result. It's probably a topic to raise on the various local communities linked above and see if an overall compromise can be made since I'm still skeptical that the action could truly be forced, again unless there is truly proven content duplication. If the scopes are too similar regardless though, would be an interesting thing to have a Steward comment on - perhaps . if that's the case and there is something actionable, I can try to find more scope duplication including follow up on the above where I'm fairly sure multiple 'pasta compilations' with the same practical function exist. For now at a communal level, perhaps we can take a closer look at the above examples and see if we can resolve them to have an approach with any more close overlaps we can find. --Raidarr (talk) 17:24, 3 November 2021 (UTC)
 * I proposed a method to merging wikis above. It involves a community vote to see if they want the wiki to be merged, so the process won't feel forced. Tali64³ (talk) 18:17, 3 November 2021 (UTC)
 * Vote is reasonable and standard for established communities, but there are also cases with very few users or only the founding contributor, and yet other cases essentially abandoned and on the brink of true inactivity only being strung along; in these cases the responsible users can be contacted directly with an inquiry, or even an adoption request for the last scenario could be made. --Raidarr (talk) 19:31, 3 November 2021 (UTC)
 * Thanks for your input. I'll amend the process. Tali64³ (talk) 16:20, 4 November 2021 (UTC)
 * Mirapedia seems to be more of a wikipedia copy kind wiki but allpedia seems to be a similar wiki without copying content Anpang

Talk 01:04, 3 November 2021 (UTC)


 * I looked, and I can't find any content policies or notability guidelines there. That's why I classified it as a no notability guidelines encyclopedia. Tali64³ (talk) 16:23, 3 November 2021 (UTC)

Problem with Small
Hi, I am encountering a slight problem with the " " code. It puts me in an insane space every time I use it, as you can see here:

Do you have a solution? Thanks in advance. Darkrai18 (talk) 19:33, 2 November 2021 (UTC)


 * Hmm, maybe put style="vertical-align:text-top" or use  instead, that will put the text on top. If you want it centered, maybe do something like text  (it puts margin to the bottom so it kinda floats) i dont know if either of these works havent tested  Anpang

Talk 01:01, 3 November 2021 (UTC)
 * It doesn't worked. --Darkrai18 (talk) 19:47, 3 November 2021 (UTC)
 * you can try . You can see the result on my sandbox. アンジェロ先輩 (talk) 22:28, 3 November 2021 (UTC)
 * It still hasn't worked. --Darkrai18 (talk) 17:28, 4 November 2021 (UTC)
 * Can you explain more about the small tag "putting in an insane position"? Did you mean when you put multiple lines of small tags and they create lots of space or the small tags text aren't centered? — Preceding unsigned comment added by Anpang (talk • contribs) 01:43, 5 November 2021 (UTC)

How to change the logo
Hello everyone, i feel stupid for asking this but, as a novice when it comes to computer, i'm lost. And i can't succeed in changing the logo. I followed this tuto https://meta.miraheze.org/wiki/ManageWiki#How_do_I_change_my_logo.2Ffavicon.3F but it doesn't work. I can't find how or where to upload the logo. Thank you ! MF4884 (talk) 14:01, 4 November 2021 (UTC)


 * You upload your logo like a regular image on your wiki's Special:Upload. Once you've uploaded it, hover over the image, right click and press "Copy image address". Return to Special:ManageWiki/settings -> Styling and paste the link there and it should work. Agent Isai  Talk to me! 20:13, 4 November 2021 (UTC)
 * Thank you ! It works perfectly :) MF4884 (talk) 19:09, 5 November 2021 (UTC)

Problem with Tab
Hi, I have a slight problem with my Tab (this: ) I would like it to be lower in my page (and centered too but it's less important.) Right now it's too high, as you can see here: I'd like it to be a bit like on this page: https://equestripedia.org/wiki/Twilight_Sparkle_(Friendship_is_Magic) Thanks in advance. Darkrai18 (talk) 17:32, 4 November 2021 (UTC)


 * Si tu veux qu'il soit centré il faut insérer {| style="margin: 1em auto;" . Pour le reste je sais pas quoi faire. アンジェロ先輩 (talk) 19:59, 4 November 2021 (UTC)
 * ah non c'est pas un tableau, je suis pas pratique avec la balise table... アンジェロ先輩 (talk) 20:03, 4 November 2021 (UTC)
 * Tu es français ou tu fais l'effort de me parler dans ma langue ? --Darkrai18 (talk) 21:35, 4 November 2021 (UTC)
 * Polyglotte, donc j'ai pas de souci avec la langue française.--アンジェロ先輩 (talk) 07:38, 5 November 2021 (UTC)

Problem with Phabricator
Hi, I can't login with my Miraheze account on Phabricator. It says my password is incorrect when it is correct, and attempts to reset my password fail too. Thank you in advance for your help. Darkrai18 (talk) 15:16, 5 November 2021 (UTC)
 * , I am not sure about the issue but you should be able to login via MediaWiki. See Phabricator for more details. --Magogre (talk) 16:07, 5 November 2021 (UTC)

Changing URL for local interwiki prefix (archiopediawiki)
We kindly request that you change the URL connected to archiopediagrc prefix from https://archiopediagrc.miraheze.org/wiki/$1 to https://grc.repository.archiopedia.org/wiki/$1.

Thank you in advance!

Wiki: repository.archiopedia.org (Page: https://repository.archiopedia.org/wiki/Special:Interwiki)

Reason: We are using a custom domain, so archiopediagrc.miraheze.org = grc.repository.archiopedia.org. See https://phabricator.miraheze.org/T8239. Publisher (Archiopedia) (talk) 09:19, 7 November 2021 (UTC)


 * Hello; thank you for the request and a sysadmin may be able to get to it anyway, but for reference these technical changes should be requested through Phabricator, where they can typically see it more quickly and handle it by default. --Raidarr (talk) 10:38, 7 November 2021 (UTC)
 * @Raidarr Thank you for your answer!
 * We figured that our request falls within the category “Request changes to your wiki's local interwiki table” (i.e. it is a request that should be made on Community noticeboard).
 * In any case, should we create a new request on Phabricator or just wait? Publisher (Archiopedia) (talk) 11:37, 7 November 2021 (UTC)
 * Oh dear, I'm not doing good today. I assumed you were requesting something different and completely missed the title, so disregard what I said as I ping a competent IW admin to have a look via Discord. --Raidarr (talk) 11:44, 7 November 2021 (UTC)
 * @Raidarr No worries! In any case, thank you for your speedy response. :) Publisher (Archiopedia) (talk) 12:19, 7 November 2021 (UTC)
 * This is ✅ right now.
 * Thanks for bringing this to my notice, you're awesome. Ugochimobi (talk) 12:28, 7 November 2021 (UTC)
 * o7, best of luck on the project and thank you for speedy resolution. --Raidarr (talk) 12:38, 7 November 2021 (UTC)
 * @Raidarr @Ugochimobi Thank you all very much! Publisher (Archiopedia) (talk) 13:11, 7 November 2021 (UTC)
 * Looks like this got sorted, but to correct something Raidarr said above. Requests for changing a wiki's local interwiki table should not be requested on Phabricator, they should be ideally requested here, for a global interwiki administrator or steward to handle. I can, however, see the reason for Raidarr's initial response, as you noted your custom domain, which is requested on Phabricator. Dmehus (talk) 15:32, 7 November 2021 (UTC)
 * This was an oversight I corrected relatively quickly and forwarded to for resolution, as I realized upon second read that I had completely mis-evaluated the request and pinged an interwiki admin to handle it upon recognizing what it was, per the subsequent discussion above this post. --Raidarr (talk) 15:56, 7 November 2021 (UTC)
 * Thank you for your intervention, @Dmehus; it confirms what @Raidarr had already clarified after the initial mistake.
 * We noted our custom domain (by referring to the relevant task on Phabricator, no less), because we thought that it would be helpful for the Interwiki admin who would check the new link in order to add it our Special:Interwiki.
 * But, apparently, our desire for precision created confusion. A fine example of unintended consequences or of the unity of opposites? Well, an issue resolved and philosophical food for thought: what else could we ask for? :D
 * Thank you again! Publisher (Archiopedia) (talk) 18:17, 7 November 2021 (UTC)
 * It was much more a consequence of my addled early morning mind than any error in the reporting or its clarity, I'd say. --Raidarr (talk) 18:24, 7 November 2021 (UTC)
 * Not a problem either way. Thanks everyone! Dmehus (talk) 18:38, 7 November 2021 (UTC)

Question (idk if this is the right place)
Uhhh is there any way to change the default skin of my wiki ?

Sorry first time using miraheze i have too many questions and my english is bad i just wanted to know how to change the default skin to monobook or something else ;-; Alexthefluffy1 (talk) 11:09, 7 November 2021 (UTC)


 * Yes. If you want a built in skin (MonoBook is one of them so you should be set), you shouldn't have to enable it via ManageWiki's extensions menu. If you want 'something else' and it's not an original option (you can see what you have in the next step), you'll have to go to Special:ManageWiki/extensions and enable it in the Skins tab.
 * Having it, you can go to Special:ManageWiki/settings (also listed as 'additional settings' on the sidebar), Styling tab (the last one), and select it from the dropdown list. It should be the first listed setting there.
 * Feel free to ask more questions like this, it's what the CW is for! Although I do recommend browsing through the MediaWiki help area, which can get you by on most things. But since ManageWiki (the way to change things that would normally be a trip to server files) is a Miraheze creation, you can learn more about it here. It's a little big, but I'm sure you'll get the hang of it. --Raidarr (talk) 11:56, 7 November 2021 (UTC)

Improving password standards on Miraheze
Hello all,

In order to comply with the latest security standards, the SRE team wishes to slowly increase password requirements to require that passwords are at least 12 characters.

The plan we thought of would be to progressively institute these requirements: first for global groups, after for local administrators, bureaucrats and bots and finally to extend the longer password requirements to the entire user base.

Before we go ahead with these changes we would like to get feedback from the community, so please do feel free to raise any concerns or provide any feedback you may have or ask us questions about this change and we would be happy to respond.

Thanks, Reception123 (talk) ( C ) 15:09, 4 September 2021 (UTC)


 * My feedback is that this policy is as dumb as most of our Covid-related policy that assumes attaining Zero Risk is more important than living our lives. Anyone who wants the additional security of a longer password can have one instantly.  There is no need to mandate that the entire user base do anything (except perhaps to those with power over the website) except to pat yourselves on the backs for having done something.  If someone is actually asking for this, then implement a customization option for individual wikis where their administration can enforce password length if desired.   20:34 4-Sep-2021


 * Is there a demonstrated need on Miraheze that would entail people changing in this way? I have not seen enough of a wider requirement or evidence on the internet of widespread compromise to think this is in any way necessary. --Raidarr (talk) 00:26, 5 September 2021 (UTC)
 * Hmmmm, not sure if this is exactly necessary. I have yet to see any reports of recent account attacks. DarkMatterMan4500 (talk) (contribs) 23:02, 9 November 2021 (UTC)
 * Support for global groups, but not for local groups. The current status quo for many of Miraheze's affairs is to let local wikis govern themselves and decide on their own policies, and only intervene when there is a legal obligation to do so, or if there is a ToU violation. Global groups should absolutely have strict password policies, because users with such groups can affect all of Miraheze. However, for local admins and bureaucrats, it's best to leave strong passwords as a recommendation rather than a requirement. Local wiki communities can decide on their own password policies if they so choose. As for the entire user base, I don't think it's necessary. A good idea in theory, but in practice it might not do much to encourage better password use. For all we know, someone who's password is the unacceptably insecure "password" could easily change it to "passwordpassword" to get their password up to 16 characters and meet the requirement, yet still have a terrible password.
 * Also, may I ask, what exactly are the "latest security standards" that you're referring to? If by "latest security standards", we mean "using HTTPS", "hashing passwords", and "keeping up to speed with security patches", we're already doing that, right? — k6ka  🍁 ( Talk ·  Contributions ) 23:24, 9 November 2021 (UTC)
 * not sure what that current mandated length is, but 12 seems too long to me. 8, sure, I'd understand, that's common practice. enforcing numbers and special characters, also good. but 12 digits? for casual users? we'd see a huge uptick in password resets. I can maybe see the benefits for global groups, admins, bots, the like (i.e. people who's accounts could damage wikis if compromised) but for someone who logs in once every six months? not worth it imo. also, which security standards are you referring to? you mention "the latest" - who's latest? Amazingakita (talk) 08:57, 10 November 2021 (UTC)
 * not sure what that current mandated length is, but 12 seems too long to me. 8, sure, I'd understand, that's common practice. enforcing numbers and special characters, also good. but 12 digits? for casual users? we'd see a huge uptick in password resets. I can maybe see the benefits for global groups, admins, bots, the like (i.e. people who's accounts could damage wikis if compromised) but for someone who logs in once every six months? not worth it imo. also, which security standards are you referring to? you mention "the latest" - who's latest? Amazingakita (talk) 08:57, 10 November 2021 (UTC)


 * I only want to say that lenght and complexity checkings are ok (mine already is complex and long enough) but I don't agree with checks that compare the previous password with the new one. If I change a password (imagine, because I want it, not because a data breach) I don't want to lose that password forever. Jakeukalane (talk)


 * Hi, I'm also wondering what the "latest security standards" are. Is it some kind of policy that Miraheze has to abide by? Regardless of that, I'm ok with enforcing stronger passwords for users who have potentially destructive permissions, both locally and globally (deleting, blocking, editing interface, etc.). For users without these permissions, maybe there could be a warning with a "your password is not secure" message that the user can dismiss? Just an idea! --Ondo (talk) 10:45, 10 November 2021 (UTC)