New PR to get the rest of the task done: https://github.com/miraheze/TSPortal/pull/10

Spam.

gnf_files, mw_settings, mw_namespaces, mw_permission duplicates removed. In addition, removed some wrong entries which had non-wiki dbnames.

In T10412#209860, @Reception123 wrote:

438 entries for mw_settings don't have a corresponding cw_wikis entry. I see many of them are from P468 so I'm thinking maybe there's an issue with the deletion script?

438 entries for mw_settings don't have a corresponding cw_wikis entry. I see many of them are from P468 so I'm thinking maybe there's an issue with the deletion script?

In T10412#209856, @Reception123 wrote:

In T10412#209855, @Universal_Omega wrote:

In T10412#209854, @Reception123 wrote:

@Universal_Omega Would you mind double checking the lists to make sure that everything can be deleted?

Definitely not betawiki and the wikibetas, those are on testglobal. But if we delete from cw_wikis, we'll have to do the same check on the others, ones that have no mw_settings, etc... but no DB after.

Yeah, definitely not betawiki itself but we could probably delete the other test beta wikis. And do you really think there's a chance some wikis even have mw_settings entries but not cw_wikis?

In T10412#209855, @Universal_Omega wrote:

In T10412#209854, @Reception123 wrote:

@Universal_Omega Would you mind double checking the lists to make sure that everything can be deleted?

Definitely not betawiki and the wikibetas, those are on testglobal. But if we delete from cw_wikis, we'll have to do the same check on the others, ones that have no mw_settings, etc... but no DB after.

In T10412#209854, @Reception123 wrote:

@Universal_Omega Would you mind double checking the lists to make sure that everything can be deleted?

@Universal_Omega Would you mind double checking the lists to make sure that everything can be deleted?

Wikis that only have cw_wikis entries (no DB):

In T10412#209851, @Reception123 wrote:

I'm not fully sure why this would be high priority, is it affecting something?

For databases that don't have a corresponding cw_wikis entry, might as well do that for all clouds then. Also, for wikis that don't have a corresponding database, could they not be removed via the regular eval way? (I ask since you listing tables makes it seem like it all has to be done manually)

I'm not fully sure why this would be high priority, is it affecting something?

Best formatting I can come up with is:

I believe it may be possible to force the TOC to display by editing MediaWiki:Print.css.

Switching to Vector legacy (2010) works for me, and is an acceptable workaround from my viewpoint, as long as I can switch to that skin.

While emulating the function of refreshLinks.php, I noticed that the entry for a particular target page (page id 140), would disappear while other pages were being updated. However, it also could show up when updating other pages, and often wouldn't appear after its own page was updated.

All right, I'll use Labeled Section Transclusion for each page that should be on the Main Page so I don't have to rely on the category.

In T10417#209842, @Dimpizzy wrote:

Ok, I'll add the pages back in manually for now.

Ok, I'll add the pages back in manually for now.

It seems that running refreshLinks.php is incorrectly removing entries from the categorylinks table. I am not sure why, but this must be related to the cause of the problem.

I don't know if it's still running, or it stopped early, but now all but three pages are missing from the category.

I'm running the script now to refresh, hopefully it won't refresh on its own after this.

In T10368#209759, @Naleksuh wrote:

@Reception123 The use case for this in core is relatively low, because it only affects user farms like Miraheze and Fandom. While I would agree with this if the basis were to only have extensions be unofficial, given that many features are put into extensions and how many extensions Wikimedia runs, I see no reason for this to be in core, and is something more suited for the MirahezeMagic extension

@Void Should I just try running it again individually on this wiki?

Possibly related to refreshLinks.php (similar to cases of T10394). If the script isn't run to completion, then it may have emptied the table without adding back all the data it needs.

Looks like the linktarget database table was missing. I've run a quick script that should have fixed it.

Error appears to be:

Error 1146: Table 'mockelectionswiki.Comments' doesn't exist

If you encounter this again, I believe it would suffice to disable and re-enable the comments extension.

https://github.com/miraheze/IncidentReporting/pull/57

Hey, yeah of course. Just tried it and I get this:

Can you post what message you get when editing pages? Not just the fatal exception message, but also another one that looks like: [bunch of numbers and letters] 2023-02-01 15:30:30 Fatal exception of type "Wikimedia\Rdbms\DBQueryError". It helps a lot when trying to find out what's happening.

In fact, I think I know why HTMLForm doesn't support things like the "hidden" attribute. MW *still, in 2023*, supports that so-called "browser", Internet Explorer 11, and the hidden attribute is not supported there.

It's mostly because of how the HTMLForm class works. Real HTML forms are much more flexible than the abstraction by MW (for example, if I could set custom attributes in the <option> elements, I could set the disabled attribute right there and then (it could look like ["label", "value attribute", "custom attributes"], just an additional entry in the array on the form descriptor. I wonder how hard it would be to get that into the MediaWiki core)), and I don't really find any way of doing this without a major rewrite, also, adding that godforsaken unmaintainable CSS hack I suggested, while possible and easier than rewriting, wasn't a good idea.

In T9999#209803, @OrangeStar wrote:

I give up, if someone else wants to try be my guest.

I give up, if someone else wants to try be my guest.

No response. If this is still needed, then please reopen when the domain is pointed.

I wasn't able to get it to work on Vector 2022 on enwiki, only on classic Vector.

Then how come it apparently works on Wikipedia?

Looking further into this, it would appear this is intentional per https://phabricator.wikimedia.org/T306719. It would seem though that this only affects the Vector 2022 skin and not classic Vector. Try changing your skin to classic Vector via Special:Preferences -> Appearance -> Vector (2010).

I think it's very unlikely that this is something wrong with Miraheze since another wiki on 1.39.1 has the same issue, so therefore I've created a task upstream which can be followed here: https://phabricator.wikimedia.org/T328556. I

@Chuck.Beckett Regarding Wikipedia, WMF sites are already using the experimental 1.40-alpha version, so it could have been fixed there but not in 1.39.1

Can't be reproduced, was likely a temporary error. Please feel free to reopen if it continues.

Just so we don't forget, the current idea would be to try using https://github.com/wikimedia/acme-chief and have an API backend for ManageWiki with the web app being MediaWiki.

@Reception123 The use case for this in core is relatively low, because it only affects user farms like Miraheze and Fandom. While I would agree with this if the basis were to only have extensions be unofficial, given that many features are put into extensions and how many extensions Wikimedia runs, I see no reason for this to be in core, and is something more suited for the MirahezeMagic extension

Thanks for the insight.

Thanks, but it's just weird when I literally can't see the skin being there before calling for this task 💀

https://github.com/miraheze/MirahezeMagic/pull/399

In T10368#209731, @BrandonWM wrote:

@Universal_Omega You mean a possible way to add this to ManageWiki/core? I'd definitely be open to that, though I'm not sure if it would have to be a restrictedsettings preference or not.

@Universal_Omega You mean a possible way to add this to ManageWiki/core? I'd definitely be open to that, though I'm not sure if it would have to be a restrictedsettings preference or not.

The script has finished running, and aside from a few of my test wikis on beta (which don't need to be fixed), only two databases are returned on executing the query:

themovieawiki
vrtwikiwiki

Both of which fail to be repaired because they are returning errors for wiki not found.

https://github.com/miraheze/MirahezeMagic/pull/398

Skins can be enabled via Special:ManageWiki/extensions -> Skins.

This is because memcached isn't cleared because unlike redis there is nothing to clear based on matches, but I can handle fixing this later.

I'm also aware this is a valid Miraheze issue, that has happened for a very long time. My guess is some conflict with ManageWiki but I was never certain. I also never looked to in-depth either. But it is worth an investigation.

I'll deal with this later. I know how to do it, and personally I think it's a good idea.

Ok, this time it should work, works the same way as described above, config should look like R9:d3a44c9827409401d1640a548fbb699644a6aff5: https://github.com/miraheze/IncidentReporting/pull/56

Per the current triage rules, this is an extra feature request and as such would be triaged as low. Additionally, it's something that should ideally be done in MediaWiki core.

Oh, sorry, I didn't know that. Thank you very much for your quick answer.

Actually, yeah, that function seems to be used to create the incident services table, all my code does is remove their names from there, which is obviously not what's supposed to happen. Incident reports are created at Special:IncidentReports/create, I should be messing with https://github.com/miraheze/IncidentReporting/blob/master/includes/IncidentReportingFormFactory.php instead.

You may change the logo yourself at Special:ManageWiki/settings -> Styling -> Logo.

I think it's a problem on my end actually. Special:IncidentReports is also used to check IncidentReports, right? Revert my PR, I'll write another way of doing this.

It happens miraheze-wide actually. Although I can't vouch for that but, I'm sure of my wikis and many other wikis I've tried it on.

Maybe I've misunderstood the config yet again but when I tested out https://github.com/miraheze/mw-config/pull/5101, this is what it appears like

That's the only way I can see this being done without rewriting the extension, no idea why it doesn't work. That loop formats the name of the service for addition to the form, the new code checks if the service is in the InactiveServices config, then skips the rest of the loop if it is. It should prevent the service from being added to the $irServices variable, thus never appearing in the form. Logic seems good, don't know what's happening.

https://github.com/miraheze/IncidentReporting/pull/54

Let's hope we found them or have me a backup if Alzheimer haven't come to this part yet...