This was done.

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

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 "hidden" attribute right there and then (it could look like ["label", "value attribute", "custom attribute"], 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.

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

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.

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.

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 in that iteration 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

• T7942: [ManageWiki] Create better CI for MediaWiki standards and security
• T7943: [CreateWiki] Create better CI for MediaWiki standards and security
• T7944: [MatomoAnalytics] Create better CI for MediaWiki standards and security
• T7945: [GlobalNewFiles] Create better CI for MediaWiki standards and security
• T7946: [RemovePII] Create better CI for MediaWiki standards and security
• T7947: [DataDump] Create better CI for MediaWiki standards and security
• T7948: [RottenLinks] Create better CI for MediaWiki standards and security
• T7949: [IncidentReporting] Create better CI for MediaWiki standards and security
• T7950: [WikiDiscover] Create better CI for MediaWiki standards and security

In T7939#160072, @John wrote:

In T7939#160067, @RhinosF1 wrote:

In T7939#160062, @John wrote:

One task - one end objective is a standard purpose. Why do we have a task for 9 separate objectives?

It's one end objective that all Miraheze maintained extensions have mediawiki-standard CI

9 different software components = 9 different tasks surely? They just good task management and makes things easily trackable and measurable.

It's probably better to be tracking things separately and have subtasks for each extension

In T7939#160067, @RhinosF1 wrote:

In T7939#160062, @John wrote:

One task - one end objective is a standard purpose. Why do we have a task for 9 separate objectives?

It's one end objective that all Miraheze maintained extensions have mediawiki-standard CI

In T7939#160062, @John wrote:

One task - one end objective is a standard purpose. Why do we have a task for 9 separate objectives?

It's one end objective that all Miraheze maintained extensions have mediawiki-standard CI

One task - one end objective is a standard purpose. Why do we have a task for 9 separate objectives?

I've extended the above mentioned PR to now also include phan.

https://github.com/miraheze/ManageWiki/pull/297 does this for ManageWiki, implementing eslint, stylelint, and phpcs. It also will make GitHub Actions automatically commit formatting fixes, when possible.