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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Jan 28 2022
Jan 28 2022
Turtle84375 awarded T8575: Data Dump Restore Possible? a Like token.
Jan 18 2022
Jan 18 2022
Jan 6 2022
Jan 6 2022
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).
Jan 5 2022
Jan 5 2022
May 14 2021
May 14 2021
Dmehus awarded T7290: Internal Error while Batch Testing with Abuse Filter a Like token.
May 13 2021
May 13 2021
Turtle84375 awarded T7290: Internal Error while Batch Testing with Abuse Filter a Like token.
Turtle84375 changed the status of T7290: Internal Error while Batch Testing with Abuse Filter from Invalid to Resolved.
@Reception123 Thanks for letting us know!
Redmin awarded T7290: Internal Error while Batch Testing with Abuse Filter a Like token.
May 12 2021
May 12 2021
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.
Turtle84375 added projects to T7290: Internal Error while Batch Testing with Abuse Filter: MediaWiki (SRE), Extensions.
I think a bureaucrat could do that through Special:PasswordReset.
Apr 28 2021
Apr 28 2021
Turtle84375 awarded T7204: Please Clear my Echo Notifications a Like token.
Apr 8 2021
Apr 8 2021
Dmehus awarded T7104: Extension:MyVariables not working on one wiki a Like token.
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.
Dmehus awarded T7109: Please Clear my Echo Notifications a Like token.
Apr 7 2021
Apr 7 2021
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
Turtle84375 updated subscribers of T7103: Warn users when attempting to remove managewiki right from self.
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.
Turtle84375 updated subscribers of T7103: Warn users when attempting to remove managewiki right from self.
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.
Apr 2 2021
Apr 2 2021
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.