Change 447009 had a related patch set uploaded (by Samwilson; owner: Samwilson):
[mediawiki/extensions/Cargo@master] Add script to POST page-purging request, to avoid confirmation step

https://gerrit.wikimedia.org/r/447009

@Samwilson - very interesting... I didn't know about that Purge extension, even though apparently it's been around since 2009!

This brings to mind another option, which is to get rid of Cargo's "purge" tab altogether. It's not as crazy as it sounds - the purge tab was always kind of an odd fit in Cargo. It's based on SMW's own purge tab (though there it's labelled "refresh"), and it serves a useful purpose, but maybe anyone who wants this functionality can just use the Purge extension instead...

But as far as this patch is concerned: is it necessary? According to https://www.mediawiki.org/wiki/Manual:User_rights , anyone who has the "purge" right can purge without a confirmation step - and by default that right is given to everyone in the "user" group. (I seem to remember that this right before only belonged to "sysop", though I could be wrong.) So does this really solve any problems?

Those are good points! I hadn't realised that it wasn't supposed to require the confirmation step... I'm always getting it though, even as a sysop. I'll try to figure out why.

And yeah, the purge tab could totally be removed from Cargo I reckon, and if anyone wants it they can just use the Purge extension. That sounds sensible, if you think it's a good way to go.

@Yaron_Koren do you have it working without the confirmation step? Because it looks like it needs to be POSTed: https://gerrit.wikimedia.org/g/mediawiki/core/+/master/includes/actions/PurgeAction.php#61

@Samwilson - yes, I don't need to press the confirmation button. I'm guessing it's because of the lines right above the line you linked to. (Though I don't know what the pingLimiter() function does.)

This would be ironic, but could it be that the Purge extension itself is somehow messing up your permissions? I ask because its documentation says that it defines its own 'purge' user right, for dictating who sees the tab - but 'purge' is already the name of the MediaWiki permission for skipping the confirmation step. Was that a big error on the part of the Purge extension developers? Or is it not as big a deal as it sounds?

Hm good thought! But no, even with the Purge extension turned off (and Cargo turned on) I get the "Clear the cache of this page?" confirmation form. I've verified that my user has the purge right. I can't figure it out. :(

@Yaron_Koren I'm still trying to track this down. Do you have any ideas of how to get confirmation-free purging to work?

Sorry, no. It should just work automatically...

In T200054#4532811, @Yaron_Koren wrote:

Sorry, no. It should just work automatically...

I think that used to be the case, but it was changed in this patch for T135170. Maybe you're using an older version of MediaWiki?

In T200054#4440087, @Yaron_Koren wrote:

This brings to mind another option, which is to get rid of Cargo's "purge" tab altogether. It's not as crazy as it sounds - the purge tab was always kind of an odd fit in Cargo. It's based on SMW's own purge tab (though there it's labelled "refresh"), and it serves a useful purpose, but maybe anyone who wants this functionality can just use the Purge extension instead...

Would you like me to prepare a patch that gets rid of the purge tab all together? Would be a simpler change. :)

Yes, you're right - I upgraded my MediaWiki version about a month ago, and noticed that change of behavior - I kept meaning to write something about it here, but forgot.

So does the Purge extension still work better, i.e. avoids the need for a confirmation step?

Yeah, Purge hijacks the link click and sends a POST request to the API to do the purge, and then redirects back the page. No confirmation click required.

It probably makes sense to leave it to the Purge extension and remove the extra link from Cargo (and maybe suggest in the Cargo docs and upgrade notes that people install Purge). But I'm happy either way. If the click-to-POST is added to Cargo then people can uninstall Purge.

Alright. I can think of three basic approaches here: (1) add the relevant JS (I think it's just a short JS file) to Cargo, to enable the skip of confirmation; (2) add to Cargo a check to remove its "purge cache" tab if the Purge extension is already installed; and (3) just get rid of the "purge cache" tab in Cargo.

What do you think? As we said, the "purge cache" tab doesn't really make sense for Cargo. On the other hand, maybe it's useful enough that it should be there, regardless of the logic involved.

Yeah, my patch above adds the required JS: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Cargo/+/447009/2/libs/ext.cargo.purge.js

But overall, I think that because purging isn't an integral part of Cargo, it should live in a separate extension. I reckon remove the link from Cargo.

I don't think the extra complexity of checking for Purge is worth it, because that extension literally doens't do anything else, so no one would need to have both Cargo and Purge installed if Cargo were to do the purging.

Oh, right, I forgot about the patch!

You're probably right that getting rid of the "Purge cache" tab is the right thing to do. Let me ask you this, though - and it's something I've wondered about for a long time: why does the "purge" action - uniquely, I think, among actions - not have a tab defined for it in core MediaWiki?

I'm not really sure, other than that it's seen as something of a hack. See for instance: T56902: Deprecate and remove the purge action from MediaWiki

I'll prepare a patch to remove the link from Cargo.

Change 466840 had a related patch set uploaded (by Samwilson; owner: Samwilson):
[mediawiki/extensions/Cargo@master] Remove 'purge cache' page tab

https://gerrit.wikimedia.org/r/466840

I think I've removed it correctly.

Change 466840 merged by jenkins-bot:
[mediawiki/extensions/Cargo@master] Remove 'purge cache' page tab

https://gerrit.wikimedia.org/r/466840

Change 447009 abandoned by Samwilson:
Add script to POST page-purging request, to avoid confirmation step

Reason:
The purge link has been removed.

https://gerrit.wikimedia.org/r/447009

Thanks!

@Samwilson - now I feel like I've made a mistake with this... I've had an uneasy feeling about this change almost as soon as I checked it in. I think part of the issue is that I never thought to actually look at the Purge extension's code until today - I didn't realize that the vaunted JavaScript code that Purge uses to override the confirmation screen is only about 12 lines long - and not very complex. It hardly seems worth it to force admins to download this extension just for this little bit of code. And purging the cache does seem pretty integral to the "Cargo admin experience".

Did you actually create a patch that adds this JS code to Cargo? It wouldn't be hard to add it in any case; I just can't remember now.

And what do you think about re-adding this to Cargo?

I'd be happy to see it as part of Cargo; whatever you think is best. The patch I did is https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Cargo/+/447009 and I think it does everything it needs to. Have a look.

There are other uses for the Purge extension, and I don't think it's a huge burden to have to install it.

Ah, fantastic. But what other uses are there for the Purge extension?

Also - how difficult would it be for you to create a patch, or patches, to undo the two relevant recent changes (81c579abc61d and 0dc63863222c)? I'm not sure I know how to do it.

@Samwilson - any thoughts?

Change 447009 restored by Yaron Koren:
Add script to POST page-purging request, to avoid confirmation step

https://gerrit.wikimedia.org/r/447009

Change 447009 merged by jenkins-bot:
[mediawiki/extensions/Cargo@master] Add script to POST page-purging request, to avoid confirmation step

https://gerrit.wikimedia.org/r/447009

Sorry for my silence, I've been traveling. :)

I think you've solved this now. Seems to work in my testing.

Ah, that explains it! Great - yes, it works for me too. I think this is the better solution. Thanks for creating both patches.