I could see the titleblacklist being created, but the testing through api.php have failed due to an unknown reason, though the syntax seems to be correct (as they work fine on other wikis).
Sep 9 2019
@Reception123 Yes. Sorry for the delay myself. Had been busy on other projects.
Jul 13 2019
Marked as resolved.
@Mlfoster Now I have disabled it, and you should be able to manage extensions.
Well, Stewards should be able to access private wikis without member rights, and even if I didn't have the permission to view the wiki, I wouldn't be forcefully logged out on other private wikis as it happened there.
Something is going wrong with your wiki - the custom domain (https://theliteratureproject.org ) will return error 404, and when I tried to fix it on the original domain (https://theliteratureproject.miraheze.org ), I'm forced to log out due to an unknown reason. I think only sysadmins can fix it.
Jul 12 2019
I think it's because you will need managewiki-restricted permission to manage extensions when restricted extensions are enabled (including but not limited to Auto Create Category Pages).
Jul 7 2019
Jun 23 2019
True, but don't you have a backup to restore all of them, as it looks like the similar issues have happened across most non-English wikis?
P.S. It's kind of random - in most cases, status updates do work fine.
Jun 18 2019
May 29 2019
Hmm, I wonder why that happened. Perhaps something related to a past incident?
May 24 2019
I have found out the error occurred because the wiki already exists. However, the message sounds like some kind of error (than telling why the wiki cannot be created), and would like to have it fixed.
May 23 2019
Apparently, the Wiki Manager permission doesn't work as intended (while wiki creator, CVT, and interwiki-admin works fine). I will report this as an update.
See T4403. I will fix your permissions as the local crat there.
May 20 2019
Thanks for your fix, which I have confirmed that it works. However, the thing is, the wiki does NOT exist, with the non-customized URL resulting in error 404 and custom domain resulting in DNS_PROBE_FINISHED_NXDOMAIN.
May 19 2019
Mar 18 2019
So maybe asking for donation through centralnotice might be the solution for the time being. Some users have already suggested it on our discord, and perhaps it's indeed high time we did so.
Mar 17 2019
I have moved the page to a log page for a quick fix. I have checked the source, and it seems like it has something to do with the use of templates.
Mar 4 2019
They would like to know the ETA of this import, and whether there will be an edit conflict if they import stuff manually using Special:Import and/or Special:Upload. Could you tell us?
Feb 28 2019
@Void I think you need to add a plus before uncyclopedia2wiki at line 3303. It seems to be the only difference I could find. (though I may be wrong, because it's rather a guess and I'm not an expert on this topic)
Feb 19 2019
It's actually an issue seen across whole Mirhaeze (such as this page), and I'll triage it as high priority.
Jan 21 2019
I'll set it to high priority, because the broken subpage links have been seen across multiple wikis, including Usopedia and meta. It's probably that the subpages on mainspace which are going wrong.
Jan 12 2019
Hmm, so I guess it was related to the local gadget. A similar problem also happened on Usopedia (which I fixed it by myself by deleting the script referring to non-listed site), and there might be similar issues coming up on other wikis.
Jan 10 2019
Hmm, it was working fine on Illogicopedia (where I found that filter), but I guess we need some improvements for Miraheze.
Jan 6 2019
Dec 31 2018
Dec 28 2018
Dec 20 2018
Nov 10 2018
Nov 8 2018
Uh, after I posted this, I found this phab task and understood that it's just a natural process during update.
Sep 2 2018
@Wedhro I thought the Italian community has decided to move the wiki to a server hosted by Carlb. Can you tell me what's going on? And which version will be the official one as the final result?
Please see CVTwiki. It did stop from time to time due to various kinds of errors.
Hmm, sounds good to me (though the speed limit is sometimes problematic for my activities). Thanks for your comment.
Sep 1 2018
P.S. I also wish I could edit the reason. Not all massive blocking is due to proxies.
Aug 31 2018
Reopened per above.
Aug 27 2018
This is probably because the website in question is not whitelisted. We had a security issue, and currently only trusted external sites are whitelisted. You can ask for the site(s) to be whitelisted or manually upload the images on your wiki.
I have to reopen the task, because the image from https://mirrors.creativecommons.org is not displayed properly; at least, it looks like you're using the one from the mirror website for CC BY-NC banners, which is:
My pleasure :)
Aug 26 2018
- Script removal should be done by oversighters (so that local admins cannot restore).
- One of the problems is that the guy who made the script has been inactive for months (see this). I'm not sure whether anyone can make a contact.
- Also, at least one of the admins there hosts multiple wikis; those wikis should also be investigated (I'll send a list on CVT channel if necessary).
Aug 24 2018
Wow, that was fast. Thanks as always :)
I've enabled protection for the next 24 hours. Can you do it within it? Thanks.
Aug 22 2018
To who perform the modification: can you notify me beforehand on Meta so that I can protect the site from being edited?
Aug 12 2018
Turning things back.
Aug 5 2018
Confirmed. Thanks for your help :)
Thanks, but I'd like to reopen the task.
Aug 4 2018
Aug 3 2018
Aug 2 2018
As I mentioned above, those who can access the logs should be limited to: admins (local), BCs (local), CVTs (global), Stewards (global), and Sysadmins (global).
The userpage itself can be dangerous, because some vandals try to register address/phone numbers for their user name. I have a filter to prevent most of them. but still it's not 100% perfect, and those vandals can intentionally create logs (which happened in my previous wiki before moving). Thus, that is still not enough.
the very "what" can contain private info or hints (because I've blacklisted creation of some pages).
Although all the filters are private, anyone can see which filter was triggered on which actions, pages, etc. from Special:AbuseLog. This is the very page I'd like to have it hidden.
Uh, well, I guess I forgot to add sysadmins. They should also be able to see the logs. Thanks again.
@Reception123 It's OK, I can wait.
As you can see here, there's this ⧼log-show-hide-comment⧽ displayed, and now we can't even toggle to display comments by clicking it.
Jul 28 2018
Thanks for your help, but I checked and it doesn't seem to be working properly. I want the logs displayed but it isn't, with a broken link option.
Jul 26 2018
Jul 25 2018
I found that it can be done by setting $wgCommentsSortDescending to "true" (which the default value is false). Thus, it's not so difficult, and I think you guys can handle it soon. Thanks again.
Uh, we're still discussing, but I'll reopen/repost the task when we make a final decision to create another namespace. So you can just close it for now.
Jul 16 2018
Actually, you don't. You can do it by yourself from Special:ManageWiki. Follow the guide written here.
Jul 15 2018
I think the MobileFrontend is enabled by default. As for the VisualEditor, you need to make a request anyway, though.
Jul 14 2018
See the comment above. It's only half resolved.
Thanks, but I also requested it to be shown on logs by default. I still have to click "Show comments" button for it.
OK.. If that's the case, we might decide not to migrate contents that should be kept private (or create another wiki). Thank you for your response.