Community noticeboard

Improving password standards on Miraheze

 * The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
 * Site Reliability Engineering would like to thank all participants in this Request for Feedback for sharing their thoughts, comments and concerns. Your feedback is very important to us and always plays an important role in any decision-making and we assure you that we will take all of this feedback into consideration. For more technical information on this task, please see T7713. Thank you! Agent Isai  Talk to me! 03:57, 23 November 2021 (UTC)

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)


 * 1) 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
 * 2) 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)
 * How is the server protected against such attacks? I think that adding a one second delay after each failed login attempt for a specific user name and IP would prevent such attacks from beeing successful, am I wrong? WHen yes, where is the flow in my considerations? LilyLilyu - smile.svg talk and I will listen · Lilypond Wiki 08:13, 11 November 2021 (UTC)
 * 1) 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)
 * 1) 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)
 * 2) 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)
 * 1) Pls do not change the current standards for passwords on Miraheze. I totally agree with Spike that everyone is free to chose a password as long as he likes. I would really hate to change my Miraheze passwords. All these password requirements (special character, number, small/big letter etc.) on many websites are really annoying me, so pls do not introduce a new password policy, thank you, LilyLilyu - smile.svg talk and I will listen · Lilypond Wiki 21:29, 10 November 2021 (UTC)
 * 2) Please DO increase password security. This is common sense, and a reality online to protect people's accounts from being easily broken into. I use a password manager that generates random string 20+ character passwords. Working in tech, I can say that increases in password security is just the way things are going to keep modernizing. Fighting that makes little sense because it's going to have to be done elsewhere eventually anyhow and is increasingly insisted on, on other sites. Insecure accounts can affect the Miraheze community because of the unified login; these logins being usable on other wikis can be problematic when an account is easily broken into. I would hope people would consider please keeping up with the tech and being realistic about what that often looks like today. CrystalClear (talk) 22:10, 10 November 2021 (UTC)
 * This is frankly not my experience even including services like Discord, Protonmail and Gmail (though Gmail is aggressive in pushing alternative functions anyways). The path of inevitability is not as clear cut as this would make it seem, at least from allegorical experience that would be easy to find. Though this is not to say that these password changes wouldn't have some benefit, and that people shouldn't be going well past them anyways. But frankly, unless you have responsibility that obliges you to more cutting edge protection, it's discretion I'd rather see users retain until it is demonstrably no longer viable on the internet. --Raidarr (talk) 09:18, 11 November 2021 (UTC)
 * 1) I do not see a strong need to increase the password requirements as proposed. As with K6ka's comment, I do  increased password security and two-factor authentication for users holding global groups (to be clear, wiki creator and interwiki administrator should not count as global groups for this purpose). I'm speaking of the SRE, Trust and Safety, and Stewards groups, principally because the   group on Miraheze is not the same as the   group on other wikis, as Miraheze has ManageWiki which provides for the granting of user group permissions without having to have the   user right that would otherwise provide access to the most sensitive, restricted user groups. I also feel that twelve characters is too much, but would support a 9-10 character minimum, with a combination of a minimum of one capitalized character, one non-alphanumeric character, and a mix of numeric and alphabetic characters. Dmehus (talk) 01:54, 15 November 2021 (UTC)
 * 2) I this as well. Coming from a company where this has been mandatory since years I would like to have this level of security here as well, especially because of the global login. Password managers can deal with even longer PWs, just saying. Soukupmi (talk) 07:58, 15 November 2021 (UTC)
 * 3) You say "latest security standards", yet provide no evidence for how this is considered to be so. Considering that I haven't seen any widely used platforms make such a change to password length, this change seems to lack any sort of proper reason behind it from what I can see. K599 (talk) 20:53, 15 November 2021 (UTC)
 * 4) It is my opinion that in this matter it is necessary to take a balanced and reasonable approach rather than a overreaching one. Unlike some comments above suggest I do not believe that it is unreasonable to require a certain password length and I think this is a sensible approach. That being said I do not agree with imposing a 12 character password for all users indiscriminately. This is because as many users have said before me the SRE team does not provide us with any justification or evidence to justify such a measure. If there have not been any accounts that have been hijacked why is it necessary to take such a measure right now? Is there a security risk we do not know about? I believe that in terms of regular users there is no need to change the current requirements and that users with low level access should make their own decisions regarding password length. I have personally not seen another website that has such strict requirements for lay-users. However, I do think that all global groups with significant power (such as Stewards, System Administrators and Global Sysops) should have this requirement as an extra safety precaution. I would not necessarily disagree with local groups such as administrator and bureaucrat having the requirement but I tend to lean towards the direction of them not having this requirement for the time being unless an actual need is proven. In conclusion, my current opinion is that an all encompassing requirement is inappropriate at the time but I would be willing to change my opinion if the SRE team will provide me with a reasoned explanation and justification for these measures other than just to be very careful. To be more clear after reading all the comments again my opinion is closest to that of Dmehus which I would support and which I find the most reasoned. --DeeM28 (talk) 20:12, 16 November 2021 (UTC)


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

Request for interwiki prefix on mtccs
Please add this prefix to mtccs: Thanks. Emojiwiki (talk) 13:38, 10 November 2021 (UTC)
 * and  to


 * ✅, see your local mh:mtccs:Special:Log/interwiki for more information. Agent Isai  Talk to me! 16:35, 10 November 2021 (UTC)

Invalid subdomain
Hi, when I made the request to create my wiki, I asked for the subdomain pzwiki.miraheze.org, but instead I got pz.miraheze.org. I can see the subdomain has been changed in my request. Is it possible to change subdomain from pz.miraheze.org to pzwiki.miraheze.org please? Co (talk) 20:47, 10 November 2021 (UTC)


 * Hi there, I handled your request, request #21369. In the request comments, you requested that the database name be changed from  to  . The part before the -wiki prefix is what your subdomain is so your original request was was for   with the subdomain pzwiki.miraheze.org. By asking to rename the database to , you basically asked to change the subdomain to pz.miraheze.org. To request it be renamed, please make a Phabricator task. Thanks.  Agent Isai  Talk to me! 20:56, 10 November 2021 (UTC)
 * Thanks! I just thought it was weird to have a database named pzwikiwiki, but I had no idea it would change the subdomain I selected. Thanks for the clarification! Co (talk) 21:37, 10 November 2021 (UTC)

My IP is blacklisted
I tried to create an account but after many tries, it shows the message of my IP being a spambot. I waited for 5 hours, then tried again, same error message. Can any sysop remove my IP from the blacklist? Thanks. 14.162.95.11 21:55, 12 November 2021 (UTC)


 * 14.162.95.11, I'm not seeing that this IP is blocked locally on Meta Wiki (this wiki) or globally, so you should be able to create an account. If for some reason you are not able to, please e-mail your desired username to Stewards at, and one of us will create an account for you with that username and e-mail address, with a temporary password delivered to that e-mail address. Thanks. Dmehus (talk) 01:36, 13 November 2021 (UTC)

I requested a private wiki, but can't access it
I requested a private wiki (qxd0008), and it was duly created, but when I try to access it I get the following error:


 * "Erro de permissão


 * Você não possui permissão para ler esta página, pelo seguinte motivo:


 * A ação que você tentou executar está limitada a usuários de um dos seguintes grupos: Membros, Administradores."

which translates to (translation mine):


 * "Permission Error


 * You do not have permission to read this page, because of the following:


 * The action you tried to perform is limited to users of the following groups: Members, Admins."

I believe maybe some configuration step was omitted, or maybe it'll still be performed and I should wait, but I don't know... Ararunaufc (talk) 01:17, 13 November 2021 (UTC)


 * Ararunaufc for your report. It looks like there was a socket read error as part of the jobrunner server's handling of the CreateWiki extension's creation of your wiki job. This is a usually fairly infrequent occurrence, and has been reported to SRE via a Phabricator ticket (can't recall the ticket number off the top of my head). When this happens, the best place to report this is at stewards' noticeboard, so a Steward can manually grant you rights, which I've now ✅. Agent Isai, whenever you see this happen, please also give us a head's up at stewards' noticeboard and also make sure you're proactively checking the CA after ever wiki you approve has been created, to ensure rights are granted. Thanks! Dmehus (talk) 01:28, 13 November 2021 (UTC)

Notice of Private Wiki Search Results Incident
On 12 November, 2021, Site Reliability Engineering was made aware that search results (page titles only) on private wikis may have accidentally been cached and thus publicly visible. SRE took steps immediately to remediate the issue and confirmed only search results were publicly visible. There is currently no indication anyone purposefully viewed private wiki search results through means of the cached version available. If you have any questions, please feel free to email sre@undefinedmiraheze.org or ask on on IRC/Discord. Thank you. Agent Isai Talk to me! 15:20, 13 November 2021 (UTC)


 * This seems quite minor, as it's only the page titles and web search page caching. The problem was remediated once identified, so this is great. Thanks for the head's up! Dmehus (talk) 15:26, 13 November 2021 (UTC)


 * Minor, but good for precedence to hear about. Glad you were on it. --Raidarr (talk) 10:20, 14 November 2021 (UTC)

1. Interwiki table. 2. Reference Tooltips. 3. Wikiplus. 4. Content Model. 5. Gadgets.
I. The interwiki table

Could you please add To the interwiki table of XComhghall Wiki?
 * 1) the prefix   to , and
 * 2) the prefix   to

'''II. Reference Tooltips'''

I enabled the gadgets extension on my wiki, and imported the js and css files, but Reference Tooltips is still not working. What is wrong? What should I do?

'''III. Wikiplus'''

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

'''IV. Content model'''

Is there a way to enable ? This is for MW: Extension: TemplateStyles.

V. The gadget extension

I have a few gadgets set as default on my wiki's MediaWiki: Gadgets-definition. If I do not enable MW: Extension: Gadgets, will the default gadgets still work, or will they be disabled along with the Gadget extension?

Thank you very much. — XComhghall (talk) 04:56, 14 November 2021 (UTC)


 * 1) I have ✅  to your interwiki table but not  .   seems to redirect to , is it ok if I add that to the interwiki table instead?
 * 2) Have you enabled them on your end?
 * 3) Wikiplus' domain (wikiplus-app.com) is not in our Content Security Policy and as such will always fail to load. Try importing it to your wiki locally or using a script on the English Wikipedia itself.
 * 4) At this moment, no. It is not within ManageWiki. You can ask for it to be added on Phabricator.
 * 5) Gadgets cannot be disabled as far as I know. Agent Isai  Talk to me! 06:40, 14 November 2021 (UTC)
 * Agent Isai I would say that's likely fine, but  is already in the global global interwiki table, as , I believe, so unless XComhghall wants the forward and/or transclude flags enabled, or a different prefix, it may not be needed? Dmehus (talk) 21:10, 14 November 2021 (UTC)
 * Agent Isai, Dmehus:
 * 1. Could you please make  a local interwiki prefix, not an interlanguage prefix?   is fine. I do want the shorter   prefix.
 * 2. The Reference Tooltips gadget is set as default on https://xcomhghall.miraheze.org/wiki/MediaWiki:Gadgets-definition, and is enabled on my https://xcomhghall.miraheze.org/wiki/Special:Preferences#mw-prefsection-gadgets.
 * 3 and 4. Thank you very much.
 * 5. Do you mean that the gadget extension cannot be disabled, or that gadgets set as default on MediaWiki: Gadgets-definition cannot be disabled?
 * Thank you very much. — XComhghall (talk) 21:37, 14 November 2021 (UTC)
 * Regarding, that can't be done, unfortunately, as the language codes are reserved for interlanguage prefixes. You could have a single character in front of, or behind, the   to make it an interwiki prefix, but it would need that character. Dmehus (talk) 21:54, 14 November 2021 (UTC)
 * XComhghall  is ✅. For the Reference Tooltips gadget, yes, that can be disabled. You would just edit your gadgets definition file to make it not be enabled by default and, to disable it locally for yourself, just go into Special:Preferences (on that wiki). Dmehus (talk) 22:02, 14 November 2021 (UTC)
 * Agent Isai, Dmehus:
 * I see! What would happen if forward = yes for the prefix en?
 * The problem with the Reference Tooltips gadget is that I enabled and imported everything, but it is still not working. Do you know what might be wrong? What should I do?
 * I was asking Agent Isai what they meant by 'Gadgets cannot be disabled as far as I know.' I was asking what would happen if the Gadgets extension is not enabled, but MediaWiki: Gadgets-definition defines some gadgets as default.
 * Thank you very much. — XComhghall (talk) 22:15, 14 November 2021 (UTC)
 * For the Reference Tools gadget, it should be able to be disabled by adjusting the flag in the MediaWiki:Gadgets-definition page, if it's enabled by default for all. Some gadgets are not enabled by default for all, so it should be possible. Note that it will conflict with the Reference Previews extension (enabled via ManageWiki). So if you have it enabled for all, or if it cannot be disabled for all, I would personally recommend the gadget over the extension, due to the greater functionality the gadget offers (i.e., ability to apply across namespaces). For the interlanguage prefix, though it has English Wikipedia in the URL, you should be able to use it with other interlanguage English language wikis, but that might require a second  prefix and a different URL. The forward flag just means that bots, API-based tools, and search engines will follow any interwiki links that include the   interlanguage prefix. For example, it's required to be enabled for wm-bot interwiki links in IRC channels. Otherwise, if it's not enabled, search engines will not follow the interwiki links and instead MediaWiki will return a bad title error. Hope that helps. Dmehus (talk) 22:26, 14 November 2021 (UTC)

$wgPFEnableStringFunctions
Why is $wgPFEnableStringFunctions disabled here on meta? It limits the possibility of advanced templates. Why is it disabled, is it some exploit or server issue or something?

If it can be enabled, please enable it. Anpang  Talk  06:13, 14 November 2021 (UTC)


 * Anpang This seems like a reasonable request, so I've ✅ this for you. Dmehus (talk) 22:07, 14 November 2021 (UTC)
 * Thank you! Anpang   Talk  00:34, 15 November 2021 (UTC)
 * No problem. :) Dmehus (talk) 00:39, 15 November 2021 (UTC)

Problem tabber
Hi, there, Would you know how to make a caption only appear in one tabber window? I know how to make it appear in both, but when I try to do it in one, the caption shows up in bold, as you can see here: Thanks in advance. Darkrai18 (talk) 13:49, 14 November 2021 (UTC)


 * Hello, my apologies for delay in responding. Has this been resolved? I have located the page you mean and it seems like you managed to get the caption going in one and not the other. If you meant something else, I ask for more information on what is intended. --Raidarr (talk) 12:43, 17 November 2021 (UTC)
 * Hi . Yes I managed, but the text appears in bold. I want it not to be. Sorry for the delay. Darkrai18 (talk) 09:16, 19 November 2021 (UTC)

Professionalization of the donation request
After nice chat about it on the Miraheze IRC channel I figured I'd post about it here. I deeply appreciate the need for donations for this whole project to live, just to make that clear at the outset.

Still, the request notification at the top of all wikis at the moment seems like it could be a lot better in a few ways. Especially on mobile it looks a bit "janky" as someone in the IRC chat said :)

First off: If you don't have a very big phone screen, it fills up the whole of the screen. This might make new visitors confused to the point where they just leave right away. If so, there's no chance that they will actually donate.

Second, the justification of the text together with the logo looks quite unprofessional in a small window. It's very uneven.

Thirdly, If you have a dark skin on your wiki, the message looks very much out of place. I understand the need for it to grab attention, so I'm not saying it should blend too much in, but maybe there's some middle ground here?

Bonus: I fear that this message could turn random visitors away from my wiki, and I also have a hard time imagining first time visitors actually donate. I'm wondering if there is any statistics on this, how many first time visitors click trough from the message, how many non-logged in visitors clicks trough, etc. If almost no first time visitors does click trough, maybe it would be smart to only show the message the second time someone visits? Just a thought. Another thought is that I would be willing to donate more than I have if there was a specific amount I could donate to skip this temporary message for not-logged in visitors one time.

Thank you all so much!

With much respect, Forteller (talk) 19:56, 14 November 2021 (UTC)


 * @Forteller Here's some good news, you can actually remove the donation banner for free by going to Special:ManageWiki/settings and enabling "Opt out of global Miraheze notices". Hopefully that's suitable for your needs. K599 (talk) 20:08, 14 November 2021 (UTC)
 * This isn't really recommendable as you opt out from all Central Notices, some of which are important and affect wikis closely. Agent Isai  Talk to me! 20:10, 14 November 2021 (UTC)
 * I agree it's not recommended, but we do have one other wiki where it's been suggested to temporarily opt out of the central notices during the annual donation campaign. Dmehus (talk) 20:11, 14 November 2021 (UTC)
 * I would say that it is, in fact, recommendable because having this option be available respects the decisions of the individual communities behind each website being hosted on this wikifarm. K599 (talk) 20:18, 14 November 2021 (UTC)
 * I don't think Agent or I were suggesting that. Each wiki can, absolutely, make their own decisions with respect to configuration settings, but from a recommended best practice standpoint, should they choose to follow it, I would say it's recommended to stay opted into Miraheze central notices. There's still no obligation for wikis to follow that, and where it doesn't fit their needs, we will still advise them on how to opt out&mdash;whether temporarily for this annual campaign or indefinitely. Dmehus (talk) 20:24, 14 November 2021 (UTC)
 * That would only be "best practices" if there were central notices that were absolutely universally important, which while I won't deny that there might be, an example of what that would be should be given. For central notices that don't fit what I just described, I think each individual community can decide for themselves if they're important enough to be displayed on their websites. K599 (talk) 20:37, 14 November 2021 (UTC)
 * They can, absolutely, and that's not what we're saying, but wikis do look to the Miraheze community for guidance, which we're more than happy to give. Dmehus (talk) 20:46, 14 November 2021 (UTC)
 * Well, just to make this clear to anyone reading this discussion, communities don't necessarily need to look for the guidance of the Miraheze meta community to make their own decisions, and even if they do choose to receive guidance from the Miraheze meta community, they don't necessarily need to agree with such guidance. Of course, each community is free to ask for anyone's guidance if they would like it, but again, don't feel like you have to agree when you have good reasons for disagreeing. K599 (talk) 20:59, 14 November 2021 (UTC)
 * Absolutely, and I don't think Agent or were suggesting that. These are just recommended suggestions to wikis on the reason(s) for staying opted into central notices. We can, and have, advised on how to opt out of central notices, but do advise on the reasons for remaining opted in&mdash;chiefly to remain connected to the Miraheze global community and "in the loop," so to speak, on important developments. Interestingly, you and I seem to be making the same point, but just doing so diffently, and I've often advocated for SRE to use central notices, which can be opted out of as it provides for greater local control, rather than the sysadmin sitenotices that are added to, which can't be opted out of, and which can't be customized aesthetically (nor translated). Dmehus (talk) 21:06, 14 November 2021 (UTC)
 * I suppose my point has been made. Thanks for now being descriptive on the apparent reasons. K599 (talk) 21:25, 14 November 2021 (UTC)
 * Thank you for your comments. I personally don't feel that centred looks like "junky." In terms of size of the central notice, one has to consider Miraheze is 100% funded by donations, so we need to balance between saying too much or too little. In short, saying too little and making it too small would make it "blend in" and be too inconspicuous, thus defeating its purpose. It's meant to be "in your face," if you will. Without user donations, there is no Miraheze (well not the ad-free Miraheze we know and love). As well, one has to consider that most people edit Miraheze from a desktop, rather than mobile, device. I personally can't imagine trying to edit on a wiki on a tiny mobile screen. In terms of statistics, SRE might be able to investigate compiling some statistics from Matomo, if that's possible, for you. If after all of that, you should be able to opt your wiki out of central notices in Special:ManageWiki/settings on your wiki. You could then, optionally, replace it with a smaller sitenotice. :) Dmehus (talk) 20:10, 14 November 2021 (UTC)
 * You're probably right that most people edit wikis from desktop, but most people seem to use the web on phones. And it is probable that almost all visitors are readers, not writers :) Maybe a shorter version for phones and a longer one for desktop could be a way to go? Just a thought. Forteller (talk) 21:56, 14 November 2021 (UTC)
 * Yeah, that is definitely possible, I think. We'd just have to design a shorter version of the central notice, set it to mobile devices, and then set the current central notices only to non-mobile devices. I'll try and take a look at that, but if I don't get to it, I'm going to ping Reception123 to this thread. Dmehus (talk) 21:59, 14 November 2021 (UTC)

Template error
I imported a template from Wikipedia and I succeeded in getting it running but it conjured an error in the process. How can I remove "templatestyles src="Template:Multiple image/styles.css" wrapper=".tmulti"> " here? Wingwatchers (talk) 21:09, 14 November 2021 (UTC)


 * Wingwatchers If you go to here, you should be able to delete that page. I can demonstrate, if you'd like, but it seems likely what you need to do is go here, select "Parser functions," and enable TemplateStyles. Again, if you'd like me to do it for you this time, I can. Dmehus (talk) 21:14, 14 November 2021 (UTC)
 * It did nothing. Wingwatchers (talk) 22:42, 14 November 2021 (UTC)
 * Wingwatchers I wondered if maybe the CSS style page needed to be purged, so I undeleted it. However, that didn't do anything, either, so I wondered if maybe the issue was the content model of the page. I asked Universal Omega if  was added to ManageWiki/namespaces, so this could be set on a namespace basis if TemplateStyles is enabled. So, what you need to do is change the content model of the page, as I did here. I'm wondering, though, since the parent template page didn't exist, it didn't automatically format it as a CSS page? In any case, that's an option for you. Dmehus (talk) 23:08, 14 November 2021 (UTC)
 * "Page Template:Multiple image/styles.css must have content model "Sanitized CSS" for TemplateStyles (current model is "CSS")." There's still some error within the template. Wingwatchers (talk) 01:58, 15 November 2021 (UTC)
 * Wingwatchers, ah, I wasn't sure whether to use CSS or Sanitized CSS. Looks like I chose the incorrect one for this use case! In any case, I've now ✅ this to Sanitized CSS, and purged the page(s). The template error seems to have disappeared. Can you take a look if it has the desired look now? From my layperson's perspective, it seems to look good. :) Dmehus (talk) 02:29, 15 November 2021 (UTC)
 * Thanks for the help! Wingwatchers (talk) 03:29, 15 November 2021 (UTC)
 * No problem! :) Dmehus (talk) 04:19, 15 November 2021 (UTC)

Question
What's the current background theme Iron Sword 23 (talk) 13:51, 15 November 2021 (UTC)


 * What do you mean? If it's skin its probably vector Anpang   Talk  02:58, 17 November 2021 (UTC)

Miraheze @ Wikimania 2023
Hello,

During today's Miraheze Meeting, we confirmed that in 2023 we are considering attending Wikimania. If you'd like to join the party or get further information, please fill out https://forms.gle/GT2VCeRSCw9NdmR6A and we'll be in touch! RhinosF1 (Miraheze) (talk) 22:33, 15 November 2021 (UTC)

Looking for advice on how to include templates within templates
Hello! I've read through template documentation and understand the basics, but the page on advanced templates lost me (https://meta.wikimedia.org/wiki/Help:Advanced_templates). I can't seem to get my page to display the parameters when they are selected on pageforms if the parameters belong to a template within my "main" template.

I'm trying to embed templates within templates and am running into some problems. If you want to see what I'm trying to do:
 * here is a link to a "main" template I am using for a pageform:
 * https://parentratings.miraheze.org/wiki/Template:Page_Test
 * here is a link to a page created with a form that calls that template:
 * https://parentratings.miraheze.org/wiki/Generic_Test_Page_1
 * here is a link to one of the templates that my "main" template calls:
 * https://parentratings.miraheze.org/wiki/Template:PRCD_Table_Test
 * and a link to the template that that sub template calls (this is the one that contains the parameters for my form):
 * https://parentratings.miraheze.org/wiki/Template:Language_Tags

I thought about trying to do this differently, as shown in the "Sites that Use Page Forms" documentation example but I can't for the life of me find where that page is calling the "Print_entry" template. It just tells me it is towards the bottom of the edit page. And this would still require me to understand some advanced template wizardry that I'm struggling to understand. For instance:
 * the layout for this page:
 * https://directory.fsf.org/wiki?title=Blender&action=edit
 * is determined by this template:
 * https://directory.fsf.org/wiki/Template:Print_entry
 * how does it "initialize parameters/variables"? (I think this is the right phrase, but I'm not sure). I see the numbered list, but I can't seem to recreate it. I feel like I need to do something like this, but I'm not sure how.

I've also read about using, but I'm not sure if I need to use that on every single pipe in all my templates except my "main" template, or just the ones dealing with my parameters. Maybe I even need to add extra {} brackets around some of the rest of my template parameters, but I'm not sure how many or when and where.

Lastly, as a separate question, calling a template twice seems to be throwing an error (pages using duplicate arguments in template calls). At least that's what I think is happening. Is it possible for my page to display the forms-selected parameters twice, but in different locations without this error creeping up?

Any help would be greatly appreciated, even if you can just point me in the right direction a little bit. I'm happy to keep cracking at this. Thanks! ParentRatings (talk) 05:38, 16 November 2021 (UTC)


 * While I'm not 100% sure what you're asking for help with or about the entire scope of your request, I can explain how the site you referenced is functioning. You already have Page Forms on your wiki, so that's a good start. The way FSF has their Directory set up, they use Page Forms for all page creations and edits. On creation, Form:Entry is attached to the Print entry template, which Page Forms then substitutes into the finished page once the form is submitted. There is some extra stuff on that wiki because they are using the full suite of semantic extensions, with many functions and capabilities beyond the forms extension. As for the ordered (number) list on that template, that's really just their documentation. It tells power users and admins what the parameter values are supposed to be when editing without the forms. Basically, it just tells you that the first parameter (meaning ) in this case corresponds to wherever the name of the application belongs. Again, this question is asking for a lot of diverse information about templates, so in order to help us understand what you need help with and to be more likely to get the answers you need, it would be helpful to get a bit more specific. I do hope this can answer some of your questions and help you get started though!  dross  (t • c • g) 23:38, 16 November 2021 (UTC)
 * Thanks so much! I tried to give as much information as possible, but I can see now how that can be confusing - sorry about that. I'm also still learning the jargon. You mention that Form:Entry is attached to the Print_entry template. How are they attached? As far as I can tell, the Print_entry template provides the page layout for each Entry on FSF - I want to do something similar on my wiki. But although Form:Entry has and other "for template" sections, I cannot see how this form is attached to the "Print_Entry" template. Understanding how to make that connection to my "layout" template while at the same time building my form around different templates that contain the parameters I want displayed would be a great help.
 * Hope this time was a little more clear. Thank you so much. :) ParentRatings (talk) 05:10, 17 November 2021 (UTC)

Interlanguage request
I would like to send those interwiki links: To the wiki:
 * cs - https://csup.miraheze.org/wiki/
 * de - https://polandballde.miraheze.org/wiki/
 * en - https://polandballwiki.com/wiki/
 * es - https://polandballes.miraheze.org/wiki/
 * hy - https://hypolandball.miraheze.org/wiki/
 * ja - https://japolandball.miraheze.org/wiki/
 * pl - https://plpolandball.miraheze.org/wiki/
 * pt - https://pt.polandballwiki.com/wiki/
 * ru - https://polandballru.miraheze.org/wiki/
 * zh - https://zhpolandball.miraheze.org/wiki/
 * id - https://bolapolandia.miraheze.org/wiki/

LegoFan506 (talk) 12:00, 16 November 2021 (UTC)
 * ✅, check your local mh:bolapolandia:Special:Log/interwiki for more information. Agent Isai  Talk to me! 15:03, 16 November 2021 (UTC)
 * Can you send the interwiki link (id) https://bolapolandia.miraheze.org/wiki/ to (en) https://www.polandballwiki.com/wiki/Polandball_Wiki? --LegoFan506 (talk) 10:59, 17 November 2021 (UTC)
 * I think Agent already did that along. Ugochimobi (talk) 16:05, 17 November 2021 (UTC)
 * Indeed, as Ugochimobi has pointed out, I have ✅ this. Note for future reference though that generally speaking, only local administrators or bureaucrats can request a global Interwiki administrator add an interwiki prefix to a wiki. However, seeing as I am a local  on , I have completed this reasonable request.  Agent Isai  Talk to me! 17:57, 17 November 2021 (UTC)

How to import or move an existing MediaWiki to Miraheze
I have a MediaWiki and downloaded the content. How can import that package here in Miraheze?? 84.21.34.146 13:22, 17 November 2021 (UTC)


 * After you've requested a wiki, please make a Phabricator task and link the XML dump. Your XML dump should be first uploaded to an external storage service such as Google Drive or MEGA. Agent Isai  Talk to me! 14:49, 17 November 2021 (UTC)
 * Worth noting that creating a user account will be necessary for this if you haven't already. --Raidarr (talk) 17:50, 17 November 2021 (UTC)

A proper way to report users
For example, I've found a suspicious user (that should be globally locked) in recent changes or cvt-feed or something like that. What's the best way to report them? Community noticeboard? Well if I find 10 over a week I'll make atleast 3 topics, too much. If there's no good way yet, I suggest a noticeboard only for reporting users, the noticeboard will be archived very often. Anpang  Talk  03:42, 18 November 2021 (UTC)
 * You can do it on the Stewards noticeboard (a lot of people report there) or you can also send an email to Miraheze. Community noticeboard is intended to get help from other Miraheze users/community. YellowFrogger (✉ Talk  ✐ Edits ) 04:23, 18 November 2021 (UTC)
 * Hmm yes. Thank you! Anpang   Talk  05:05, 18 November 2021 (UTC)
 * To report users, you may do so on #cvt on Discord or on IRC in addition to the Stewards' noticeboard where a member of the global Counter Vandalism Team will process your report. If the issue is a bit sensitive, you are also welcome to send an email to either cvt@undefinedmiraheze.org or stewards@undefinedmiraheze.org.  Agent Isai  Talk to me! 05:12, 18 November 2021 (UTC)
 * For regular reports especially, using the chat-based options may be most efficient. --Raidarr (talk) 17:32, 18 November 2021 (UTC)

Question for category pages
Hi, it's me again. Do you know how to make the category pages look more like Fandom's than Wikipedia's? For example having icons next to the category names, or "trending pages". Thanks in advance. Darkrai18 (talk) 22:09, 19 November 2021 (UTC)

interwiki

 * hi, staff you can help me my two wiki 麥克百科 wikiand日語-麥克百科事典 wiki inter language? thanks.--Msnhinet8 (talk) 08:14, 22 November 2021 (UTC)
 * ✅, check your local Special:Log/interwiki for confirmation. Agent Isai  Talk to me! 08:17, 22 November 2021 (UTC)
 * ok,thanks.--Msnhinet8 (talk) 08:22, 22 November 2021 (UTC)