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

Now, what if that revision turned out not to be good?

The warning would be enough to curtail user error. So I guess there's 2 totally unrelated reasons for wanting this link (or both), which may be why it seems weird.

Hm, now that I think about it actually there are 2 potential diffs you might want to look at from that page - either (earlier of this diff to most recent) or (approved to most recent), the former is probably the more useful of the two, but either would work.

Could it be a warning with a link? If that text had after it, "Click here to see diff to most recent." it would be perfect, and a lot better than FR version even.

(1c) So in RC it will link both to the net diff (approved to current) and also to the diff of that particular revision. If you click on the latter, and set the newer one of those 2 as approved, you may think you had actually gone to the net diff and approved most recent.

(3) ah okay, yeah if it's not easy/doable no problem - and yeah, I wouldn't want there to be 500+ entries in RC (or a log) when someone changes a setting in a template...so it would only be worth it if it could be combined into a single line, which is starting to sound like it might be complicated. Maybe I could accomplish something via some workaround with AbuseFilter's ability to check diffs, if I always warn when either approvable_by or NOAPPROVAL is added.

(3) yeah that's fine. Maybe there could be a separate log for additions or removals of approvable_by or NOAPPROVAL to pages? I'm going to hide the "set as approved revision" log messages from my recent changes (assuming that's possible) but it would be nice to have a log for these show up in RC.

(3) Oh, I guess anyone can add it, but the revision has to actually be approved by someone who was already able to approve it prior to the change being made in order to have any effect.

Well, okay, but the same thing is true for everything before the approved revision.

Oh, yeah having that class helps a lot, I wanted to style something like this in addition to having the two texts there. I guess I could just do everything with css then,

I just really want to preserve the concept of edits being "pending" - actually I might use "Approve [pending]" and "Set as approved" as the two texts. (One other possible option could be to do it visually with arrows in opposite directions after the text "approve".) When I first looked at AR on the one wiki we installed it on, I was really confused looking at the page history for about 10-15 minutes before realizing what was going on with there being only one approved edit at a time, and I think if I was confused a bit then other users will be way more confused, particularly those who are used to the FR concept. Also this seems like relatively minor change to implement in order to significantly increase compatibility with the other paradigm, unless I'm wrong.

1f, 2c) updated description again.