Community noticeboard

From Meta
Jump to navigation Jump to search
Community noticeboard
This noticeboard is community discussions, generally global in nature or which relate to specific wikis or users. For requests that require Stewards', or, in a limited number of circumstances, Global Sysops', intervention, please see stewards' noticeboard. If in doubt, please try here first, and you will be directed there if the matter requires a Steward.

On Community noticeboard, you can:

  • Start a community discussion, generally global in nature or which relates to specific wiki(s)
  • Solicit volunteers' assistance to help maintain or write content for your wiki
  • Ask questions with both the global community and system administrators about either Miraheze or some technical aspect of MediaWiki on your wiki
  • Request changes to your wiki's local interwiki table, including change(s) to locally override one or more of the global interwiki table (located on Meta) prefix configurations

If you would like to:

To add your request, type in a concise title in the box below, then click "Add Topic".

Archives of Community noticeboard [e]   

Discussion: Central notice changes

This is for the sake of having an open discussion on the changes proposed in this RfC, though I won't really touch much on the last proposal that was added by another person (of course, you're welcome to talk about that as well nonetheless). Hopefully this comment will at least make it clear what the proposals I brought up are intended to mean. Also, please ask nicely if you would like clarity on anything at all.

The first one to discuss is the following:

Central notices with the purpose of soliciting participation from wiki communities for an event or a discussion should last while that event or discussion is open for people to participate. As in, the central notice would only be removed after the event or discussion has closed.

Let's start by saying that this is not changing what a central notice is made for. It's not saying that every discussion gets a central notice, what it's saying applies in the instance when the people who make central notices decide that a discussion will get a central notice, which is still at their judgement. This talk page comment might show some insight on what such judgement it is, which again they would still retain. What changes is specifically the duration of such particular central notices, in that it would be in relation to the discussion that it would be notifying of.

The discussions being referred to can be gleaned from Special:CentralNotice (click "Show archived campaigns" to see the older ones). It is what is meant to gather people to provide their input and feedback, and this description fits, for example, Requests for Comment or Requests for Stewardship. And if they have yet to be closed by the closer, then the closer presumably decided that it needs more time to gather more comments before a conclusion can be drawn. If so, the methods used to notify of the discussion's existence should get continued use to gather more discussion from people.

Another proposal to discuss is the following:

A campaign type can be set for central notice campaigns, allowing users to opt out of specific campaign types in their preferences, specifically in the "Banners" section. Here is a proposal for what campaign types Miraheze should use:

  • Fundraising
  • Surveys
  • Maintenance
  • Requests for Comment
  • Requests for Stewardship
  • Requests for Community Director

To make it clear how to use preferences to opt-out of campaign types, some text instructing people how to do so should be added to central notices.

In technical terms, campaign types are configured with $wgCentralNoticeCampaignTypes in LocalSettings.php.

This can presumably work with ManageWiki to apply for a whole wiki. To sysadmins, this would presumably be done by using a custom variable to set $wgDefaultUserOptions['centralnotice-display-campaign-type-whatever'] = 0.

Now, in regards to how to decide on the campaign types to be used, I'd say that having the communities' consensus is still relevant, in the case of disputes over what should be grouped together or partitioned. And the RfC does show a dispute over whether Requests for Global Sysop should be included, excluded, or grouped with another type. So it would at least be useful to have some sort of discussion with wiki communities to figure out what's best.

In response to other comments in the RfC: Including Requests for Global Sysop in the list of campaign types does not mean that every single one of that request gets a central notice, it is meant to mean that a RfGS would be allowed to get a central notice, which would still have the judgement of the people who make central notices to actually get one. And people should be able to decide for themselves if they want to opt out of seeing certain central notices, and I figure that if someone desires a tool to stop seeing a certain kind of notification, they likely aren't interested in what's being notified about in the first place. Finally, it was concluded in this RfC that there is consensus for community-oriented posts to be posted on Miraheze's social media accounts, therefore a community-elected role would be appropriate.

Feel free to say your thoughts on any of these topics. K599 (talk) 15:29, 1 December 2021 (UTC)[reply]

@K599: And will there be a way to disable CNotice for some, and leave only fundraising? YellowFrogger (Talk Edits) 15:33, 1 December 2021 (UTC)[reply]
@YellowFrogger As said in the explanation of how campaign types work, people should be able to go into their preferences and opt-out of the types that they don't want to see. K599 (talk) 16:27, 1 December 2021 (UTC)[reply]
@K599: But there has to be an option to hide it across the whole wiki (not just in preferences), but yes, all visitors to a particular wiki would be better. Nobody is obligated to see CNotice either, so it had to have that. Showing only CNotice for fundraising, which is important for Miraheze to maintain the wikis maintenance, the others don't matter (or only matter in Meta). YellowFrogger (Talk Edits) 19:59, 1 December 2021 (UTC)[reply]
@YellowFrogger I mentioned above that there's presumably a way to make campaign types work with ManageWiki, though I suppose a sysadmin should comment on the method I talked about. K599 (talk) 20:19, 1 December 2021 (UTC)[reply]
Note that the list of campaign types proposed in my initial comment is based on past central notices as seen on Special:CentralNotice. Of course, feel free to discuss any desired changes to the list. K599 (talk) 03:04, 8 December 2021 (UTC)[reply]
For some added context, the banner preferences can be seen in Special:Preferences#mw-prefsection-centralnotice-banners, where it's currently the extension's defaults. These options have been unused probably due to being unrelated to Miraheze. K599 (talk) 03:46, 22 December 2021 (UTC)[reply]
This talk page discussion has a review of the proposed list of campaign types. In response:
@Dmehus: Okay, but I would prefer that "Community Notices" have a page that explains what would fall under this label. Then this page would be linked, if possible, from the related user preference and, if implemented, the related ManageWiki setting proposed in the community wishlist proposal. K599 (talk) 01:29, 2 January 2022 (UTC)[reply]

Community Discussion: Wiki creators and creating wikis for themselves

Since an RfC would be too much for just one addition to the Wiki creator policy I am opening a Community Discussion here. As you all know, wiki creators are elected to serve the community and approve/decline wikis that are requested. They can in theory of course also approve their own wikis, but in my view for purposes of objectivity it would be preferred that they had another wiki creator do that.

However, what I'm proposing here isn't a complete ban on wiki creators creating their own wikis, it's simply the possibility for a Steward to remove a wiki creator if they are excessively create wikis for themselves and tend to not be creating wikis for other users.

The following would be added to "Revocation": A wiki creator's rights may also be removed by a Steward if they are mainly creating wikis for their own use and not focusing on their role of creating wikis for other users. Reception123 (talk) (C) 08:21, 7 December 2021 (UTC)[reply]


  1. Symbol support vote.svg Support as proposer. Reception123 (talk) (C) 08:23, 7 December 2021 (UTC)[reply]
  2. Symbol full support vote.svg Strongest support Wiki creators should serve the community, not themselves. It wouldn't make sense if a wiki creator misused their privileges to create an excessive amount of wikis for themselves without any consequences. Agent Isai Talk to me! 08:23, 7 December 2021 (UTC)[reply]
  3. Symbol full support vote.svg Strongest support The proposal pretty much covered it.
  4. Symbol strong support vote.svg Strong support Why not? Anpang Talk Stuff 08:27, 7 December 2021 (UTC)[reply]
  5. Symbol full support vote.svg Strongest support. This should stop wiki creator spam. TylerMagee (talk) 08:38, 7 December 2021 (UTC)[reply]
    Symbol support vote.svg Support --Magogre (talk) 09:04, 7 December 2021 (UTC)[reply]
  6. Symbol full support vote.svg Strongest support I don't really have to much to add, the post covered basically what I wanted to say on this issue. TigerBlazer (talk) 11:15, 7 December 2021 (UTC)[reply]
  7. Symbol support vote.svg Support Ugochimobi (talk) 11:25, 7 December 2021 (UTC)[reply]
  8. Symbol support vote.svg Support Don't get me wrong, I'm fine with wiki creators requesting wikis for themselves and self-approving it, but if it becomes excessive to the point of flooding the farmer log, then it does come off as either disruptive or somewhere between messy and cloggy like a clogged toilet. --DarkMatterMan4500 (talk) (contribs) 11:56, 7 December 2021 (UTC)[reply]
    That's a fair point too, though I was more concerned with objectivity and creating more wikis for yourself rather than for other users. Since it's no secret what actions started this Community Discussion, I would point out that many requests that were made and 'self-approved' would have likely not been approved by another wiki creator, at least not by myself. Wiki creators also decline wiki requests if someone is requesting too many wikis, so it's definitely unfair that a wiki creator can create many wikis for themselves while regular users are told not to create an excessive amount. Reception123 (talk) (C) 12:07, 7 December 2021 (UTC)[reply]
    Reception123 Yes, that's very true. DarkMatterMan4500 (talk) (contribs) 13:50, 7 December 2021 (UTC)[reply]
  9. Symbol support vote.svg Support All users must respect the content policy and wiki creator is no exception YellowFrogger (Talk UnEdits) (Bring back patrolled) 14:29, 7 December 2021 (UTC)[reply]
    Well the Content Policy as such doesn't mention wiki creators creating an excessive amount of wikis for themselves at all, which is why I opened this Community Discussion, as there needs to be a separate ground beyond the CP removal ground. Reception123 (talk) (C) 15:44, 7 December 2021 (UTC)[reply]
    that's right YellowFrogger (Talk Edits) 23:19, 7 December 2021 (UTC)[reply]
  10. Symbol strong support vote.svg Strong support Absolutely. I actually think it would be a good convention for a wiki creator to request a wiki and let another wiki creator approve it in the name of transparency, but I won't push for that here. --Raidarr (talk) 14:49, 7 December 2021 (UTC)[reply]
    That's an interesting point yeah, I'm kind of undecided on that but related to what I say below I feel like if a wiki creator wants to create a wiki that they could see be declined by someone else they should wait for someone else to approve, but that's not really a clear question. Reception123 (talk) (C) 15:43, 7 December 2021 (UTC)[reply]
  11. Symbol strong support vote.svg Strong support I agree with what is said above. Maybe this example is too extreme but it is like a judge deciding their own case. Here of course it is not nearly as serious or complicated but the principle still applies in that a judge is someone who is trusted and knows how to apply the law but that does not mean that they are trusted to apply it if they are involved in a case. In my personal view we are not being strict enough and I would go further than this proposal and vote for not allowing wiki creators to create their own wikis at all for reasons of impartiality; can someone really impartially interpret the Content Policy in regards to their own wiki? That is not however the subject here but in consequence I believe that it is perfectly desirable for a wiki creator to be removed if they are not adhering to their original "oath" which is to create wikis for other users, not for themself. I have seen the comments opposing the Steward discretion aspects of this proposal. While there is a point to the argument of not giving up everything to Stewards in this particular case I agree with what is said by Reception123 and believe that it would not necessarily be desirable to have a "direct democracy" model for these removals as is the case for other more positions. Sometimes it is necessary for the community to delegate their powers to Stewards and this situation is to me is one of those times. If Stewards are not trusted by the community then they should open a revocation request instead of attacking the discretionary powers of Stewards. Accordingly it is my strong view that it is not acceptable for a wiki creator to be focusing on creating multiple wikis for themselves and to not be creating almost any wikis for other users. --DeeM28 (talk) 09:23, 8 December 2021 (UTC)[reply]
  12. Symbol support vote.svg Support I don't really see how this could be bad.  —Lakelimbo (talk)  19:22, 15 December 2021 (UTC)[reply]


  1. A wiki creator is someone who has the experience and trust to create wikis that can follow Miraheze policy, which you arguably can do best if you yourself are managing it. Whether or not people should be creating their own wikis is a seperate issue, but I don't think there is a distinguishment between doing so "mainly" and not. There is no obligation or commitment as a wiki creator, it is a volunteer position, and I do not support requiring people to "balance" with other wikis. Also, the proposed change is that any Steward can just take the permissions away unilaterally which is definitely a no-go. Changes like that should require consensus. Naleksuh (talk) 21:08, 7 December 2021 (UTC)[reply]
    I also agree with you. No need for early revocation for a single basic reason YellowFrogger (Talk Edits) 05:20, 8 December 2021 (UTC)[reply]
    No one suggested that someone should be removed based on one instance and without warning. The suggestion that Stewards would take permissions away as they please suggests a lack of trust in the current Stewards to me which is a different issue altoghether.If there is not currently an obligation on a wiki creator to approve other users' wikis and not just create wikis for themselves, I think there should be, and this new addition to the policy would imply that. Stewards can already take permissions away unilaterally for violations of the Content Policy, so in that regard they already have a similar power, just limited to the CP. While "A wiki creator is someone who has the experience and trust to create wikis that can follow Miraheze policy" is true, what if a wiki creator has lost that trust because they're not creating wikis for users but just for themselves? There should be a way for them to be removed. Reception123 (talk) (C) 07:46, 8 December 2021 (UTC)[reply]
    There should be a way for them to be removed. Yes, but that doesn't mean that way should be stewards unilaterally removing it. Also, removal should be because of creating wikis against policies, not by not creating enough wikis for people other than themself Naleksuh (talk) 01:05, 10 December 2021 (UTC)[reply]
  2. Symbol oppose vote.svg Oppose if a wiki creator is only there approving their own requests, provided they are doing it properly, I see no problem with that - indeed it is beneficial to Miraheze as a whole as it means other wiki creators do not have to deal with them. If they are not doing so properly then a better proposal would be to ban wiki creators from approving their own requests. ~ El Komodos Drago (talk to me) 12:43, 10 December 2021 (UTC)[reply]
    Well yes, the issue isn't about creating a few wikis for ones-self, it's basically about abusing the process and creating an amount of wikis for oneself that otherwise would have not reasonably been approved by any other wiki creator. While there is no hard rule, it is a convention that unless they have a good reason we don't really allow users to create a large amount of wikis for themselves. Reception123 (talk) (C) 07:00, 13 December 2021 (UTC)[reply]
    Well propose that rule. It seems like you are trying to eliminate one behaviour by creating a rule banning an entirely separate one that seems (alone) to be harmless. This is bad rule making. ~ El Komodos Drago (talk to me) 11:04, 15 December 2021 (UTC)[reply]
  3. Symbol oppose vote.svg Oppose – Mainly based on the Naleksuh's reasoning. I agree the removal should be performed if the wiki creator is creating wikis only for their own and/or against policy but it shouldn't be the unilateral decision of a steward to remove the rights without consulting the community. Stewards are trusted, but I do not feel comfortable with the rights being removed unilaterally by a steward if the user is elected by community. If community consultation added to the proposal, I'd completely agree with it. --Magogre (talk) 13:41, 10 December 2021 (UTC)[reply]
  4. Symbol oppose vote oversat.svg Strong oppose in part, per what others have said above, namely Naleksuh, Magogre, and El Komodos Drago, but also because I feel this proposal was made in response to a user who speaks little to no English, but who I might also add has created wikis for users and whose Content Policy understanding actually not that bad. As our only Chinese language wiki creator, if their bit was hypothetically removed by a Steward per this criterion, I feel they'd have a difficult time getting it back mainly because of their lack of Meta activity and command of the English language. As well, since the proposal is very, very vague, you potentially have a situation where one Steward might agree with revocation and another Steward might not. Moreover, though I generally prefer Steward discretion rather quantified details, I feel this is a case where it's better to be more explicit. What constitutes "for their own purposes"? One wiki? Ten wikis? 100 wikis? I guess I could potentially support something along these lines, but only an alternate proposal that (a) takes into account the above arguments, (b) quantifies specifics, (c) ideally is part of a larger RfC or an acknowledged prelude to a forthcoming RfC to amend the wiki creator inactivity and revocation clauses (i.e., for example, should the SRE revocation clause still exist? if so, under what conditions?), (d) takes into account the multilingual nature of Miraheze and Meta Wiki, and (e) requires at least super-majority (i.e., 75%) of existing Stewards to agree to the removal, if not unanimity, and only after, say, a thirty (30) day notice and remediation plan had been put forward to the wiki creator in question. Dmehus (talk) 07:37, 13 December 2021 (UTC)[reply]
    To respond to your first point about the specific user I will admit I am not aware in respect of which user this request was made but I believe it is problematic for a wiki creator to speak no English especially if they are approving requests in English. I think it is quite obvious why such a situation is not desirable.
    In regards to discretion I would currently support a wider discretion for Stewards to remove wiki creators generally beyond simply the Content Policy but based on the other opposes it appears to me that such a wide discretion is not desirable.
    Regarding your proposal it appears to be too lenient for me. Why do wiki creators need to be given such a large measure of remediation options? If they are not creating wikis for other users they should be removed in my opinion and the community can reinstate them if that is what it wants. While there may be no appetite for this change my view is still that it would be simpler to not allow users to create their own wikis for reasons of impartiality.
    To respond to the vagueness I am not sure how specifics would make sense in this context and how someone would be able to define a number of wikis that a person can create for themselves. I am confused as to the reason why you believe that in this case general Steward discretion is not appropriate; I think it is.
    In conclusion my general view is that wiki creators need to be held to a higher level of scrutiny and it is better to remove more wiki creators if that is necessary to preserve the integrity of the process. Wiki creators can always be added back if they pledge to respect the rules and conventions in the future but I disagree with being overly lenient if they are not serving the community but are serving themselves. DeeM28 (talk) 18:43, 16 December 2021 (UTC)[reply]
    The issue, though, is for the user in question, there's not really been any Content Policy issues in their wiki approvals. Dmehus (talk) 05:49, 20 December 2021 (UTC)[reply]
    As for the discretion, I'm not necessarily opposed to Steward discretion, but this was hurried and rushed proposal, which even Reception123 admitted to me on IRC, that did not consider all of the procedural ramifications. What if one Steward disagrees with another Steward's removal? Can the rights be re-added without a community vote? Without some sort of readdition clause, or a thorough remediation and corrective action plan, we'd essentially be substituting one form of mob mentality !voting with another. I do agree with you that I feel for some positions, direct democracy is not the best form of appointment. I would be supportive of granting greater authority and discretion to Stewards to remove the wikicreator for more than just a defined inactivity clause or repeated Content Policy understanding and application issues, if we also allowed for Stewards to grant the wikicreator bit, perhaps on a temporary basis, where the request tends devolve into mere !voting based on English Wikipedia essays, so as to allow reasonable candidates, perhaps candidates who speak languages other than English, a track record by which the community could assess, from a practical standpoint, whether the user can consistently apply their understanding of Content Policy correctly. So, as an example, in such cases, Stewards could be granted the discretion to grant the bit on a temporary basis (say, for a maximum of 30 days), after which the bit would be automatically removed. Either shortly before their temporary status was due to expire, or after it had expired, the candidate would then be able to have a track record to cite to the community in standing for election as a permanent wiki creator. Additionally, I'm more inclined to support some sort of Meta Wiki only activity for the purposes of the inactivity clause, as we have some wiki creators who are globally active, but have not created one wiki. Thus why I feel a more major overhaul of the policy is needed. Dmehus (talk) 06:07, 20 December 2021 (UTC)[reply]


  • Pictogram voting comment.svg Comment: While I don't see the problem with self-approving wiki requests that other wiki creators have self-requested, it becomes a distraction to all others who would want to review the wiki request if it becomes excessive. --DarkMatterMan4500 (talk) (contribs) 12:07, 7 December 2021 (UTC)[reply]
  • Pictogram voting comment.svg Comment: I think it's worth mentioning that the case which lead to this conversation is a holdout of a time when WCs were appointed with little in the way of community input, and it was done two days before the process changed. Just an observation, not to fault the Steward at the time who made the call. --Raidarr (talk) 14:45, 7 December 2021 (UTC)[reply]
    Indeed, the proposal may serve a limited purpose (for a single user) but I think either way it would make clear to any future wiki creators that when creating wikis for themselves if they choose to do so they should take the chance to think: would another wiki creator really have approved this if I was a regular user? Though of course its main point is limiting excessive wiki creations for ones-self which would not otherwise be approved of by any creator Reception123 (talk) (C) 15:42, 7 December 2021 (UTC)[reply]
    By all means, this is very reasonable to do regardless of the 'catalyst' to propose. Plus it solidifies the precedent for new requests in the future. --Raidarr (talk) 15:55, 7 December 2021 (UTC)[reply]
    Reception123 said he's open to having this essentially serve as a non-binding community input session, rather than any sort of binding policy-setting discussion, in view of the strong arguments presented in opposition. So essentially, the comments expressed herein would help to refine the aims of the proposal in a broader RfC that looks at reforming the wiki creator policy, perhaps in January or something. Based on the conversations I've had with Agent Isai on IRC, he seemed receptive to the idea as well. Dmehus (talk) 05:54, 20 December 2021 (UTC)[reply]
  • As pointed by the Naleksuh, I also believe a steward should not remove the rights unilaterally and I'd like it if somehow there should be a fixed time for the community to comment on the removal. A note on the AN or SN should be sufficient and anyone should be able to request the revocation of other's rights upon misuse. --Magogre (talk) 05:17, 8 December 2021 (UTC)[reply]
    As commented above, this is already possible for Content Policy violations so this isn't some large new change that gives Stewards significant extra power. While this was never discussed before explicitly, my feeling is that the reason for why wiki creator revocations are Steward discretion rather than community consensus/vote is to avoid mob-mentality, for example people teaming up to remove a wiki creator because they disagree with their specific approval/disapproval of wiki requests. Again, that's just my view, it was never actually discussed in this way. Though either way, as I say above, if you disagree with the current Steward discretion that exists for revocation then that's a different issue because it already exists for CP violations. Reception123 (talk) (C) 07:50, 8 December 2021 (UTC)[reply]

Do you think this RFC would stand a chance?

I have an idea for an RFC (Requests for Comment) about changes to the Content Policy, but Raidarr and Agent Isai suggested that I should ask other users first to prevent it from being snowballed, and Agent Isai specifically suggested I go here to ask. Anyway, here are my ideas for changes:

  1. Change the rule "Miraheze does not host wikis with the sole purpose to spread unsubstantiated insult, hate or rumours against a person or group of people" to "Miraheze does not allow any pages on wikis with the sole purpose to spread unsubstantiated insult, hate or rumours against a person or group of people" because we do not need any pages with this purpose, whether or not the wiki itself is made to do so.
  2. The rule "A wiki must not create problems which make it difficult for other wikis" should have multiple changes:
    1. The rule should apply to all wikis, not just Miraheze wikis, because no wiki should be duplicated; the internet doesn't need two versions of wikis. I understand that it is hard to stop the entire internet from duplicating wikis, but it is something that should be stopped, and Miraheze should play a part in stopping it. I do think that since there are no staff for the entire internet and as a result corrupt staff exist on various sites (including wikis), there can be exceptions for non-Miraheze wikis. However, a user must go through every single option in order before requesting this to be an exception (unless the options say they can do otherwise):
      1. Review the wiki's quality. If you want to make an exception, then the most ridiculous reason to duplicate wikis is because they have bad quality. If they have bad quality, then they can be improved. If the changes that need to be made are not against the rules, then just try to clean up the wiki.
      2. If the change would concern the rules or requires a lot of cleanup, then ask the owner of the wiki (note that what counts as an "owner" includes the founder, a user who adopted the wiki [this only applies to wikis that are hosted by another wiki-hosting site since independent wikis cannot be adopted], the only bureaucrat [if there is only one bureaucrat] and of course, a user who is stated to be the "owner") or, if there is no bureaucrat who would be considered the "owner", the most active bureaucrat, and talk to them about the change. If there are no bureaucrats or all of the bureaucrats are inactive, you should adopt the wiki. However, note that you should try contacting the bureaucrats first regardless, and if the wiki is independent, you are now free to request an exception.
      3. If the bureaucrat you contacted disagrees with you, then do not immediately decide that the bureaucrat is corrupt. Try to have a reasonable discussion with them. If you tried to adopt the wiki and your request was denied, unless you agree with the reason, try to continue talking with the user who denied your request and again, don't immediately decide they're corrupt.
      4. If the bureaucrat acts in a way you consider unfair, if you can, calmly talk with them about it. If the same happens with the user who denied your request, do the same thing with them.
      5. If the bureaucrat continues to be unfair, then it depends on the case on what you do. If the wiki is hosted by another wiki-hosting site, talk to the users with the highest position (whether or not that is stewards, staff or something else) about dealing with the abusive bureaucrat. If the wiki is independent, however, you are now free to request an exception. If the user who denied your request continues to be unfair, then it depends on what position they have. If they have the highest position, then again, you are now free to request an exception. If they do not, however, and someone is above them, they can be reported to a user with the highest position.
      6. If the user with the highest position disagrees, then again, try to have a full conversation with them.
      7. If the user with the highest position continues to be unfair after a discussion and there is no point in discussing it anymore, then you should ask the stewards of Miraheze, and if they agree with you, then your wiki can become an exception. In case you're wondering where you can request an exception, request it at Stewards' noticeboard before requesting the wiki, and if your request is approved, then you can now request the wiki at Special:RequestWikiQueue, and make sure you link to the discussion for reference.
    2. Although I believe this already applies, I think it should be made more clear that the rule does not just apply to duplicating wikis, but also to the following:
      1. Creating pages on wikis that contain destructive criticism towards the wiki.
      2. Having any content on wikis that the wiki's staff members have stated that they do not want.
  3. There should be a rule that states "A wiki must not have pages that are likely to cause drama". Pages that are considered likely to cause drama are:
    1. Negative pages about obscure users on the internet
    2. Pages about people who do not want a page about them (this does not apply to informative pages)

FatBurn0000 (talk) 02:28, 12 December 2021 (UTC)[reply]

"A wiki cannot create problems for other wikis". But this already applies to all wikis including non-Miraheze external ones. Does this include humor wikis? Can't they also create an article about another wiki? But all the content of a humor wiki shouldn't be taken seriously, that's a fact. YellowFrogger (Talk Edits) 02:37, 12 December 2021 (UTC)[reply]
@YellowFrogger: I agree that humour wikis should be able to create pages about other wikis, but I don't think I said that they couldn't; I only said that if the staff members don't want it they can say that won't allow it. FatBurn0000 (talk) 03:22, 12 December 2021 (UTC)[reply]
Also, are you sure that Miraheze doesn't allow duplicates of non-Miraheze wikis? According to Raidarr, there are multiple duplicates of Fandom wikis. FatBurn0000 (talk) 03:34, 12 December 2021 (UTC)[reply]
1. is intended to address systemic issues. The change is not necessary. The wording is deliberate to reiterate our stance; any pages are included by this wording, and are considered 'content policy issues' already. They can be reported and addressed (by removal at request or if systemic and unaddressed reasonably, by wiki lock until fix or removal).
2. can merit additional, if careful language, so lets see:
2.1. I disagree that Miraheze should gatekeep on this. For one, many Fandom wikis have moved to Miraheze, and Fandom is notorious for being sluggish or unwilling to delete wikis for their ambient revenue, nonetheless the entire staff are typically inclined to move in bypass of your written process altogether. For two, communities with severe enough drama and legitimate enough community schisms should not be subject to your proposed bureaucratic process, especially if the wiki intends to make significant enough stylistic or fundamental changes that would not be feasible for another platform. Again, the level of possibilities make this a potential issue. All in all my stance here is not unlike my stance on politics - 'lets worry about ourselves before worrying about other (nations)'. We actually do have a topical duplication problem in several cases locally even if they don't match the strict requirements that would make content forking an issue, and we could do better from a wiki creation standpoint to be aware of and refuse probable content duplication on Miraheze as well as work to remediate the ones that exist. There are a variety of wikis with strongly overlapped purpose as Tali64³ has researched before. In all I would have to oppose based on the broad stretch of this language, and disagree that it is our role to enforce it anyway.
2.2. 'destructive criticism' is a dangerous precedence for 'your criticism is too steamy for us, delete'. For one that is more of a conduct matter, since it does not pertain directly to wiki content. For two this should be addressed by the local community and local rules. It is not the Content Policy's job to moderate at this level. Indeed, 2.2 here is entirely out of scope for the CP as a whole imo. If you don't like the criticism, rebuke it or ignore it, or if it is sufficiently toxic, remove for incivility and unconstructive purpose, all of which is possible with healthy local management.
3. Already covered in full imo by the premise of the existing rule. Frankly I think this is an attempt to enable your lawyering to bring back a fundamentally problematic concept - pages about people with a critical or negative focus - as a legitimate thing since you will have made the policy more specific, but not actually addressed this detail.
Not to assume bad faith, but I believe these changes are born of a desire to enable certain forms of content and to realize a more personal vision of what Miraheze should do and allow which would be more controversial if expressed in full to the wider Meta community. Part of why I suggested to have the concept reviewed first is so this could be expressed informally and if possible, changes made to talk out of this line of thought or even make it malleable instead. Unfortunately given the evident purposes of these points and their niche appeal, I'm afraid this one is not likely to pass in addition to what would be my personal outright oppose in a live RfC. --Raidarr (talk) 11:04, 12 December 2021 (UTC)[reply]
  1. Well, it should still be made more clear.
    1. This is why there are exceptions to this rule. Also this doesn't necessarily apply to just Fandom wikis.
    2. Fair enough.
  2. Not all criticism and negativity towards obscure users is guaranteed to be destructive, it is just a common problem that they will be, which has before happened with the Outcasts and other user reception wikis (including Crappy GachaTubers Wiki, a wiki that is unfortunately still open).

FatBurn0000 (talk) 22:03, 12 December 2021 (UTC)[reply]

I feel like I agree with FatBurn on this, if this is an existing rule, then it should be stated in the content policy. At the very least I think that "sole purpose" is slippery wording. ~ El Komodos Drago (talk to me) 11:22, 15 December 2021 (UTC)[reply]
And you. Are you going to open an RfC or not? YellowFrogger (Talk Edits) 22:32, 12 December 2021 (UTC)[reply]
There should be a rule stating, "Only one Miraheze wiki should exist for a topic," because duplicate wikis exist. Tali64³ (talk) 00:41, 13 December 2021 (UTC)[reply]
@Tali64³: What I am suggesting is that the rule should be for all wikis, not just Miraheze wikis, with a few exceptions for non-Miraheze wikis in case of abusive staff. FatBurn0000 (talk) 08:21, 13 December 2021 (UTC)[reply]
A user named Blubabluba9990 opened an RfC YellowFrogger (Talk Edits) 00:00, 14 December 2021 (UTC)[reply]
  1. There isn't any issue with the creation on Miraheze of a wiki that already exists somewhere on the internet. Some proprietary wiki host having a certain wiki does not give them the rights to it.
  2. I'm not entirely sure what you're referring to by "destructive criticism", but being able to criticize a wiki on that wiki is essential to accountability.
  3. There is no need for a rule such as 2.2.2, as wiki's generally have some form of content policy or guidelines as to what's allowed. Furthermore, the terminology "staff members have stated that they do not want", as that seems to imply that a wiki belongs to its staff, not its community. — Arcversin (talk) 19:52, 14 December 2021 (UTC)[reply]
  1. How is there "no issue" with it? There is no need for two versions of one wiki on the internet.
  2. What I am saying is, the pages should not suggest that due to the flaws, users should go against the wiki and possibly fork it.
  3. Fair enough.

FatBurn0000 (talk) 21:56, 25 December 2021 (UTC)[reply]

@FatBurn0000: There is no issue with it because while it's generally not a good thing, the community of editors around a particular topic isn't bound to a particular platform, and migration away from Fandom is a positive. Also, wikis don't have "owners", so you won't want to use that word in any proposals. — Arcversin (talk) 23:07, 25 December 2021 (UTC)[reply]
@Arcversin: There are exceptions in certain cases, but wikis should still not have duplicates anywhere unless it is truly necessary. If there is a fair enough reason to fork a wiki from another site, then again, exceptions can be made. FatBurn0000 (talk) 05:12, 26 December 2021 (UTC)[reply]
@FatBurn0000: Whether a wiki exists some other place on the internet isn't, apart from copyright, relevant to whether Miraheze will host a wiki. It might not be a good thing for communities to be split, but it's best for such situations to be sorted out by the communities themselves, via migration of community members, as opposed to external interference. For other Miraheze wikis, we have the fork provision of the Content policy, but for external wikis, we want to support communities getting out of places like Fandom. — Arcversin (talk) 16:08, 26 December 2021 (UTC)[reply]
@Arcversin: That still isn't a reason to duplicate a wiki. FatBurn0000 (talk) 21:38, 27 December 2021 (UTC)[reply]
@FatBurn0000: Then please explain your reasoning. — Arcversin (talk) 00:22, 28 December 2021 (UTC)[reply]
@Arcversin: My reason why I would like no wikis to be duplicated is because there is no need for more than one wiki about one topic. Most issues with wikis can be dealt with. FatBurn0000 (talk) 22:28, 28 December 2021 (UTC)[reply]

Re: Proposal 3

This is largely covered by the existing rule that "Miraheze does not host wikis with the sole purpose to spread unsubstantiated insult, hate or rumours against a person or group of people". With regards to 3.1, I'm not sure that obscurity should be a big issue - obviously for identifiable individuals there is a GDPR/right to erasure issue here. 3.2 is basically entirely covered and again GDPR/RTE. ~ El Komodos Drago (talk to me) 17:07, 16 December 2021 (UTC)[reply]

UI compacting the main navigation menu

Hi! I would love to see main navigation menu on the side be more compact and would suggest removing repetion from 3 sections to be displayed in this way:

  • Request:
    • new wiki
    • new feature
    • adoption
    • RfC's
  • Noticeboard:
    • Community
    • Stewards'
    • Meta Adminis.
  • Miraheze:
    • FAQ
    • Help Center
    • Categories

...what do you think?  ZBlace (talk) 07:41, 16 December 2021 (UTC)[reply]

Isn't it the same? or you meant shortening the text to that?  AP📨  08:01, 16 December 2021 (UTC)[reply]
YES - shortening the text to this version. I think it makes huge difference in mobile access, visibility of Donation link (which is super low at very end) and maybe a little bit in traffic :-) I think also most basic color coding would bot hurt, but that is more complex to negotiate due to color-blind people and branding issues. ZBlace (talk) 08:15, 16 December 2021 (UTC)[reply]
Why's meta administrators noticeboard with a "i" and fullstop? "Meta Adminis." Typo? And new wiki, new feature, adoption are spelled with no capital letter.
Can it be changed to:
  • Requests:
    • Create wiki
    • Request feature
    • Adopt wiki
    • RfC
  • Noticeboards:
    • Community
    • Stewards'
    • Meta admins'
  • Miraheze:
    • FAQ
    • Help center
    • Categories
Also, it'd be better if it was a preference instead of everyone getting the shortened sidebar. And another suggestion: move the Donate to Miraheze to the Miraheze: category and make it "Donate" in the shortened version.  AP📨  09:07, 16 December 2021 (UTC)[reply]
Just from the main menu down it? I don't want Random page removed (which I like to keep squishing to see some pages) YellowFrogger (Talk Edits) 19:32, 16 December 2021 (UTC)[reply]
Yes and Sure. I also like RandomPage on Wikis since start :-p
How can this proposal get picked up? --ZBlace (talk) 17:53, 24 December 2021 (UTC)[reply]
@ZBlace It's addicting to do that. And why are you wanting to change? The current one looks pretty good, and I don't know where you can make the proposal either, if it's on the Miraheze server on Discord, with RfC or on SN or Meta:AN (administrators noticeboard , interace admins can change MediaWiki:Sidebar), so it would be nice if you send there. --YellowFrogger (Talk) 19:50, 24 December 2021 (UTC)[reply]
Reasoning? Check my #2post in thread. --ZBlace (talk) 20:41, 24 December 2021 (UTC)[reply]
I like the spirit here, of using fewer words to convey the concepts. Especially in the noticeboards area, spelling out 'noticeboard' is not really necessary. I do think the 'adoption' wording should change, as it's no longer appropriate for what the page does (but that requires that the page is moved to a renamed version as well, an action that is still pending). I would pick bones with exact choices of words however, and would rather see it explored further if we can get confirmation that a Meta Admin would like to pursue this or raise this to a Meta RfC. Raidarr (talk) 00:48, 25 December 2021 (UTC)[reply]
@Raidarr thanks for positive feedback. I would also love to hear of any Meta admin now. --ZBlace (talk) 14:58, 25 December 2021 (UTC)[reply]
Raidarr, this is the shortcut. Good for lazy people looking for a shortcut like this and therefore redirection with these shouldn't be eliminated like Hose Keeping or maintenance, etc. And in response to the above user, admins (and even stewards) unfortunately get that way most of the time, but I don't think it needs to go to the point of a RfC --YellowFrogger (Talk) 15:15, 25 December 2021 (UTC)[reply]
I'm afraid I don't understand what you're referring to with this comment, except for the RfC bit. --Raidarr (talk) 15:49, 25 December 2021 (UTC)[reply]
I was quoting about what you talked about above (spirit of using abbreviated words), this is something from the template:shortcut --YellowFrogger (Talk) 02:19, 26 December 2021 (UTC)[reply]

Add Interwiki links to my two Wikis

Hi, I want to add Interwiki links to my two Wikis. The detailed information is as follows.

Wiki to be

Prefix (iw_prefix):dw

Url (iw_url):$1


Prefix (iw_prefix):hs

Url (iw_url):$1.html


Prefix (iw_prefix):hsstudy

Url (iw_url):$1


Prefix (iw_prefix):dcm

Url (iw_url):$1


Prefix (iw_prefix):dcmeta

Url (iw_url):$1


Wiki to be (

Prefix (iw_prefix):hs

Url (iw_url):$1.html


Prefix (iw_prefix):hsstudy

Url (iw_url):$1


Prefix (iw_prefix):dcm

Url (iw_url):$1


Prefix (iw_prefix):dcmeta

Url (iw_url):$1


Thanks. @Diamochang - talk | email me - 01:19, 18 December 2021 (UTC)[reply]

@Diamochang: This is Yes check.svg Done at this time, you can visit diamodocswiki and diamowikiwiki for the logs. Ugochimobi (talk) 21:47, 18 December 2021 (UTC)[reply]


  1. Trying to create or delete this page leads to an error.
  2. Trying to import valid XML files also leads to a similar error. Ora & D (talk) 10:44, 19 December 2021 (UTC)[reply]

@Ora & D: What errors are you facing? Agent Isai Talk to me! 10:51, 19 December 2021 (UTC)[reply]

1. Create:
The revision #0 of the page does not exist.
This is usually caused by following an outdated history link to a page that has been deleted. Details can be found in the deletion log.
Fatal exception of type "LogicException".
2. Fatal exception of type "Wikimedia\Rdbms\DBTransactionError". Ora & D (talk) 11:00, 19 December 2021 (UTC)[reply]
This probably should be moved to Phabricator, noting the fatal exception, linking to the permalink to this thread. Dmehus (talk) 06:44, 20 December 2021 (UTC)[reply]
Thanks. It's being handled there. Ora & D (talk) 16:52, 20 December 2021 (UTC)[reply]

Block log message not changing

I was trying to change the block log message for a wiki I run (Decyclopedia), and I noticed that the block log message wasn't changing. I tried looking at MediaWiki help pages to try to figure the problem out. I'm editing MediaWiki:Blocklogentry on that wiki. Tali64³ (talk) 18:26, 20 December 2021 (UTC)[reply]

The message appears to be MediaWiki:Logentry-block-block. I am not sure where, if any, MediaWiki:Blocklogentry is actually used. By the way, using uselang=qqx parameter in the URL will tell you the names of all the messages used on the page. Dylsss (talk) 19:50, 20 December 2021 (UTC)[reply]

My ban, and mental health.

im still around thankfully. Wishing all a merry Christmas. Sorry to be a nuisance but all my wikis are dead, can i possibly get my ban lifted or lightened??? Thank you all. Take care. SperosDurrell (talk) 02:26, 21 December 2021 (UTC)[reply]

You can undo a wiki inactivity in Special:ManageWiki/core of your wiki YellowFrogger (Talk Edits) 02:28, 21 December 2021 (UTC)[reply]
just want to start fresh that's all. Thanks. SperosDurrell (talk) 02:29, 21 December 2021 (UTC)[reply]
It's great to see you around but it would be nice for you to focus on the wiki you already have. Agent Isai Talk to me! 02:31, 21 December 2021 (UTC)[reply]
which one lol? There all dead.... SperosDurrell (talk) 02:34, 21 December 2021 (UTC)[reply]
link, me??? SperosDurrell (talk) 02:38, 21 December 2021 (UTC)[reply]

Mejoras en la piel vector / Improvements in skin vector

Hola. He realizado una propuesta sobre mejoras de la piel vector pero fue desetimada porque excede el alcance técnico de Miraheze.

Encontré que este asunto se está desarrollando en MediaWiki y existe una consulta a la comunidad: Reading/Web/Desktop Improvements/Third prototype testing. Todos pueden participar y experimentar.

Esperemos que pronto se generen los cambios para disminuir la cantidad de caracteres por línea. Lo sugerido es entre 45 a 75. Actualmente, en pantallas de más 1300px caben más de 130 caracteres por línea. La Wikipedia francesa ya adoptó un cambio muy favorable en la piel vector. Saludos a todos. ¡Felicidad y prosperidad! Hugo Ar (talk) 15:27, 21 December 2021 (UTC)[reply]

Translated by Google Translator
Hello. I have made a proposal on vector skin enhancements but it was rejected because it exceeds the technical scope of Miraheze.
I found that this topic is being developed on MediaWiki and there is a community query: Reading/Web/Desktop Improvements/Third prototype testing. Everyone can participate and experiment.
We hope that the changes will be generated soon to reduce the amount of characters per line. The suggested is between 45 to 75. Community Wishlist Survey. Currently, screens larger than 1300px can fit more than 130 characters per line. The French Wikipedia has already adopted a very favorable change in vector skin. Greetings to all. Congratulations and prosperity! Hugo Ar (talk) 15:27, 21 December 2021 (UTC)[reply]
You are trying to switch to the new vector, (as well as the French Wikipedia and Portuguese Wikipedia) and take the old one (legacy vector which is the current one), bu the English wiki and the mediawiki site haven't even done that yet , would be an interesting idea, but let's wait for new updates, both on mediawiki and also on high traffic sites, as the new version is a beta YellowFrogger (Talk Edits) 16:56, 21 December 2021 (UTC)[reply]
Hola. Al parecer puede efectuarse el cambio con esto: / Hello. Apparently the change can be made with this:
$wgVectorDefaultSkinVersion = '2';
$wgVectorDefaultSkinVersionForExistingAccounts = '2';
$wgVectorDefaultSkinVersionForNewAccounts = '2';
$wgVectorIsSearchInHeader = true;
$wgVectorLanguageInHeader = true;
$wgVectorUseWvuiSearch = true;
Saludos / Greetings Hugo Ar (talk) 19:11, 21 December 2021 (UTC)[reply]

Can I limit namespaces?

I dont necessarily need to do this, but it may be nice, could I set user group rights in such a way that some groups can only edit certain namespaces? If not thats not a problem for me but was just wondering. Or maybe limit certain namespaces to certain usergroups? (excluding the editprotected and edit semiprotected userrights). Thanks for the advice! EmperorOctopus (talk) 22:18, 21 December 2021 (UTC)[reply]

You can change in Special:ManageWiki/namespaces page of your wiki, select clicking in "submit" (If you choosed a namespace) and it will have a box with the name: Which userright should be needed to edit this namespace? ($wgNamespaceProtection). You type some user right in it YellowFrogger (Talk Edits) 22:32, 21 December 2021 (UTC)[reply]
Thank You! Ill look when I get home. EmperorOctopus (talk) 01:58, 22 December 2021 (UTC)[reply]
Yeah, so that only has the options for editprotected and editsemiprotected and editinterface. Again what Im asking may not be possible, but Could I limit a new namespace to a custom usergroup? If not that's fine, I'm just curious. Thanks, EmperorOctopus (talk) 03:31, 22 December 2021 (UTC)[reply]
I will see, thanks YellowFrogger (Talk Edits) 03:38, 22 December 2021 (UTC)[reply]

template infobox election not working

Hi, when I try to make the infobox election template it doesnt work and says "Script error: No such module "documentation".Script error: No such module "Check for unknown parameters"." And whenever I put with {Infobox election} (with two of these brackets{ on each side)it just says ""Template:Infobox election""

Any help will be appreciated, thanks Papito19 (talk) 00:52, 22 December 2021 (UTC)[reply]

When "No such module" error appears, it is because there are no modules to make the infobox work. To fix this, do the following, for example, when EX: "Error no module of this type: Yesno", then you will have to create a module with the name yesno from Wikipedia. Anything invite me to check your wiki infoboxes YellowFrogger (Talk Edits) 01:05, 22 December 2021 (UTC)[reply]
where do you put "yesno" sorry im new Papito19 (talk) 01:59, 22 December 2021 (UTC)[reply]
Invite me to your wiki for me to review if you want YellowFrogger (Talk Edits) 03:38, 22 December 2021 (UTC)[reply]


Hello! ManageWiki has an EditNotify extension. As I understand it, it allows you to notify about fresh changes through the Echo interface. But when I connected it on my wiki, I did not find anything like this. So what does this extension do? DecabristM (talk) 10:12, 23 December 2021 (UTC)[reply]

Hello! The extension allows registered user to get notified for:
  • Creation of new pages
  • Edit to existing pages - It includes notification to all changes.
  • Change in specific template field - Users get the notification when there is a change in template field
  • Change in specific template field to specific template value - Users are notified when there is a change in template field value

All users who are subscribed for any of the event listed above will be notified for them with a simple alert message (Echo notification) as well as an email. The possible sets of pages for which users can choose to be notified are:

  • All pages - keep track of change or creation of all pages.
  • All pages in one or more namespaces
  • All pages in one or more categories

Source: --YellowFrogger (Talk) 22:44, 23 December 2021 (UTC)[reply]

I saw it. I don't understand where the list of attendees is configured to receive these notifications. The documentation only offers a way to change the system files, which I cannot do. DecabristM (talk) 09:07, 24 December 2021 (UTC)[reply]
Please file a Phabricator task and we'll help you set it up after Christmas. All config files are public but we'll be happy to help you make the relevant changes and deploy it.
Side note: I'm not 100% sure why something that relies so heavily on setup by us is available for you to turn on. ~ RhinosF1 - (chat)· acc· c - (     online) 09:35, 24 December 2021 (UTC)[reply]
I think the best way would be to let the bureaucrats configure this extension via ManageWiki or remove it from those available on ManageWiki. DecabristM (talk) 11:21, 25 December 2021 (UTC)[reply]
I fully agree that getting it in ManageWiki somehow needs to be done but we're unfortunately without our main developer at the moment and it's the middle of the festive season. ~ RhinosF1 - (chat)· acc· c - (     online) 11:24, 25 December 2021 (UTC)[reply]
I sent a request to the phabricator. DecabristM (talk) 11:58, 25 December 2021 (UTC)[reply]

Remove the space between my two tabs

Hi there, I have created two templates, unfortunately there is a gap between them, as you can see on this page : I would like to have them "glued" together. How do I remove the space? Thanks in advance. Darkrai18 (talk) 11:46, 23 December 2021 (UTC)[reply]

You mean you want the 2 tables to be sticked together?  Anpang📨  11:49, 23 December 2021 (UTC)[reply]
Basically, yes. Darkrai18 (talk) 12:01, 23 December 2021 (UTC)[reply]
Something like this:
{| class="wikitable" style="margin-bottom:-1px"
! Header text !! Header text !! Header text
| Example || Example || Example
| Example || Example || Example
{| class="wikitable" style="margin-top:0px"
! Header text !! Header text !! Header text
| Example || Example || Example
| Example || Example || Example

Which is:

Header text Header text Header text
Example Example Example
Example Example Example
Header text Header text Header text
Example Example Example
Example Example Example
Explaination: Tables are seperated because they have margin values, here in the style= css the top and bottom margins have been set to 0, but the bottom border of the top table will still overlap the top border of the bottom table which will make the border thick so the bottom margin of the top table needs to be -1 instead of 0.  Anpang📨  12:34, 23 December 2021 (UTC)[reply]
I did not understand everything... Concretely, what do I have to change ? Darkrai18 (talk) 12:55, 23 December 2021 (UTC)[reply]

Hello, Darkrai18


{| class="wikitable" style="margin-bottom:-1px;"
! A partir de 2009!!
| '''''[[Fast and Furious (franchise)|Fast and Furious]]''''' || [[Gisèle Yashar]]

{| class="wikitable" style="margin-top:0;"
! A partir de 2016!!
| '''[[Univers étendu DC]]'''|| [[Wonder Woman (Univers étendu DC)|Wonder Woman]]

A partir de 2009
Fast and Furious Gisèle Yashar
A partir de 2016
Univers étendu DC Wonder Woman

Greetings. Hugo Ar (talk) 14:46, 24 December 2021 (UTC)[reply]

To add, if you want the width of the 2 tables to be matching, you can use 1 table:
{| class="wikitable"
! A partir de 2009!!
| '''''[[Fast and Furious (franchise)|Fast and Furious]]''''' || [[Gisèle Yashar]]
! A partir de 2016!!
| '''[[Univers étendu DC]]'''|| [[Wonder Woman (Univers étendu DC)|Wonder Woman]]

Which results in:

A partir de 2009
Fast and Furious Gisèle Yashar
A partir de 2016
Univers étendu DC Wonder Woman

Interwiki table

Could you please

  1. Add the prefix s to$1, and
  2. Delete the interlanguage prefix en,

In the Interwiki table of XComhghall Wiki?

Thank you very much. — XComhghall (talk) 22:35, 23 December 2021 (UTC)[reply]

@Ugochimobi: --YellowFrogger (Talk) 22:40, 23 December 2021 (UTC)[reply]
This is Yes check.svg Done, thanks. --  Joseph  TB  CT  CA  23:08, 23 December 2021 (UTC)[reply]


I wondered how to use Huggle with Miraheze. I'd like to continue anti-vandalism efforts easier for the wikis that get vandalized the most. -- Cheers, Bukkit ( TalkAll Contribs ) 00:28, 24 December 2021 (UTC)[reply]

The Huggle is a great alternative to Twinkle yes, but I ask if it needs to be rollback to revert in Huggle. And also: the recent changes here from Meta is a bit stalled on vandalism; there is not much vandalism here. Even so, vandalism starts mainly with IP addresses. --YellowFrogger (Talk) 00:39, 24 December 2021 (UTC)[reply]
@Bukkit: Huggle is a tool which was designed with the Wikimedia movement in mind. It seems to require server-side software to be deployed and configured across multiple wikis so this is something that cannot be used on Miraheze. Agent Isai Talk to me! 00:43, 24 December 2021 (UTC)[reply]

Request for Feedback: Adding new default extensions

Request for overturn on Requests for Comment/Local IP Block Exemption

Problem with Tab

Hi there, I have created a "Tab" template for my pages. Problem, I would like the two ends to be rounded. However, this is only the case on one end. It is only rounded when my Tab has this shape:

|tab4=Capabilities and equipment

Either when it's staggered. My page link : My template link : Thanks in advance. Darkrai18 (talk) 11:35, 28 December 2021 (UTC)[reply]

The two ends are already rounded?
Or you mean all 4 corners to be rounded?
Then border-radius: (how much round)px should work  Anpang📨  11:45, 28 December 2021 (UTC)[reply]
I'm talking about this : Tab1111111.PNG. I would like both ends to be rounded. Darkrai18 (talk) 11:58, 28 December 2021 (UTC)[reply]
Oh, then that I have no idea. Maybe an {{if: checking if the next one exists, if not set to rounded else not rounded and continue?
Like i have no idea....  Anpang📨  12:02, 28 December 2021 (UTC)[reply]
Thanks for trying. I'm waiting for more answers. Darkrai18 (talk) 12:32, 28 December 2021 (UTC)[reply]
This current theme of your wiki (mw:Skin:Monobook) is weird. But let's show the rounded borders preview CSS in the Vector theme:
border-top-left-radius: 2em; border-bottom-left-radius: 2em;
--YellowFrogger (Talk) 16:44, 28 December 2021 (UTC)[reply]
@Darkrai18: Your template is too complex for me to locate where to added Template:Border-radius in the other tabs. I have recreated it in a simpler design on the Test Wiki

Comments disabled

On 28 December 2021, we experienced severe performance issues globally which led to hours long downtime across all Miraheze wikis. While investigating the issue, we found that the commentlist API module (used by the Comments extension) was at fault as it used an excessive amount of resources whenever called and disabled it which seems to have put an end to the hours of downtime. However, as a result of the commentlist API module being disabled, the Comments extension cannot load comments. We apologize for the inconvenience and are actively working with the upstream developers of the extension to find a solution to this and to re-enable the API module as soon as possible.

In the meanwhile, we encourage you to consider alternatives to the Comments extension such as CommentStreams.

Please note that even though the API module is disabled, extensions that rely on Comments such as BlogPage are not affected and can be used as normal. Agent Isai Talk to me! 01:31, 30 December 2021 (UTC)[reply]

This here will have an impact mainly on Qualitipedia wikis, which often use these comments in their articles from what I see. --YellowFrogger (Talk) 01:37, 30 December 2021 (UTC)[reply]
This is correct; QP cannot reasonably just consider alternatives outright given the lengthy history of existing comments and the familiarity of their use, and losing history is indeed an impact. Then when switched a new history is made to wipe out the old one, or the plugin is switched back to result in a blind period for comment history since from what I understand the data is not compatible between them. I understand Miraheze is doing what it can, but in case of the above it does have an impact and it would be preferable to see a fix than to make an intermediate switch. --Raidarr (talk) 17:25, 30 December 2021 (UTC)[reply]
We migrated from CommentStreams... How difficult is to do a module that works and don't spent tons of resources? All the ones we have tried have performance issues or were difficult to comment... Thanks for resolving the downtime :) Jakeukalane (talk) 09:28, 30 December 2021 (UTC)[reply]
@Jakeukalane: Ultimately, it would depend on the upstream maintainer of the extension. A variety of factors come into play such as the complexity of the issue and whether the maintainer has the time to fix the issue. Because of that, we can't give you an ETA unfortunately, sorry! Disabling an API module isn't something we take lightly, it was an emergency measure taken to combat the hours of downtime we suffered yesterday. We are actively working with the maintainer to hopefully find a fix and restore functionality of the Comments extension. However, in the meanwhile, have you tried revisiting CommentStreams? The latest update gave it a facelift and it acts snappier, perhaps you may like that as a temporary alternative. Agent Isai Talk to me! 09:51, 30 December 2021 (UTC)[reply]
@Agent Isai: There was some confusion on my part. We migrated to CommentStreams but it is not working right now. That lead me to believe that we had the problematic comment extension. Greetings. Jakeukalane (talk) 12:55, 30 December 2021 (UTC)[reply]
I still have Miraheze taking 7 seconds to boot. DecabristM (talk) 16:49, 30 December 2021 (UTC)[reply]
@DecabristM: We still aren't perfect, but the actions taken did resolve the major downtime and improved things.

A few concerns:

  1. When will this be back?
  2. What is CommentStreams exactly? Can I perhaps see a picture of what it looks like, since the MediaWiki page does not have one. I also would not recommend the Commentbox extension as it just edits the page which is quite annoying.
  3. I wonder if this is why it would not let me use the reply button to reply here, so I had to actually edit the page. Blubabluba9990 (talk) 17:42, 31 December 2021 (UTC)[reply]
I figured out what CommentStreams is, since I enabled it on my wiki. Blubabluba9990 (talk) 19:35, 31 December 2021 (UTC)[reply]

Bug with the article counter

Hey! I am using the article counter on the main page for readers. But despite the fact that there are already three articles on my wiki, the article counter has been displaying zero for several days. What could be the problem? DecabristM (talk) 13:02, 30 December 2021 (UTC)[reply]

@DecabristM: Please note that MediaWiki only counts pages with links to them so if a page doesn't have any other pages linking to it, it won't show up in Special:Statistics. Additionally, Statistics gets stuck every so often but gets manually refreshed every 2 weeks so if all your pages have links to each other than Statistics should show them once they get refreshed. Agent Isai Talk to me! 14:14, 30 December 2021 (UTC)[reply]
Yes, the problem was missing links. Thanks! DecabristM (talk) 16:45, 30 December 2021 (UTC)[reply]
As Agent Isai said above (even if the page is large and has the main namespace, if it doesn't have links, it doesn't count as articles). And, very small pages in the main namespace don't count as articles, but as pages. --YellowFrogger (Talk) 17:41, 30 December 2021 (UTC)[reply]

Problem with Tab, part 2

Hey there. The tab works very well, I'm very happy with it and I thank you all. I made some modifications but a problem persists: The text appears in white when I'm not on the main page, while I would like it to appear in black when I'm not on the said page. For example, here it appears in white and it's fine : But here it stays white : I would like it to be black. Do you have a solution? Thanks in advance. Darkrai18 (talk) 14:03, 30 December 2021 (UTC) Darkrai18 (talk) 14:03, 30 December 2021 (UTC)[reply]

Thank you very much, @PercyUK:. Darkrai18 (talk) 16:31, 30 December 2021 (UTC)[reply]

Issue with our wikis

Hi, I am one of the admins at the music reception wikis. Today we turned on video functionality for the best music wiki, and it appears it allows us to import videos properly. However, there is an issue. When the video is in, it says "Click to load content" which I do not know why, do you know why it appears this way and how we could fix it? FullInterTurn (talk) 22:33, 30 December 2021 (UTC)[reply]

I would expect an admin to talk about this first, but as I write this review no response. With that, I advise you then, as it is an error of an extension, to open a ticket in the phabricator so they will probably check if there is an error in the extension that is preventing such thing. And if you want, you can invite me to review the wiki. --YellowFrogger (Talk) 01:34, 31 December 2021 (UTC)[reply]

A bit of a problem

So I went to reply to the notice about the Comments extension being (hopefully temporarily) disabled, but when I clicked the reply button it took a few seconds to load and then displayed an error screen. I had to end up editing the actual page itself in order to reply. I do hope all of this is fixed soon because Miraheze is the last good wiki-hosting platform: Fandom has multiple problems, ShoutWiki is broken and inactive, Wikisite and EditThis run on ancient MediaWiki software and are inactive, and all of the other wiki hosts and wiki farms use other software and are pay-to-use. Blubabluba9990 (talk) 17:54, 31 December 2021 (UTC)[reply]

Oh and that isn't the only issue. When you click Save Changes, it takes like 30 seconds to save the changes. Blubabluba9990 (talk) 17:55, 31 December 2021 (UTC)[reply]
@Blubabluba9990: See the section above. Current comments extension is currently disabled due to a problem. --YellowFrogger (Talk) 22:36, 31 December 2021 (UTC)[reply]
I thought that was talking about the comments that can be created with the "comments" tag, not the thing that lets you reply to talk pages without editing the page. Or is it both. I'm confused. Blubabluba9990 (talk) 20:14, 1 January 2022 (UTC)[reply]
Specify what you are saying, you yourself stated that you are "confused". --YellowFrogger (Talk) 23:31, 1 January 2022 (UTC)[reply]
Which comment extension are you referring to? I assumed you were referring to the one that allows the <comments/> tag, but you are saying it is also that creates the reply button that allows you to reply to talk pages here, which means it is both extensions. Or are they part of the same extension. Blubabluba9990 (talk) 15:21, 2 January 2022 (UTC)[reply]
There is also the fact that for some reason it takes a minute to save edits. I do not know why that is. Blubabluba9990 (talk) 15:27, 2 January 2022 (UTC)[reply]

How do I post a template multiple times to the same page without "Pages using duplicate arguments in template calls"?

Is there a way around this? I want my user to fill out a form that selects some values and then have those values displayed simultaneously in two different spots within the page. Thanks for your help! ParentRatings (talk) 21:43, 31 December 2021 (UTC)[reply]

@ParentRatings: This is happening because you are using two parameters with the same name (duplicated). To avoid this, you should set the parameter and remove the duplicate, and leave only one. What is your wiki? Could you invite me to analyze the error? --YellowFrogger (Talk) 22:32, 31 December 2021 (UTC)[reply]

Interwiki changes for planetariumwiki

Please edit the following Interwiki prefixes.

Prefix: wikitroid
Metroid Wiki
Prefix: metroidwiki

No need for transclusion or forwarding on either. dross (tcg) 07:22, 1 January 2022 (UTC)[reply]

@Dross: Yes check.svg Done. Consult your local Special:Log/interwiki for more information. Agent Isai Talk to me! 07:31, 1 January 2022 (UTC)[reply]

Fixing collapsible lists for the Sidebar template

Hello. I'm currently having issues with templating on my wiki. My current iteration of the Sidebar with collapsible lists template has the appearance of a normal Sidebar, but the collapsible lists function of the template doesn't seem to work, making it so that only the name of the list is shown without giving the option of expanding its contents. See this if you want a direct example of the issue, this for the template in question.

As far as I know, every template and module that is used by the Sidebar with collapsible lists template is a direct copy from Wikipedia or other wiki templates, so I'm stumped as to what could be causing the issue here. Sylepieus (talk) 16:33, 1 January 2022 (UTC)[reply]

Sylepieus, it seems that the wiki is private. Only members and administrators can view the pages. Greetings. Hugo Ar (talk) 16:01, 2 January 2022 (UTC)[reply]
Hugo Ar My bad, it should be fixed now. Appreciate the heads up. Sylepieus (talk) 20:11, 2 January 2022 (UTC)[reply]
Hola Sylepieus. La plantilla llama al módulo: Sidebar. Lo que veo en el resumen de edición del módulo es que al módulo lo importaste desde la Wikipedia en inglés. Pero, sin embargo, el código no es igual.
¿Puede ser esta la causa de que no funcione como lo deseas? ¿O puede ser que aun haya que incorporar otros módulos?
Translate by Google traductor
Hello Sylepieus. The template calls the module: Sidebar. What I see in the module edit summary is that you imported the module from the English Wikipedia. But nevertheless, the code is not the same.
Could this be the cause of it not working the way you want it to? Or could it be that other modules still have to be incorporated? Best regards and good start to 2022. Hugo Ar (talk) 20:50, 2 January 2022 (UTC)[reply]
Hugo Ar, changing over the Sidebar module seems to have fixed the collapsible lists part of the issue, though another issue seems to have cropped up as a result. Looking at this template for reference, it's trying to transclude Module:Sidebar/styles.css. It seems that the issue here now is that Module:Sidebar/styles.css is stuck in plaintext and doesn't function as code, even if it's directly copied from en Wikipedia. Do you know how I could fix this? Thanks in advance. Sylepieus (talk) 07:04, 3 January 2022 (UTC)[reply]
Sylepieus, You must activate Template Styles. To do this go to y and activate:       TemplateStyles and       TemplateStylesExtender. Greetings. Hugo Ar (talk) 12:09, 3 January 2022 (UTC)[reply]
Hugo Ar, I've turned on both the extensions as you've advised. There's some progress since the sample template now shows an error message in editing previews, but the issue with the code in Module:Sidebar/styles.css being in plaintext still persists. If it helps, the error message from the sample template says Page Module:Sidebar/styles.css must have content model "Sanitized CSS" for TemplateStyles (current model is "plain text"). Sylepieus (talk) 16:29, 3 January 2022 (UTC)[reply]
Sylepieus, Try activating the CSS extension:       CSS. Greetings. Hugo Ar (talk) 16:57, 3 January 2022 (UTC)[reply]
Hugo Ar, I've already activated the CSS extension in advance. The issue still persists. Sylepieus (talk) 17:07, 3 January 2022 (UTC)[reply]
Sylepieus, te falta configurar algo más porque veo que ocurre lo mismo en otras páginas similares como, por ejemplo, esta:
En la wiki que administro no tengo módulos ni plantillas con hojas de estilo CSS. Todo los estilos los agrego en MediaWiki:Common.css
Mi sugerencia: crea una cuenta en Phabricator, describe la situación y solicita que te indiquen el cambio de configuración para que todo funcione correctamente:
Saludos cordiales. Hugo Ar (talk) 17:54, 3 January 2022 (UTC)[reply]
Translated by Google Translator
Sylepieus, you need to configure something else because I see the same thing happening on other similar pages, such as this one:
In the wiki that I manage I do not have modules or templates with CSS stylesheets. All the styles I add in MediaWiki: Common.css
My suggestion: create an account in Phabricator, describe the situation and request that they tell you the configuration change so that everything works correctly:
Kind regards. Hugo Ar (talk) 17:54, 3 January 2022 (UTC)[reply]

Miraheze's relationship to Orain

I have been wondering this for a while, but what exactly is Miraheze's relationship to Orain. I have seen many conflicting answers about it: Some have said it is a direct predecessor, others have said that it is a spiritual predecessor, I have seen people that Miraheze was founded by former Orain staff, but it seems like the exact relationship (or if there even is one) remains ambiguous. In addition, the Orain Meta home page redirects to the Miraheze Meta home page, which implies that Miraheze is at least partially a successor to Miraheze. In addition, this says that Miraheze was originally Orain. Despite all of this, Orain doesn't seem to be mentioned much, and wasn't mentioned in Miraheze's five-year anniversary celebration. Blubabluba9990 (talk) 16:28, 2 January 2022 (UTC)[reply]

Miraheze and Orain are often linked together because both John and Southparkfan were volunteers on Orain for a long time. In July 2015, they left Orain to make Miraheze but Orain continued to exist as its own independent wiki farm. In September 2015 however, Orain was compromised and all of it's server data deleted. Many wikis on Orain moved over to Miraheze as a result which is why Orain and Miraheze have a sort of link together, Miraheze is a bit like Orain's de facto successor as many Orain wikis moved over to Miraheze and so did a lot of the volunteers and users but in a technical sense, Orain and Miraheze are completely unrelated. Since Orain was no more after 2015, I'm guessing Miraheze bought to redirect users who thought Orain was still in existence to us as we held a nice portion of Orain's user base. Because we're not technically related to Orain, there's really no need to mention it as it's just a thing of the past. Agent Isai Talk to me! 16:37, 2 January 2022 (UTC)[reply]
Blubabluba9990, officially, Miraheze and Orain have no direct relationship. Both were/are volunteer run and funded wiki farms, but with different purposes and visions. If trying to quantify the relationship, you could say was inspired by, for better or for worse, Orain. When Orain collapsed, the domain name expired, and Miraheze purchased the domain name and redirected it to Miraheze. Some volunteers also had Orain accounts, but other than those points, that's about the extent of the connection. Dmehus (talk) 16:39, 2 January 2022 (UTC)[reply]
Ok, that makes sense. I had figured that Miraheze could somewhat be considered Orain's spiritual successor. Blubabluba9990 (talk) 17:07, 2 January 2022 (UTC)[reply]
@Blubabluba9990: Orain was founded in 2013 by Wikipedians and was attacked in 2015 and do not have relationship with Miraheze. And as you can see in this archive page, some Orain users are the same as Miraheze users today. --YellowFrogger (Talk) 23:02, 2 January 2022 (UTC)[reply]

Math editor

Hello, it seems math equations editor is missing on this wiki. How can I get it? RedFox (talk) 17:43, 2 January 2022 (UTC)[reply]

@RedFox: Could you elaborate? Do you mean on this wiki (Miraheze Meta) or your wiki? Agent Isai Talk to me! 17:46, 2 January 2022 (UTC)[reply]
Agent Isai, I mean my own wiki called mathzadachi. It was created today. Thanks for your quick answer. — Preceding unsigned comment added by RedFox (talkcontribs)
You can enable it in your Special:ManageWiki/extensions interface under 'Parser hooks'. --Raidarr (talk) 20:30, 2 January 2022 (UTC)[reply]

Miraheze hit 5,000 wikis!

I was looking at the main page and saw that Miraheze is now hosting over 5,000 wikis! That's a great achievement for a wiki farm funded solely by donations. How should we celebrate this accomplishment? Tali64³ (talk) 01:13, 3 January 2022 (UTC)[reply]

Tali64³, yep, that's right. We have hit 5,000 wikis before, back in early 2020, but that was largely because the wiki closure was broken, so long dormant wikis weren't being appropriately marked as deleted. Dmehus (talk) 01:19, 3 January 2022 (UTC)[reply]
Congrats!  Anpang📨  01:26, 3 January 2022 (UTC)[reply]
Milestones usually don't matter that much, especially when it's about the number of wikis (soon the number will go down by a huge number for deleted wikis, currently there are too many inactive or closed wikis). --YellowFrogger (Talk) 01:27, 3 January 2022 (UTC)[reply]
Well, I was thinking about what you said, and I decided to start the Save the Inactive Wikis coalition to save inactive wikis. Would you like to join? Tali64³ (talk) 03:32, 3 January 2022 (UTC)[reply]
However, there are more interesting things to do. An inactive wiki means the owner is sick of it. --YellowFrogger (Talk) 17:14, 3 January 2022 (UTC)[reply]

My talk page goes haywire

This is Katsumi, an admin from Crappy Games Wiki.

It seems my talk page has gone haywire of some sort. I've tried to add this topic to my talk page...

Title: CGW admins visited Hololive Wiki?
Content (in wikitext):

So, I've played a bit with [[Special:CentralAuth]].

It seems that some of CGW's admins have visited [[mh:hololive:Main Page|Hololive Wiki]]<sup>(me included)</sup>.

I know that [[Blog:On MSI jumping on the VTuber bandwagon|the whole VTuber thing is a sensitive topic on the wiki]], but still, I'm very curious about why some of the admins are simping Hololive girls.

{| class="wikitable"
| style="text-align:center;" |[[File:Symbol support vote.svg|20px|link=]]
| style="text-align:center;" |[[File:Symbol oppose vote.svg|20px|link=]]
| style="text-align:center;" |[[File:Symbol oppose vote.svg|20px|link=]]
| style="text-align:center;" |[[File:Symbol support vote.svg|20px|link=]]
| style="text-align:center;" |[[File:Symbol oppose vote.svg|20px|link=]]
| style="text-align:center;" |[[File:Symbol oppose vote.svg|20px|link=]]
| style="text-align:center;" |[[File:Symbol oppose vote.svg|20px|link=]]
| colspan="3" |''No information''
| style="text-align:center;" |[[File:Symbol support vote.svg|20px|link=]]
| style="text-align:center;" |[[File:Symbol oppose vote.svg|20px|link=]]
| style="text-align:center;" |[[File:Symbol oppose vote.svg|20px|link=]]
|[[User:Katsumi a.k.a. Upperdecker2562|Katsumi]]
| style="text-align:center;" |[[File:Symbol support vote.svg|20px|link=]]
| style="text-align:center;" |[[File:Symbol oppose vote.svg|20px|link=]]
| style="text-align:center;" |[[File:Symbol oppose vote.svg|20px|link=]]
| style="text-align:center;" |[[File:Symbol oppose vote.svg|20px|link=]]
| colspan="3" |''No information''
| style="text-align:center;" |[[File:Symbol oppose vote.svg|20px|link=]]
| colspan="3" |''No information''
|[[User:Mr. Dready|Mr. Dready]]
| style="text-align:center;" |[[File:Symbol support vote.svg|20px|link=]]
| style="text-align:center;" |[[File:Symbol oppose vote.svg|20px|link=]]
| style="text-align:center;" |[[File:Symbol oppose vote.svg|20px|link=]]
| style="text-align:center;" |[[File:Symbol oppose vote.svg|20px|link=]]
| colspan="3" |''No information''
| style="text-align:center;" |[[File:Symbol support vote.svg|20px|link=]]
| style="text-align:center;" |[[File:Symbol oppose vote.svg|20px|link=]]
| style="text-align:center;" |[[File:Symbol oppose vote.svg|20px|link=]]
| style="text-align:center;" |[[File:Symbol oppose vote.svg|20px|link=]]
| colspan="3" |''No information''
| style="text-align:center;" |[[File:Symbol oppose vote.svg|20px|link=]]
| colspan="3" |''No information''
| style="text-align:center;" |[[File:Symbol support vote.svg|20px|link=]]
| style="text-align:center;" |[[File:Symbol oppose vote.svg|20px|link=]]
| style="text-align:center;" |[[File:Symbol oppose vote.svg|20px|link=]]

You know what they say...
{{Quote|Weebs tend to be weird. What did you expect?|[[User:Allistayrian|Allistayrian]]}}


If I tell it to parse and render the following text, it outputs this message...

Unable to transfer content: Error contacting the server for conversion between wikitext and HTML. Please check your Internet connection or try again later if the problem persists. If you still get this error please file a bug

and if I try to add the topic, it gives me an error...

Caught exception of type Flow\Exception\NoParserException

However, if I try to create a topic with much fewer characters (about 10-30 characters), it accepts that. Strange...

Is it because of the recent update? 🦖️ my Name is Katsumi(BA↗RI↘BA↗RI↘)
KamenRiderRevice-logo.webp talk
KamenRiderRevice-logo.webp contributions
03:26, 3 January 2022 (UTC)
It works for me, so its probably about the wikitext entered in your topic  Anpang📨  03:49, 3 January 2022 (UTC)[reply]
Your "test" is 192 characters long. Mine is 371, approximately twice as long as your "test". 🦖️ my Name is Katsumi(BA↗RI↘BA↗RI↘) 04:11, 3 January 2022 (UTC)
Mathematically speaking, 192 to 370 is exactly one time higher, being not that far off, particularly in terms of characters. On the subject of the bug, he claims it is caused by your connection. Anyway, if this persists, I suggest opening a ticket in the phabricator because the extension. --YellowFrogger (Talk) 04:35, 3 January 2022 (UTC)[reply]
Geeze, the signature formatting in this section... Anyway, I tested locally with a block of my own and your post, and the issue here is either temporary or local. At this point issues actually don't have much to do with the version upgrade. Rather the migrations Miraheze is performing to new hardware, which started not long after the update. While it may have been your connection, I can't rule out that you might have been struck with one of the temporary glitches Found the error, investigating locally. Per the local post, all I can advise right now is patience; unless a persistent bug can be reported, Miraheze Tech is not well equipped to resolve the various phantom issues that are occurring around this time. They are inevitable during the upgrade process, which from what I hear can/will extend into early next month. --Raidarr (talk) 10:25, 3 January 2022 (UTC)[reply]
Upon conferring with SRE and doing more tests, the trouble is images. The migrations I mentioned above have specifically made images the most unstable part of Miraheze right now, and trying to post the images into a dynamic form like StructuredDiscussions will cause it to fail. I'd suggest making the post without them and being light on their use in general until the migration is complete and SRE gives word to that effect. Issue is known and basically unfixable right now; no point filing a phab task unless SRE advises it in this thread. --Raidarr (talk) 10:57, 3 January 2022 (UTC)[reply]

Upcoming changes and performance issues

Valued Miraheze community members,

As you all know very well, Miraheze's commitment to our users is to provide the best MediaWiki hosting for free. In keeping with that commitment, Miraheze is pleased to announce our newest data centre, SCSVG! Instead of renting out servers, Miraheze will finally own it's own hardware for the first time ever. With the addition of this data centre to our server lineup, we will be able to offer our users a much better, faster and smoother experience. For more information on this, please checkout this Phabricator post.

In light of that, we have begun the migration process to our new servers. As you all probably know, Miraheze has faced some performance issues these past few months as we've outgrown our current servers. These new servers will hopefully resolve most if not all of the issues we've faced in the past few months regarding performance (including 502 "Bad Gateway" and 503 "Backend fetch failed" errors). In the process of migrating however, you will likely notice (and probably already have noticed) degraded performance and increased error rates. The migration has exacerbated our current performance issues as, on top of having to serve normal user traffic, some of our current servers are now also copying their files over to the new servers which means that there's an increased strain on them. This means you may notice 502 and 503 errors on some pages which loaded before, especially those pages with lots of images or templates. During this period too, we may need to temporarily suspend some actions such as image-related actions and wiki requests/creations. During this migration period, it may become necessary to temporarily disrupt some processes such as image related actions and wiki creations/changes. It too may be necessary to temporarily disrupt service completely or place wikis on read-only mode. Should this be necessary (we will try to avoid any and all service disruption where possible), we will inform the community with a weeks notice before the disruption occurs.

We know how inconvenient this may be but our hope is that with these changes, we will hopefully resolve all (or at least most) of the performance issues which have plagued Miraheze for these past few months. As always, we thank you for being part of the Miraheze community and we hope to be able to serve you all better in 2022. If you have any questions regarding this, please do not hesitate to reply to this thread or ask on our Discord/IRC channels.

On behalf of Site Reliability Engineering,
Agent Isai (talk) 09:59, 3 January 2022 (UTC)[reply]

Thank you very much for the message. This has answered to my question. Kind regards. Hugo Ar (talk) 12:24, 3 January 2022 (UTC)[reply]
Is there a specific time of the day when the servers are less busy? I need to make approximately 200 edits (with responsible pause between them, e.g. 60 seconds) that update Cargo tables (this wiki has software documentation, and new version of this software was released today). Edward Chernenko (talk) 15:13, 3 January 2022 (UTC)[reply]
@Edward Chernenko: Server performance issues are generally random and are not always tied to server busyness or idleness so we can't really give a timeframe for when it would be best for you to do those edits. Agent Isai Talk to me! 15:19, 3 January 2022 (UTC)[reply]
Glad you noticed this error, which happens every day (and complicates saving edits). And we hope to get a new server in 2022, as promised. --YellowFrogger (Talk) 15:36, 3 January 2022 (UTC)[reply]