Community noticeboard

Edit rights restricted
Hi, I want my open wiki to be editable for Members only. Right now I made : "Everybody" with no rights and "Confirmed users" with Edit rights. Is that the best way ? Does anybody may become a "Confirmed user" on my wiki by his own ? Thanks for your advices Webmaster1 (talk) 16:41, 30 November 2021 (UTC)


 * Hi there :), you're welcome here.
 * Yes, I am sure you're on track as only confirmed users should be able to view your wiki (if it's private).
 * Plus, No, No one can grant themselves the confirmed user group, you or a sysop has to grant them.
 * Hope this helps. Ugochimobi (talk) 16:54, 30 November 2021 (UTC)
 * Thanks for this fast answer. But this : the site should'nt be private. Everyone reading it, only the granted one editing. Is my way ok for that ? Is there a better way ? Webmaster1 (talk) 17:40, 30 November 2021 (UTC)
 * For only site administrators to edit it, you must enable the extension ProtectSite in ManageWiki/extensions of your wiki. This won't make your wiki private, and I recommend reading the MediaWiki page about this extension to see how to edit, among other things. Hope this helps you. YellowFrogger (✉ Talk  ✐ Edits ) 18:02, 30 November 2021 (UTC)
 * No, I don't want only site administrators to edit it, but only Confirmed users (granted by me) to edit it. Webmaster1 (talk) 18:24, 30 November 2021 (UTC)
 * I've never used this extension, so I recommend that you don't believe this answer: but I think it works like this. If you want guest users to edit, put them as admin on the site. If you only want registered users to edit on the site, this extension: "EditSubpages" should do it. But that's another thing. YellowFrogger (✉ Talk  ✐ Edits ) 18:42, 30 November 2021 (UTC)
 * I wasn't the one that replied with that though, but just like I said above, I thought your wiki is private, but if what you want is what you said in the second RE, then, it's simple, all you need is a public wiki then the page you don't want everybody to edit, you'd protect "Allowing on autoconfirmed user's access" by so doing, only autoconfirmed and "confirmed users" will be able to edit such pages. Ugochimobi (talk) 19:10, 30 November 2021 (UTC)
 * @Ugochimobi: Sorry for the mistake, and thanks for the answer. Webmaster1 (talk) 19:38, 30 November 2021 (UTC)
 * No problems,:P Ugochimobi (talk) 20:07, 30 November 2021 (UTC)
 * Hi there! Uh, it looks like a lot of the previous solutions are pretty unnecessarily complicated. If I am correct that you want only members that you choose to edit, you can do this simply by changing which user groups have the  permission on your wiki. You can do this under Special:ManageWiki/permissions by removing the   permission from the   group (which is the same as the   group), and adding it to whichever group you desire. You may even wish to create a new group like   and give it the   permission for more control over who exactly has the ability to edit.
 * I can see that you have already figured out how to unassign the  permission from the   group, and have assigned it to the   group. If you would like to ensure that only confirmed users can edit your wiki, you will need to be sure to also remove the   permission from the   group as well (which applies to all logged in Miraheze users) at [ Special:ManageWiki/permissions/user].  dross  (t • c • g) 23:17, 30 November 2021 (UTC)
 * Seriously? And I used to edit a lot on a wiki, and I always went through ManageWiki, but I had no idea that this was exclusively for this. That's why it's good to volunteer even if you're not a steward. I think this is good because we don't need to solve it with extensions. Because extensions one day ceases to exist and is very manual. YellowFrogger</b> (✉ Talk </b> ✐ Edits </b>)</b> 00:25, 1 December 2021 (UTC)
 * I've been around MediaWiki installs since probably about the time of 1.25 or so. Worked on the basics of or hosted a few independent wikis myself, including Hypercane's Hypoverse when it was once an independent farm. Those kinds of projects mean making changes to the LocalSettings.php file itself and running the included scripts from time to time. For me, ManageWiki is just like an extension of everything that goes into the backend management of a MW wiki. dross  (t • c • g) 07:08, 1 December 2021 (UTC)
 * they're all similar solutions. Thanks anyway :) Ugochimobi (talk) 07:00, 1 December 2021 (UTC)
 * Thanks to all for your valuable comments. What @dross has said is important as there is something weird. Though "All Users/Everyone * " has no editing rights, yet the simple "User" group has about all rights ! Apparently every group should be carefully checked... Webmaster1 (talk) 14:51, 1 December 2021 (UTC)
 * Another strange detail : I created a group 'Member' with edit rights, but this goup does'nt appear in the '[mywiki/]Spécial:ManageWiki/permissions' list. Quid ? This let me think there should be somewhere a clear definition of the Groups. For instance "Robot" and "Bureaucrates" : of Mywiki ? or of Miraheze ? Webmaster1 (talk) 15:01, 1 December 2021 (UTC)
 * Did you get it figured out? Everything looks good to me in Special:ManageWiki/permissions/member and on Special:ListGroupRights. dross  (t • c • g) 19:15, 1 December 2021 (UTC)
 * Yes I did get it figured out, and as I am learning I admire... Thanks for the Special:ListGroupRights address. Webmaster1 (talk) 21:33, 1 December 2021 (UTC)
 * I am sorry, I have this problem : though I belong to the Administrator group of my Wiki, I have no permission to create the Discussion page of any page I created ! So I figure I have missed something and nead your help. -- Webmaster1 (talk) 09:53, 2 December 2021 (UTC)
 * Hey! No problem! It looks like none of your user groups have the  permission, which I do believe is necessary to create any pages in addition to editing existing ones. There is also a   permission for discussion pages which you may want to assign to a user group. Hope this helps!  dross  (t • c • g) 09:59, 2 December 2021 (UTC)
 * Just on the principle, I should say something important about MediaWiki permissions - nothing is assumed, and by default everything is inherited. If a user was able to do something, an admin probably doesn't have it because they inherited from the user. So if you remove something from one group that was inherited from, you must make sure to add it to groups you want able to use it. --Raidarr (talk) 10:14, 2 December 2021 (UTC)
 * Thank you. I got the  and   permissions checked. -- Webmaster1 (talk) 10:26, 2 December 2021 (UTC)

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)
 * And will there be a way to disable CNotice for some, and leave only fundraising? YellowFrogger</b> (✉ Talk </b> ✐ Edits </b>)</b> 15:33, 1 December 2021 (UTC)
 * @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)
 * 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</b> (✉ Talk </b> ✐ Edits </b>)</b> 19:59, 1 December 2021 (UTC)
 * @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)
 * 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)

MediaWiki 1.37
Can you please upgrade all farm wikis on this farm to MediaWiki 1.37? Thanks. TylerMagee (talk) 18:26, 1 December 2021 (UTC)
 * The version is still coming, maybe in a few days! Miraheze systems work and that's why Miraheze always gets a new version in a short time. Remembering that Wikipedia already uses version 1.38 YellowFrogger</b> (✉ Talk </b> ✐ Edits </b>)</b> 19:47, 1 December 2021 (UTC)
 * Based from my inquiry on Discord to SRE, the idea is to roll out in the next few weeks; however, there are snags with extensions that need to be worked out. Until that happens, a full update will be delayed. SRE is actively working on the matter. --Raidarr (talk) 20:32, 1 December 2021 (UTC)
 * Upgrades aren't something you have to request, they are something we do automatically. One of our commitments to our users is to always provide the latest version of MediaWiki. Currently, we're testing all 300+ extensions on our farm to make sure they work well with MediaWiki 1.37 with only about 20 extensions left to test. We anticipate to probably upgrade to MediaWiki 1.37 in the next few week if possible. Agent Isai  Talk to me! 20:42, 1 December 2021 (UTC)

Accidentally removed self from bureaucrat role
Hi there. I am completely new to this and was poking around roles and removed myself from the bureaucrat role (i am the sole member currently) thinking administrator role would still allow me to access to editing the wiki settings. I'm now stuck, what should I do? Hamishpo (talk) 08:57, 2 December 2021 (UTC)


 * You can request a steward in this to re-add you to the bureaucrat role in your wiki. Anpang   Talk   Stuff  09:03, 2 December 2021 (UTC)
 * Thankyou so much! Hamishpo (talk) 10:18, 2 December 2021 (UTC)

Problem with infoboxes
Hello, I'm new to setting up wikis of my own here, had The Pantheon Verse Wiki started earlier today, and I'm struggling with the infoboxes. I've imported a number of templates and modules from Wikipedia to get them working, but every time I try to create one, this text appears next to it in the preview: " <templatestyles src="Module:Infobox/styles.css"> "

I have no idea where I went wrong, can anyone help me? - 59Efra (talk) 17:42, 2 December 2021 (UTC)


 * Please enable TemplateStyles at Special:ManageWiki/extensions -> Parser hooks to get rid of that. Agent Isai  Talk to me! 17:48, 2 December 2021 (UTC)
 * Did that, now I'm getting this other message instead: "Page Module:Infobox/styles.css must have content model "Sanitized CSS" for TemplateStyles (current model is "plain text")." How do I solve this? - 59Efra (talk) 17:56, 2 December 2021 (UTC)
 * I've fixed that for you. For the record, I changes the content model of the page using Special:ChangeContentModel from text to Sanitized CSS. Ugochimobi (talk) 18:11, 2 December 2021 (UTC)
 * Thank you very much! - 59Efra (talk) 18:15, 2 December 2021 (UTC)
 * Hi there, to be honest with you, importing templates and modules from ENGLISH WIKIPEDIA is where you started making the whole mistake, as infoboxes from there always has one or two issue here, why? they're complex that you need enough Lua programming knowledge to fix them to your taste.
 * Per Agent above, Head to this page in your wiki and scroll down to find the mw:Extension:TemplateStyles and turn it on. Enabling that should fix your current issue. Ugochimobi (talk) 17:53, 2 December 2021 (UTC)

DynamicPageList not displaying for most users
Hello. Recently an editor at SideM Wiki brought up that DynamicPageList wasn't working (we use them on pages such as this). I checked the extensions for the wiki, saw that DPL was disabled, and then reenabled it. It works for my account (admin) but not for the other editor (regular user). I also tried logging out and DPL no longer worked. What could be the cause of this? Thanks for any help. Clay (talk) 00:34, 3 December 2021 (UTC)


 * I can't see any issues, has the error been resolved? ~ El Komodos Drago (talk to me) 13:01, 10 December 2021 (UTC)
 * Yeah, I'm not sure what happened but it seems to work when I log out now. Clay (talk) 05:23, 14 December 2021 (UTC)

Removal of the Liberty skin
Hello,

SRE wishes to inform the community that the Liberty skin will be removed in preparation for Miraheze's upgrade to MediaWiki 1.37 on 5 December, 2021, due to lack of compatibility with MediaWiki 1.37. While testing the skin on MediaWiki 1.37, page contents loaded incorrectly and unstyled due to resources not loading. As this skin is not compatible with the latest release of MediaWiki, we will have to remove it before upgrading.

Miraheze offers many skins to choose from. Affected wikis who have the Liberty skin enabled as the default are encouraged to move from the Liberty skin to one of Miraheze's other skin offerings. You can enable new skins at Special:ManageWiki/extensions -> Skins on your wiki and set it as the default at Special:ManageWiki/settings -> Styling. Note that once the skin is removed and if it is your default skin, you'll be moved to the Vector skin automatically. If you don't have the skin enabled as the default, no further action is required.

Thank you for your understanding, Agent Isai  Talk to me! 12:00, 3 December 2021 (UTC)


 * Thanks for telling us. SoyokoAnis  12:14, 3 December 2021 (UTC)
 * Is there a method to identify and contact default users of Liberty directly? I can't imagine that on its own, this message will effectively reach the management of each affected wiki. --Raidarr (talk) 13:07, 3 December 2021 (UTC)
 * All affected wikis have been notified via a sitenotice like the one that appears here on Meta. Per our statistics however, it seems only 8 wikis have it set as the default. Agent Isai  Talk to me! 13:10, 3 December 2021 (UTC)
 * Great, that makes us safe, as long as the wikis/users in question have been notified. Ugochimobi (talk) 13:17, 3 December 2021 (UTC)
 * I don't use the skin, but giving something like this 2 days notice is not cool and is something right out of the Fandom book. Especially when 1.36 is not reaching its EOL until May 2022 and there is certainly no rush to update. Naleksuh (talk) 19:36, 3 December 2021 (UTC)
 * Timely updating is part of the Miraheze base pitch, but more advance notice would be good to consider going forward. --Raidarr (talk) 20:31, 3 December 2021 (UTC)
 * It's going to be a not-so-great change for those who wear the skin. I don't use it and I won't be sorry. But one must understand who is for good. so its good, even if it sejas one less skin. Let this new version come. <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 21:07, 3 December 2021 (UTC)
 * I'm sorry that you feel like two days notice is not enough, we will keep your comments in mind and seek to provide notice earlier next time when possible. As for the no rush to upgrade argument, one of Miraheze's main commitments is to upgrade to the next version of MediaWiki in a timely manner, as Raidarr points out above. We don't think it would be fair to hold up an entire upgrade for all users simply because of one skin that isn't compatible and for which we have no reason to believe there will be a fix in the near future (based on the current activity of the developers). Maybe there is a reason that I'm missing but I personally don't see what would be different if the notice had been there five days instead of two for example, but as I say, a longer period of time is something we will consider in the future for such changes if that is what the community wishes. We are sorry that we have to remove Liberty but it is up to the developers to keep their extensions up to date and compatible with the latest versions of MediaWiki. Universal Omega does regularly help developers and fix bugs, but unfortunately the developers for Liberty don't seem to be interested in keeping it up to date with the latest stable version of MediaWiki. If wants to add something he should feel free. Reception123 (talk) ( C ) 11:15, 4 December 2021 (UTC)

MediaWiki 1.37 upgrade
In keeping up with our commitment to always provide the newest version of MediaWiki to our users, Miraheze is happy to announce that we'll soon be upgrading our MediaWiki version from 1.36 to 1.37 on 7 December, 2021. The upgrade will take place from 17:00 (UTC) to 20:00 (UTC). During this time, all wikis will be set to read-only meaning that wikis will be uneditable during that period of time.

This MediaWiki upgrade brings little new features that may interest users apart from (perhaps) support for JPEG2000 images. As for technical changes, this MediaWiki upgrade brings plenty of change, consult the release notes for MediaWiki 1.37 for more information. If you have any questions, feel free to ask, thank you! Agent Isai Talk to me! 21:05, 3 December 2021 (UTC)
 * Good <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 21:08, 3 December 2021 (UTC)
 * I arrived at Miraheze in version 1.34 and we are already going to version 1.37. We are old. But this new version (as you said), it's not going to be a big deal (and the next one (1.38 that Wikipedia)) has ridiculous changes in the sidebar on Mobile MinervaNeue, the one that you press and open settings, login, etc. The letters just got smaller. Version 1.38 was released quickly after 1.37, which raises doubts. <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 21:12, 3 December 2021 (UTC)
 * 1.38 isn't released yet. Wikimedia projects run an alpha version. ~ RhinosF1 - (chat)· acc· c -  21:31, 3 December 2021 (UTC)
 * Lots of pages in the wiki I am subscribed to are now crashing with Fatal errors. Comment streams are also blank and not functioning and giving "Invalid API response". Wanderer2020 (talk) 04:37, 8 December 2021 (UTC)
 * Use Phabricator to report bugs. TylerMagee (talk) 18:26, 11 December 2021 (UTC)

Problem with /styles.css module
Hi

I'm working with templates and modules on one new wiki (using code from Template Wiki). So I want to create Module:Documentation/styles.css for Template:Doc. But every time the system shows an error. So I need for help. --Tigran07 (talk) 06:38, 4 December 2021 (UTC) Tigran07 (talk) 06:38, 4 December 2021 (UTC)


 * What's the error? Agent Isai  Talk to me! 06:41, 4 December 2021 (UTC)
 * "unexpected symbol near '/'." -Tigran07 (talk) 06:45, 4 December 2021 (UTC)
 * And every time I change the code, the error still remains. -Tigran07 (talk) 07:05, 4 December 2021 (UTC)
 * Also something is going wrong with Module:WikidataIB. Wiki show it like a usual page --Tigran07 (talk) 07:25, 4 December 2021 (UTC)
 * Is it supposed to be Template:Documentation/styles.css? Anpang   Talk   Stuff  08:37, 5 December 2021 (UTC)
 * This module supposed to be Template:Documentation Tigran07 (talk) 12:05, 5 December 2021 (UTC)
 * What? Well I'm just telling Module: pages don't have subpages so it's probably Template:Documentation/styles.css Anpang   Talk   Stuff  03:03, 6 December 2021 (UTC)

I'd like to apply for Interwiki administration on my site
...now that enough time and edits have passed. (Only doing so because I'd like to get in my next two IW IDs any hour from now--and at the suggestion of and  from back in July.) This comes as I'm taking a break from conlang-dictionary entry-import duties; keep in mind I'm rescuing them from a now slower-than-laboratory-pitch Referata, a.k.a. what used to be the Semantic MediaWiki hotspot. (Long story...)


 * Wiki ID: constantnoble
 * Requested IWs:
 * mwe (mediawiki.org/wiki/Extension:$1 / MediaWiki extension details)
 * mwm (mediawiki.org/wiki/Manual:$1 / MediaWiki manual pages)


 * Active/Registered users: 1 (this founding contributor) / 25 (through Miraheze login)
 * Contributions by this applicant: Almost 9,000 (and please, no Dragon Ball jokes)

Over at Phabricator, I'm gearing up for my next filing--concerning a few issues I'm having with PageForms lately--and to I am awaiting a much-needed adjustment to my DPL3 install (whereby count in "ParametersData.php" must be raised from the default 500 [locally or otherwise] to get the correct result[s] for various page tallies in the resultsheader).

All this, as the 1.37 era is gradually approaching on here...

All right, / Have at it.

Once again, many thanks!

--Lily talk and I will listen · Lilypond Wiki 13:54, 14 December 2021 (UTC)

Imported infoboxes from Wikipedia aren't working
For my wiki, (Link), I wanted to use some infoboxes from Wikipedia. I followed the steps on the Miraheze page on importing infoboxes, but even though the templates for the infoboxes and their /doc versions are imported, it doesn't work. I enabled the extensions that the page explained were required, and it still did nothing. Whenever I want to edit an infobox now, it will let me insert the template, but not provide any fields for me put information into, showing a message that there are "no unused fields." Any help with this would be greatly appreciated. - IAmTheSenate (talk) 21:06, 11 December 2021 (UTC)
 * Hi, I'm the creator of the test page you're probably talking about. Note firstly that the page is in the process of being created and it is not recommended, yet, to follow what was written on it because everything is incomplete and in the middle it may fail. When that message appears explaining about missing module, example: There is no module with that name: Yesno you must create a Yesno module imported from Wikipedia. Your mistake is that the unused fields probably means you didn't put any message in the parameter or something. I've never had this error with me so I'm not exactly sure what this is. <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 22:09, 11 December 2021 (UTC)
 * Your wiki is private, I can't see what's on it. I would even analyze what this is <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 22:12, 11 December 2021 (UTC)
 * If you're ok with doing so, I can add you as a member to analyze the situation. IAmTheSenate (talk) 03:56, 12 December 2021 (UTC)
 * yes I would like to see what's there <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 19:28, 12 December 2021 (UTC)
 * I've added you as a member now, so hopefully you can help find the problem. Thank you again for helping with this. IAmTheSenate (talk) 19:51, 12 December 2021 (UTC)
 * You must also add the extension TemplateStyles. I saw on your wiki that it is not activated. <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 21:01, 12 December 2021 (UTC)
 * I believe I've done all the things you suggested in the edits, however nothing seems to be working. IAmTheSenate (talk) 21:58, 12 December 2021 (UTC)
 * I should also probably mention that I have not used MediaWiki before, nor Miraheze, so I don't have a full grasp of exactly how to do everything. IAmTheSenate (talk) 22:00, 12 December 2021 (UTC)
 * I also at first struggled to add infoboxes to the wiki.
 * All pages that say: "Page "Name of page/styles.css" must have content model "Sanitized CSS" for TemplateStyles (current model is "plain text")", you delete and recreate with the same content. I saw here that you added the extension <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 22:27, 12 December 2021 (UTC)
 * Will solve? <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 00:03, 13 December 2021 (UTC)
 * Unforutnately no. I changed my user content model to Santitized CSS and I did so with the templates required for, in this case, the country infobox, and now it says they aren't in Santitized CSS when they are. It gives me this message on the template for the country infobox page: Page Module:Documentation/styles.css must have content model "Sanitized CSS" for TemplateStyles (current model is "plain text"). and Page Module:Hatnote/styles.css must have content model "Sanitized CSS" for TemplateStyles (current model is "plain text").
 * I honestly cannot find what is wrong. IAmTheSenate (talk) 03:10, 13 December 2021 (UTC)
 * I will see. So, please, help to know what's going on here. you should also delete and restore the page again, as you had added the TemplateStyles extension. And not to have changed content model <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 03:45, 13 December 2021 (UTC)
 * Hi there, would you add me as a member of your wiki so I can fix this for you? Ugochimobi (talk) 05:35, 13 December 2021 (UTC)
 * Sure, thank you for offering your help. IAmTheSenate (talk) 21:48, 13 December 2021 (UTC)
 * He (Ugochimobi) understands about this and it's interesting that you add him as a member. <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 23:49, 13 December 2021 (UTC)

Sanitized CSS (2)
What does "Sanitized CSS" mean in TemplateStyles? I need help with this. It's saying it need sanitized css but the code is js. Anpang  Talk   Stuff  01:47, 12 December 2021 (UTC)


 * Yo! You can not use Javascript files for TemplateStyles. As the warning notes, it must be sanitized CSS content model precisely. Ugochimobi (talk) 14:40, 12 December 2021 (UTC)
 * I also have these problems. When I go to solve for Special:ChangeContentModel, it bugs saying "Unrecognized or unsupported rule at line 1 character 1" <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 19:27, 12 December 2021 (UTC)
 * Hi, this means that the current css isn't correct and can not be converted into SCSS. Ugochimobi (talk) 05:29, 13 December 2021 (UTC)

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 and  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: FatBurn0000 (talk) 02:28, 12 December 2021 (UTC)
 * 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:
 * 3) 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):
 * 4) 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.
 * 5) 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.
 * 6) 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.
 * 7) 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.
 * 8) 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.
 * 9) If the user with the highest position disagrees, then again, try to have a full conversation with them.
 * 10) 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.
 * 11) 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:
 * 12) Creating pages on wikis that contain destructive criticism towards the wiki.
 * 13) Having any content on wikis that the wiki's staff members have stated that they do not want.
 * 14) 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:
 * 15) Negative pages about obscure users on the internet
 * 16) Pages about people who do not want a page about them (this does not apply to informative pages)
 * "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. <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 02:37, 12 December 2021 (UTC)
 * 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)
 * 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)
 * 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 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)

FatBurn0000 (talk) 22:03, 12 December 2021 (UTC)
 * 1) Well, it should still be made more clear.
 * 2) This is why there are exceptions to this rule. Also this doesn't necessarily apply to just Fandom wikis.
 * 3) Fair enough.
 * 4) 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).
 * 1) 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).
 * 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)
 * And you. Are you going to open an RfC or not? <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 22:32, 12 December 2021 (UTC)
 * 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)
 * 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)
 * A user named Blubabluba9990 opened an RfC <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 00:00, 14 December 2021 (UTC)


 * 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)

Edits not saving on English Gyaanipedia
I guess from the last few days it's happening, I have seen this yesterday and tried to resolve it but couldn't able to. I don't know it's a bug or something else.

Whenever I tries to edit any page on English Gyaanipedia it's not saving and this message is poping up '''Error, edit not saved. "wikitext" content is not allowed on page Shaunak Chakraborty in slot "Main"



or can any of you guys please help me with this. Thanking you with due respect. Shaunak Chakraborty (talk) 06:13, 13 December 2021 (UTC)


 * Shaunak Chakraborty, please note I have procedurally ✅ this thread from Administrators' noticeboard to here, where it is now much more in scope. Secondly, to your question, can you clarify this a bit more? Thanks. Dmehus (talk) 06:20, 13 December 2021 (UTC)
 * Actually whenever I am trying to edit any page on English Gyaanipedia not only this above mentioned, this message is popping up and the edits are not saving. I have seen that since last few days other users also don't made any edit which means they also can't able to do that but yes still I can able to edit my userpage, so maybe this thing only affects the main space. This thing is only happening with English Gyaanipedia not with other versions. Can you please help me with this. Shaunak Chakraborty (talk) 06:46, 13 December 2021 (UTC)
 * Did you change the managewiki settings or did some phabricator request? It's like mediawiki got confused that wikitext (which is normal content) isn't allowed in the wiki. <span style="display:inline-block;border:2px solid #bfff00;border-radius:8px;background-image:linear-gradient(to bottom right, #75ff75, #ffff80)"> AP 📨 07:23, 13 December 2021 (UTC)
 * No I didn't change the managewiki settings or doesn't made some phabricator request, but I have tried to figure out this in mediawiki setting but couldn't able to do so. I think now I should put a request on Miraheze phabricator. Shaunak Chakraborty (talk) 08:16, 13 December 2021 (UTC)

Modules
Hello? I'm new here. How can I add a navbox module for my wiki? LiaMinina (talk) 01:26, 15 December 2021 (UTC)


 * Go to Special:Import and scroll down to the "Import from another wiki" section, set Source wiki to meta, set Source page to Module:Navbox, and click Import. It will maybe require more modules so import those too. <span style="display:inline-block;border:2px solid #bfff00;border-radius:8px;background-image:linear-gradient(to bottom right, #75ff75, #ffff80)"> AP 📨 03:03, 15 December 2021 (UTC)
 * Navbox is a more complicated thing just like Infobox. You must first configure them with MediaWiki:Common.css and js from Wikipedia. Any questions, send it to me <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 03:18, 15 December 2021 (UTC)
 * But how do I do that? LiaMinina (talk) 14:33, 15 December 2021 (UTC)

Another suggestion
A new special page or a new Special:ManageWiki section called "Quick templates". The special page would contain lots of buttons with names of commonly used templates (infobox, userbox, documentation, mbox, navbox, etc), clicking one of those buttons will import that template and also all modules needed for it to work. I'm coding an extension that does exactly that too haha <span style="display:inline-block;border:2px solid #bfff00;border-radius:8px;background-image:linear-gradient(to bottom right, #75ff75, #ffff80)"> AP 📨 07:32, 16 December 2021 (UTC)

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)


 * Isn't it the same? or you meant shortening the text to that? <span style="display:inline-block;border:2px solid #bfff00;border-radius:8px;background-image:linear-gradient(to bottom right, #75ff75, #ffff80)"> AP 📨 08:01, 16 December 2021 (UTC)