Is this issue still occurring?

In T8667#176789, @dross wrote:

In T8667#176649, @YellowFrogger wrote:

After manually creating the groups in MediaWiki:Grouppage, I "solved" the problem as the groups came back. https://gtavariants.miraheze.org/wiki/Special:Statistics @dross creating the pages "solved" the problem

Hmmm, that's strange. Doesn't appear to be the case on planetariumwiki.

In T8667#176649, @YellowFrogger wrote:

After manually creating the groups in MediaWiki:Grouppage, I "solved" the problem as the groups came back. https://gtavariants.miraheze.org/wiki/Special:Statistics @dross creating the pages "solved" the problem

In T8667#176706, @Reception123 wrote:

@YellowFrogger If this task is to stay open, we'll need another where this is happening in order to be able to debug/fix.

In T8681#175873, @Universal_Omega wrote:

they need manually added to SSL redirects, only if no page is specified are they always redirected.

This has been floating around on some Meta noticeboards and discussions, and I have never been able to reproduce. All of the above subdomains always have redirected to their custom domain normally from my end. Could there be an old DNS cache somewhere on the user end?

Hello! As a bureaucrat, you can do this yourself by navigating to Special:ManageWiki/permissions/* on the wiki and uncheck the edit box. Happy editing!

Manual creation of the group pages does not resolve the issue.

It seems like you two are seeking some advice, so I can be very straightforward about all this.

In T8630#175487, @Lucamauri wrote:

We will surely put our best effort in the RfC, but it won't possibly be perfect and polished at first attempt.
I'm not very expert on things at Miraheze, but a Request for Comments, by its own definition, looks like a place to get feedback and discuss it.
We want to spark conversation, first and foremost, we are not trying to sell any concept here.

Requests for Comment here on Miraheze is used as a means of receiving community input to establish consensus for project-wide changes, those changes which affect a mass amount of users, or those changes which change the trajectory of the Miraheze community. A successful RfC should, in fact, accomplish its goals the first time. A properly formed Request for Comment should not require several separate iterations to reach success; brute forcing a project idea is not an indicator of success or community support.

Please, spend some serious time drafting such an RfC.

Just my two cents, but I would also hope that this would help avoid some of the attitude around "I moved all of the old site's media to Miraheze, but it isn't exactly what I/we wanted. Could you export our media for us?"

Hello! You can enable EasyTimeline yourself by navigating to Special:ManageWiki/extensions#mw-section-parserhooks and activating it there. Happy editing!

Update: VisualEditor loads fine from my end with ?veaction=edit URL parameter.

Unable to test due to namespace protection. Please update with more detail if possible. Include any errors or messages received when attempting to use VisualEditor.

This is almost certainly not a JavaScript or on-wiki problem.

CR. All threads on CN receiving described error or timeout error.

Superseded by T8593.

In T8588#173670, @YellowFrogger wrote:

If it's intentional, something probably causes it.

Partial repro. Visiting a wiki using some sort of mobile responsive features loads fine. Skin remains mobile throughout search (from tapping search icon to entering search terms). Site displays desktop for results. This may be intended behavior, though, as it uses Special:Search. Clicking results returns to mobile version.

History shows proper contributor. Only author label on the special page is showing incorrectly.

Revs 61908 thru 61923 have same error.

Additionally, most recent rev is in sequence with the last working rev. Most recent being 63249.

The first revision to cause the error is 61918. This is also an integer less than the previous revision, 63248. Any chance error could be from a newer revision with an id smaller than previous?

FWIW: CR RhinosF1. CNR on own.

In T8498#171696, @Void wrote:

Hmm, would it be possible to simply put the values of $wgNamespaceProtection into $wgAvailableRights? Or would this not work because this config would be loaded after everything else that depends on $wgAvailableRights?

If I were to make a recommendation, I would simply remove the ability to configure $wgNamespaceProtection from the ManageWiki interface if there is no intention to support adding custom permissions for assignment. ManageWiki configuration of $wgNamespaceProtection is useless otherwise.

Wonderful! I'm glad I could help!

I see that MediaWiki:Common.js at your wiki does not yet have any content. Have you read the instructions directly below the section you linked on the MediaWiki website? The page section at https://www.mediawiki.org/wiki/Manual:Collapsible_elements#Source_3 details that you must add the code on that page to your Common.js file for collapsible tables to work.

Glad you got it figured out. :)

Link to extension page for convenience.

In T5252#99848, @Void wrote:

I'm thinking of forcing all saved group names to be lowercase . . .

Quick bump and also link to Mermaid extension that I neglected to add in the original task.

Hello there - unfortunately, it will not be possible to add Fandom's video embed tool, as all Fandom extensions are declined by default per https://meta.miraheze.org/wiki/Extensions#Declined_extensions_.28.3C1.31.29.

I'm unsure why exactly the redirects in system messages are behaving the way they are.

Sitewide login issues. Reputably affecting several well-known users, including self.

It really isn't that unreasonable to link to the original English version for a few reasons. Firstly, it's the default Privacy Policy page. Second, there is a translation bar across the top of the page anyway. Finally, the English version takes precedence over others anyway.

A pretty major part of the reason I've seen cited for having certain information "expire", for lack of better word, is due to the fact that the servers have been known to run out of space or memory. Part of managing this problem is clearing old and likely unused, uncontroversial, and irrelevant data. It's really just working out kinks wherever possible in the least obstructive and destructive ways that are plausible enough.

Still valid. Awaiting response from sysadmins.

+1. Would love this honestly. Many useful WMF tools excellent for local and global analyses.

Reopening until this can be completely resolved.

Hi Nyl!

The system listings will sort alphabetically by internal name, no matter what order they are listed in configuration. I'm not sure where else they are displayed, but most of it should be able to be changed via interface pages (i.e. MediaWiki namespace).

I would like to +1 this. Not sure if it would ever actually happen, but it would certainly be convenient.

As Hispano76 mentioned, the images on the bottom right of the main page are from Miraheze Commons. See https://magic.miraheze.org/wiki/%D0%A4%D0%B0%D0%B9%D0%BB:Miraheze_Logo.svg for an example of an image from Miraheze Commons. InstantCommons for both Miraheze and Wikimedia is already enabled for your wikis.

You can make a wiki publicly viewable, but restricted to editing via ManageWiki by marking your wiki as open and unchecking the edit permission for the * group (https://dreamsit.miraheze.org/wiki/Special:ManageWiki/permissions/*) and the user group (https://dreamsit.miraheze.org/wiki/Special:ManageWiki/permissions/user). This will configure it so that anybody can read, but nobody can edit pages.

These rights are not allowed to be unset by bureaucrats per Miraheze.

I can see that the permission were removed in you wiki's log. It is problematic that the groups no longer show in the dropdown, especially as a default group.

Are you referring to the system's listing, i.e. in Special:ListGroupRights?

This would make new formats additional to the default:

swf, xcf, psd, mkv, mov, mp4

Is this related to T4813?

Can repro on test account (non-autoconfirmed, first time dialogue). Cannot repro on main account.