Unfortunately due to some external circumstances I do not have the time to finish this task at the moment, I will pick it up again when I have time if nobody else claims it in the meantime. The work in progress commits I made are linked in the original post if someone wants to continue working based on what I had done

I don't think it's particularly likely for the number of wikis to suddenly grow so in that case the same model could be adopted and we can worry about scalability when we get there.

I took a look at how WikiDiscover implements the "number of wikis with setting" magic word, and it actually just fetches every wiki from the DB, parses its settings JSON, and checks if the setting has the desired value... we could take the same approach here instead of a separate table for consistency reasons, although I don't think doing it that way is particularly scalable if there was a significantly larger amount of wikis (since we only have ~6k it's not that big of a performance worry)

In that case a separate table should be fine.

Since there can only be one category per wiki, the query only needs to look for an exact match. If we were to store tags as strings in JSON format or as comma separated lists, we'd need the query to check for any occurrence of each tag being filtered for every wiki. That kind of query is slow in SQL.

How come it would be that different than querying categories with the current system?

In order to make querying tags efficient we'll likely need a new table on the mhglobal database cw_wikitags with wiki_dbname and tag_id columns... Although we could store the tags as JSON or CSV in cw_wikis, trying to query that would be slow

I'm not aware of there being any particular adversity to JS use, since a task like T10408 also exists.

I started to take a look at potential ways to implement this, and from a frontend UX standpoint the best result was using OOUI's MenuTagMultiselectWidget. The major downside to using this is that it requires JavaScript.

In T8791#214737, @Joritochip wrote:

Should people be able to specify tags during the wiki creation process? (Could be done as a part of T9153)

Should people be able to specify tags during the wiki creation process? (Could be done as a part of T9153)

We thought about that but I think given the nature of tags there would probably be a lot compared to categories which are quite static. Though if it seems difficult to do we could probably start with config and see how frequent it really is in practice. That's also why that part is only Stage 3, as it would be the last thing to be done in either case.

Regarding the addition of a user right for stewards to modify tags: how often do we anticipate tags actually needing to be modified? Is it necessary for a special page to modify them vs just putting them in a config parameter?

In T9195#209617, @OrangeStar wrote:

I'm going to make a subtask for the "using heavy JavaScript to modify groups and namespaces" part, I have an idea on how to do that without adding any new APIs (at least the namespaces part).

I'm going to make a subtask for the "using heavy JavaScript to modify groups and namespaces" part, I have an idea on how to do that without adding any new APIs (at least the namespaces part).

Everything is now done for this.

Reopening per Universal_Omega

Backups are done.

To provide an update on backups, public wikibackups are currently underway. Private backups will be done after but take little time. I can say almost certainly that all this will be done by the 21st, given that there's still 3 days left.

The RfF has now been closed and we will therefore be proceeding by adding the option of having five pre-defined tags in addition to the current categories system.

While not wanting to pre-empt the discussion at https://meta.miraheze.org/wiki/Community_noticeboard#Request_for_Feedback:_Categories_and_the_tagging_system it seems quite clear that there is wide support so far from the community to both keep the current category system but also to add a new 'tag' system. While obviously work shouldn't start before the RfF is completed, after a discussion with @Universal_Omega I think it would be best to do this in three stages (originally I thought of two but @Agent_Isai suggested #3). The rationale is that between Stage 1 and 2 wikis can start getting used to the new system and tagging their wikis and Stage 2 wouldn't be very useful at the beginning of the process in any case.

This extension has been moved to Wikimedia Phabricator, is marked as maintained (now maintained by Wikimedia folks, as was kindly offered here once it was posted about), and is now marked compatible with 1.39+ on its extension page.

@Agent_Isai Status?

Assigning to Agent for community consultation. I would recommend having two main options for implementation: either we keep one main category and then tags or we just have tags

Btw, https://phabricator.wikimedia.org/T295830 indicates that GrowthExperiments shows errors if Suggested edits feature is enabled without CirrusSearch installed, so I guess it should also be disabled.

I fixed the sitenotice, it was a simple fix, but php error messages aren't very helpful at identifying the cause.

Sitenotice fixed and deployed thanks to @Void.

We could also just revert the problematic change, but I would first want to give UO a chance.

Discord, status page, and Twitter notification done. I see you tried to do a sitenotice but there was some change in the code used for sitenotices which caused a deploy failure so I'll see if @Universal_Omega has any idea on how to fix this though I'll note that he's currently away so if this cannot be resolved within a few hours, I'll deploy a CentralNotice instead.

@Agent_Isai Can this be announced for tomorrow 2000-2030 please?

In T9195#195130, @John wrote:

This feels like am infinitely defined task - where does the scope end? What's the end goal? I think this should be split up into tasks for each part so they can be tracked, fleshed out and opinions can be sought in a more defined manner.

This feels like am infinitely defined task - where does the scope end? What's the end goal? I think this should be split up into tasks for each part so they can be tracked, fleshed out and opinions can be sought in a more defined manner.

I think I fixed this now. Please re-open if not.

Sorry for necro this task but seems to happened on custom domain: https://houkai2.cyou/
Tested clearing cache and cookie, used Edge and Chrome.

I think I deployed something that fixed this. It was never totally related to Firefox, and if you have issues, please try clearing browser cookies and see if that resolves the issue. I did test Firefox, with total cookie protection on, and was able to login properly. Therefore. closing as resolved.

Moving to normal as users have been notified afaik and there's nothing much we can really do?

Firefox 101.0.1 on Windows 11, thanks!

Thanks @Untropicalisland: can you confirm your Firefox and OS version either here or on the Firefox ticket linked?

@Reception123 @RhinosF1 thank you and sorry for missing those earlier messages. I disabled Total Cookie Protection on the miraheze domain and that resolved it.

Raised this at https://bugzilla.mozilla.org/show_bug.cgi?id=1774861 - please disable Total Cookie Protection if it's enabled.

In T9340#190089, @Soukupmi wrote:

I personally find "It is unmaintained" simply false given that after the initial ticket for it a patch was submitted within 3 days.
I hope once it is merged into the trunk again, this ticket will re-evaluated and we can keep our favorite theme for a while still.

I personally find "It is unmaintained" simply false given that after the initial ticket for it a patch was submitted within 3 days.
I hope once it is merged into the trunk again, this ticket will re-evaluated and we can keep our favorite theme for a while still.

It becomes hard when every extension needs forks deploying, that are all on branches that could be deleted at any point and if a change is made upstream and not pulled to the deployed branch. It's on us to notice and work out the right solution.

Sorry, I'm not a programmer, just a MH user. I saw there was a fork by a Wikimedia developer, with one file different (which has 4 lines changed in it. isLoggedIn looks to have been changed to isRegistered in each). I didn't realize it was a problem to swap out that file or use fork at the bottom of the link, so again, sorry.

The patch isn't even merged.

A patch has been submitted for this skin and confirmed as working (though not yet merged), can it please be retested for those wikis that use it?