In T8575#174405, @Reception123 wrote:

In T8575#174322, @Anpang wrote:

In T8575#173928, @Reception123 wrote:

@Turtle84375 So would you like both the XML and images to be imported by us?

I'm not turtle but could you try do that now?

Well I'd like them to confirm that that is what they want first.

In T8575#173414, @Pppery wrote:

Actually, it looks like https://archive.org/download/turtlewiki-datadump/index.php is a XML dump (despite the file extension), and https://archive.org/download/turtlewiki-datadump/index_(1).php is an image dump (actually a tar.gz file, despite the extension).

@Reception123 Thanks for letting us know!

In T7290#144790, @Reception123 wrote:

I've also noticed this. This is an upstream issue so unfortunately there's nothing Miraheze can do about this except wait for upstream to fix it.

I think a bureaucrat could do that through Special:PasswordReset.

In T7104#141011, @Reception123 wrote:

We weren't aware of this conflict until now. Unfortunately, this does seem to be an upstream issue and there is nothing we can do unless they fix it. I've created upstream task: https://phabricator.wikimedia.org/T279617 and restricted enabling both extensions at once on Miraheze.

In T7109#140960, @Dmehus wrote:

@Reception123 has a documentation page here with the query that needs to be run for the actioning SRE.

In T7104#140882, @Reception123 wrote:

@Turtle84375 Could you please try disabling the ApprovedRevs extension and then checking if it works after that? (you may need to purge the cache: https://www.mediawiki.org/wiki/Manual:Purge). If it does work after you've removed ApprovedRevs, there is likely a strange conflict between the extensions that will likely be Upstream

In T7103#140875, @Universal_Omega wrote:

In T7103#140863, @Joritochip wrote:

In T7103#140860, @Turtle84375 wrote:

In T7103#140836, Universal_Omega wrote:

• ManageWiki should blacklist the entire deletion of the bureaucrat group, in my opinion but that's just an opinion.

Some people like to remove and/or rename the bureaucrat group to suit their own/their wiki's purposes, so I'm not sure the last one is really the best idea, as far as keeping Miraheze wikis as founder-run and customizable as possible. I'm all for the other suggestions, though.

I do not think that suggestion was intended to be serious, and if it were it would probably need to be a separate task.

Yeah, it was just a thought. One I since realised was not a great one.

In T7103#140836, @Universal_Omega wrote:

• ManageWiki should blacklist the entire deletion of the bureaucrat group, in my opinion but that's just an opinion.

Success! I did something a little simpler, I just deleted the specific revision that wasn't patrolling, leaving the other "patrolled" updated revisions of the file intact. I'm not sure what went wrong in the first place, but this is now resolved for the moment. Thanks, Dmehus!

In T7079#140174, @Dmehus wrote:

I have seen this on Miraheze Commons. It's related to uploaded files, but I'm not sure this is fixable within Miraheze. It may be an upstream bug. My best advice would be to try deleting all versions of that file, including the file page, then restore one or both. I know that magically patrols unpatrolled revisions on pages, so it may work on files as well.