Pivot has an uncommon configuration setup compared to regular extensions, will get this done tomorrow.

The extension is on Wikimedia's version control, so I think Wikimedia's Phabricator is where bug reports should be filled. There's a Kartographer project there, add it to the task when creating it.

Well, they're using Google Analytics (and Cloudflare's reverse proxy, which is also somewhat questionable, perhaps not quite as much as GA), so just for that I would decline this, but that's just me.

Sorry, the above comment assumed that this was the pokemonwiki rename request. Anyway, should be fixed by waiting/closing and reopening the browser.

Try closing and reopening the browser.

Was able to successfully login into the wiki. Probably some temporary error with CentralAuth.

Reason for that is unrelated to this task, but will get fixed when Ugochimobi's PR is fixed.

The MobileFrontend page at mediawiki.org recommends adding the following to your MediaWiki:Mobile.js if it doesn't load:

True is the default value, yes. This task, however is asking for the value to be set to false in order to use Kartographer's markers instead of OSM's (https://phabricator.miraheze.org/T10430#210082). This is achieved by setting that variable to false. Per settings.js at Kartographer:

Setting is undocumented. Judging by the source code, it's only purpose seems to be controlling from what hook MediaWiki:Mobile.css is loaded. Please justify why you want to set this to true on your wiki or this will be declined.

@Reception123 @Universal_Omega Opinion on this?

That config should be a boolean (https://github.com/wikimedia/mediawiki-extensions-Kartographer/blob/307d7a08411fb1b56bd9f8f1ebbfd65dc530a03e/extension.json#L594 and https://github.com/wikimedia/mediawiki-extensions-Kartographer/blob/7437afb535f20d77a1b1b3f581c4d3c72dfc08eb/modules/settings/settings.js#L28), the default is true so I've set that wiki's value for this setting to false.

@danielg28 We don't make changes to the extension's, the LocalSettings change we can do, however.

nevermind, it's the vietnamese page.

@Void What page is page id 140?

@Ugochimobi If you want to do it don't feel afraid of claiming it.

Here's the rest of the conversation, with the identity of the person who answered redacted:

They don't have an email, but there is a form on their website (behind Cloudflare's annoying CAPTCHA, of course). Here's what I've sent them:

This is just cdn.jsdelivr.net but over Fastly's network exclusively, so if cdn.jsdelivr.net was approved, this one will be easily approved (at least the fastly subdomain, not sure about wildcard, as SRE wants to keep additions to the CSP to the strict minimum necessary). However, the script can just be set to use cdn.jsdelivr.net and it would work without issues (which would be a 1 line change: https://github.com/bhsd-harry/Wikiplus-highlight/blob/c842b06377288de715fd9466aef3dfe80e4a3304/main.js#L99).

@Owen What elements from the DPA do you want to be able to copy via left-click?

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

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.

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.

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

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

Why not? Is the same thing the recursive resolver would do, just done on the authoritative nameserver instead. I think it would work, but I don't think this solves the concerns with the cookies raised by John and Reception123.

Yes, it is still against the RFCs as of today. Cloudflare doesn't return CNAMEs on root domains, it just resolves the CNAME on the authoritative nameserver and then return the A/AAAA record(s) instead of the CNAME, which technically complies with the spec as the recursive resolver never sees the CNAME at the root itself.

CNAME on root domains is technically illegal according to the standards, as, if there's a CNAME, no other records other than DNSSEC-related records are allowed. There's ANAME for when you want to ignore the standards and still do this anyway, but I don't recommend using that.

https://github.com/miraheze/mw-config/pull/5100 sets that wiki's license to CC-BY-SA 3.0

@Justman I can try to help you over email if you want. Email me at alex@blueselene.com. My OpenPGP key is at https://blueselene.com/pgp-archive/11ADE4393600C1BDFFCBC0A598DE15942B08CA00/key.pub in case you want an encrypted channel.

Ah, then everything seems OK, sorry. If you can't edit the callback URL, then yeah, open a new OAuth consumer request.

No, as that is the domain where the Miraheze wiki is hosted. The application needs to be on it's own subdomain and server, SRE isn't going to install it on their servers.

@PiscesKazeMGR Other than the IP at https://wiki.songngu.xyz/w/index.php?title=Trang_Ch%C3%ADnh&curid=1&diff=38&oldid=28, it seems that you're the only contributor to the wiki, if you delete that edit the wiki should be clear. Please confirm again what license you want.

You can request the wiki again at Meta, then request that the archive be imported. Depending on the size, you should do it either at Special:RequestImportDump at Meta, or here at Phabricator.

The ported licenses are also supposed to be globally-compatible (https://creativecommons.org/faq/#what-are-the-international-unported-creative-commons-licenses-and-why-does-cc-offer-ported-licenses), though CC themselves also recommend using the unported unless there's a need to use a port (and also recommend using the 4.0 international, which I also personally recommend, as I find the 4.0 easier to read and understand, just compare https://creativecommons.org/licenses/by-sa/4.0/legalcode with https://creativecommons.org/licenses/by-sa/3.0/legalcode).

The 3.0 family of licenses has various versions. There's the "unported", which is written to be jurisdiction-neutral (like the international 4.0), and there's the "ported" versions, written to take into account the local laws in the jurisdiction they're ported to. The VN port is written to take into account certain Vietnamese laws.

Assigning to Agent, they did most of the work on this (adding the setting to ManageWiki).

https://github.com/miraheze/mw-config/pull/5098

Seems to be working now.

Everything seems to be in order now.

The callback URL is where users are redirected to by Miraheze if they click "allow" on the dialog box at Meta asking for consent. If redirected there, the request contains information needed to complete the final step of obtaining user credentials. It should be its own endpoint, where you complete the final step and then redirect the user again to your app's main page/dashboard/whatever.

They want you to add a wildcard record: *.comprehensibleinputwiki.org IN A 95.271.135.175. It is technically possible without needing to move the wiki.

How about setting up fanon.lophocmatngu.wiki as a CNAME to mw-lb.miraheze.org and setting the rest of the domains yourself on your DNS server instead of pointing the domain to Miraheze's DNS? I don't know how willing SRE will be to set those fankit and nguyet subdomains.

Sounds like it's just that you don't have permissions to access the wiki. Go to https://meta.miraheze.org/wiki/Stewards%27_noticeboard#Permissions to request that your bureaucrat and sysop permissions be restored.

Don't assign people to tasks, they'll claim them if they decide to do it.

MediaWiki:Timeless.js was being imported twice, once through MediaWiki.Common.js and another as skin-specific JS by MediaWiki. Skin JS files should only have JS specific for that script, the problem is with the wiki's JS setup.

@Reception123 I can contact them myself if you want.

@Uncleistvan1BBB could you attach the file to the task? Click the "File Not Attached" button to do it.

Here is the event handlers at the "Wiki Navigation" sidebar element.

Forget the above, it was because of using var_dump in my script. No problems with the string in PHP 8.0.27.

I've narrowed it down to the string. I've made a stand-alone script and am getting the same error as the extension.

If I had to guess, MatomoAnalyticsHooks::matomoScript, a function listening to the SkinAfterBottomScripts hook, is being called twice, for some bizarre reason most likely.

In T9814#200511, @Reception123 wrote:

Is this a huge issue or something quite minor?

This looks like a JS issue. There are 2 click event handlers at the elements in the sidebar, one from the Timeless skin's JS, and another from MediaWiki:Timeless.js. Both call .toggle right after the other one, so that's why you see it open and close so fast. Preventing MediaWiki:Timeless.js from loading fixes this, so remove the one at MediaWiki:Timeless.js to fix this.

Chances are the wiki was deleted for inactivity per the Dormancy Policy. I don't see the wiki at ManageWiki, so undeletion is not possible. There seems to be a backup at https://archive.org/details/wiki-2ndenlightenmentmirahezeorg_w.

Changing the License of an open, collaborative project such as a wiki is not exactly trivial; in fact, it's almost impossible in practice if the community wants to keep the project's copyright status clear. If you want to do something like this, the first step is to get *every* editor who ever contributed to the wiki to agree to re-license their contributions under the CC-BY-SA 3.0 Unported (their past contributions will be under a dual-license, the CC-BY-SA 4.0 and the CC-BY-SA 3.0, this is because CC licenses cannot be revoked). This alone is impossible if your wiki takes contribution from anonymous editors (IP addresses), as, in almost all situations, there's no way to verify if the person behind the IP when they edited the wiki is the same one in any future edits.

https://github.com/miraheze/mw-config/pull/5090