Does this also mean all those properties get saved in the JSON page? It used to be that way originally, but was removed as it makes the schema harder to evolve (T331222).

On wiki.gg we've implemented most of what I described, with one small difference:

As a note, we've updated messages and the special page to be called Application Passwords on wiki.gg, e.g. https://support.wiki.gg/wiki/Special:ApplicationPasswords

We decided to do this on wiki.gg, we are renaming Special:MovePage to Special:RenamePage as 1.43 rolls out, and we also have changed all system messages to say 'rename' instead of 'move' (although we probably missed some and will have to fix still). This decision was made independently of this thread but we searched to see if it had been suggested before and figured it's worth bringing up here.

In case you didn't know, there is a "Show a confirmation prompt when clicking on a rollback link" option in the Preferences (Appearance menu)

Maybe we're getting slightly out of scope of this task, but that confirmation has a few problems:

My problems with the javascript UI that keep me using non-JS version are:

Hi, my suggestion for naming conventions is:

Hi, we want to remove this extension from about 800 wikis on wiki.gg. This will be much easier to do if there is a tracking category that we can query on each wiki, get a list of the ones that aren't using it, and then go through the rest by hand.

That would be renaming the extension (or "forking" it and then moving to the new version), so that "Nuke" doesn't show up on Special:Version either, and documentation is listed under MassDelete, etc.

For users' familiarity across wiki installations, I might prefer creating one single alternative name and setting a toggle so that wikis can config between the two. Then whichever one is not chosen redirects to the other.

Understood, we didn't realize it was such a restricted group of people. We would be happy to have just one person approved, either Alex (preferred) or myself, if this helps.

Hi, what are the next steps here? Do we need to file something other than this ticket? (Again the aim of this ticket is to request the NDA)

I've also used a setup that I call Module:ForwardArgs to accomplish something like this. I think the most minimal example would look like:

Ah sorry, I didn't notice that option when creating this ticket. Updated it with that template now!

Right, yes - Cargo has something similar too, where you can query values in the order in which they appear on the page, but it's already unreliable, even with linear parsing.

Hm, it looks like that only allows you to preview the page, and I'd prefer to be able to save it as well (e.g. this is a way for someone to submit changes and propose them so they'd want to link the result instead of just screenshotting). But since I figured a patch to Scribunto is unlikely to happen, previewing would still be a good compromise I think.

Oh @cicalese should I go ahead and do that last-resort patch?

I like this! It'll help to find example uses in addition to showing "stability" of the extension, I've always appreciated the "wikis using Cargo" page to find examples of Cargo tables. For standardization, maybe the template should have a list of farms and generate the sentence?

That seems like a reasonable option to me, especially if:

However, the filter might still get throttled until the 24 hours (or whatever the configured value is) will have passed.

Echoing @Revansx , here's my primary use case:

afaik the plan is for us to start updating regularly - we're not on forked MediaWiki anymore, but we are behind on versions for sure. I have no idea what the plan for updates is though, just that they're supposed to happen.

Ah, I didn't realize changecontentmodel existed since we're on 1.33 still, sorry.

I think it should allow both changes because it's possible for a script to encounter a page that was initialized with the wrong contentmodel, then want to append text to it & fix the contentmodel.

Okay so I've found a workaround for my own purposes, which is to leave behind a redirect in the move and then delete the redirect afterwards. This suppresses the "unchecked page." But it's still kind of weird:

1. Create page - you have an unchecked page at OriginalLocation
2. Check page - no unchecked page
3. Move page WITH redirect - now you have a page which exists at OriginalLocation and is not unchecked, but says it's unchecked in Recent Changes
4. Delete OriginalLocation - no unchecked page anymore

Hi,

1. I'm the lead admin of https://lol.gamepedia.com/League_of_Legends_Esports_Wiki. I do a lot of work with Lua and Cargo.

Oh, now I'm able to remove - when I opened the ticket, I got the same error come up when I attempted to delete, but now it let me unlink successfully - if that's something you fixed, thanks!

Hi sorry just wanted to follow up on this

I sync a lot of code across wikis, and sometimes the newer wiki doesn't have all the tables created yet, having the page completely error can make it pretty hard to figure out what needs to be created. Also with such a large number of wikis & tables, I don't always create everything unless I need it. There's a separate issue which is that (at least in the past) the recreate data api action could only REcreate tables, and not create them in the first place, which contributes to the lag in creating all tables on new wikis, since it's a manual process for each one; regardless, I don't think erroring the entire page is the best behavior when a table doesn't exist.

Ok! I just had a conversation with @Alianin about all this, and I'll write here when I have an update.

So does everything seem good now?

Yeah unapprovable vs no current approved revision is important, since no current approved revision will be a "scary" warning message that the page is completely unreviewed by staff. I'll remove 2e then.

• ah, my mistake in the later part, this doesn't depend on 1b, only 1a

Oh yeah....Ok re-renumbered, and updated sub-part numbers as well as references.

Hah, yeah I was debating between temporarily doing Part 0.5 and that...Relabeled now. If anyone is following the discussion and confused, here is the old numbering/lettering. Hopefully I didn't miss any changes.

Ok updated a bit, and I switched some things around in order. I still haven't renamed stuff but if everything still seems good I'll do that next to have a final description that looks nice. And for 1 b and d, as long as the URL actions and classes are defined, it doesn't matter to me at all if this is built in.

Yeah, I think everything here seems good, though there's still the question about whether 1b and/or d are going to be added to the extension or something I do in js/css provided the classes are added (which tbh I think they should be regardless, just for extra custom styling)

Ah, yeah that would work too. FR doesn't, but I'll make a note of it in the overview. And 1(b) potentially has the same issue too, but could also be fixed the same way by adding a class to the overall page.

Ok I made a couple more small edits. One thing for 1d - I realized I wasn't clear about this before, that link should only be in RC if there actually are post-approval/pending changes present for that page. (Since the link also serves as a visual indicator that a page has pending changes that need to be checked.) So maybe not as easy to do in JS.

That's how FR does it - If you click "accept revision" (or alt+shift+S) here it just processes it without navigating away, it's just a lot faster to go through a lot of pages that way, since there's no waiting for the page to reload. I think that's the only FR action that you can do without any page navigation.

Yeah, that's correct - though of course I would prefer to do as little JS as possible since we already have a crazy amount of JS all over the place.

Okay, I kind of do like the idea of having that action available, but it would definitely be not at all important, as long as the extension has a built-in hotkey on the current version of the page & any diff of (any older version to current) that set current version as approved (mirrors FR behavior, where alt+shift+S does this).

Oh sorry. Monitor how much I actually need the [pending changes] (or action=diffapprovedtolatest) links vs the regular diff link in RC. A lot of the time, they aren't the same link & I really did need the one provided by FR. So basically, 1(d) is actually as important as I thought it was.

Sorry, I don't think I understand this. What is the "diff" you're talking about - the standard MediaWiki "diff" link, or some link from FR? If it's the latter, I don't understand.

Ok I updated the task with the diffapprovedtolatest URL action in b and d, and removed c since that's part of b now (after everything I'll re-letter but that's probably too confusing for now).

Now I think I fully understand the issue - in your case, you want an approval to happen as quickly as possible, even if the latest revision is not 100% perfect, as long as it doesn't contain any obvious flaws. You want to approve in haste and correct in leisure, to coin a phrase.

Yeah, exactly this. I view AR/FR as something I really don't want to have, and we only use it out of necessity to avoid super incorrect things that are put live every now and then either through user error or vandalism. So our approval process is a very minimal and quick review just to make sure nothing is blatantly false. This is also why the permissions thing is such a big deal to me, I want a lot of people to bypass this review altogether, and we'll just monitor via patrols what has actually been carefully inspected or not.

No, I always want that link regardless of number of users. Even if I did want to check the history in that case, I'd still first look at the net diff just to have consistency in workflow. Patrol is this. Basically approving an edit via FR/AR = "this edit is not wrong and so it can be live" - this needs to be as fluid as possible to happen, and happen quickly. Patrolling is a much more leisurely and careful thing, and would avoid the issue that you're describing being problematic.

@Alianin could answer about FR being phased out, I'm not sure the details about it.

Ah and re: 1b), what if it was on every view of the page? That would fix 1c and provide more consistency in doing so.

No, I almost never bother looking at page history before clicking to a net pending diff. It's almost always irrelevant to the change made on the page. My wiki is basically a news site, so page edits are usually the addition of new information that didn't exist in the previous version of the page because it hadn't happened yet. I guess this is different from most wikis which might be the reason for a lot of our disconnect.

Wait in 1(b) - would that link be at the top of every single view of the page? My understanding was that was only when viewing current version of the page, but it sounds like it would be on edit/history/viewing diffs/viewing old versions/etc ? If so then we can strike 1(c) no problem, although I would still like to keep 1(d) (that link that FR provides from RC is super important).