Skizzerz

Can you provide the full error message? It should tell you why it's unable to delete that directory. If it's a permissions issue, you'll need to ensure that composer is running under the correct account name. Your host should be able to assist you with determining that.

This can be achieved via the preloading feature, see https://www.mediawiki.org/wiki/Manual:Creating_pages_with_preloaded_text That link also has some extensions that can automatically insert the preload text when trying to create a new page.

It should be safe to ignore those errors. If you are not planning on developing MediaWiki, it would be best to suppress those by turning error_reporting off in your php.ini

Yes, you need a valid working email setup for most email providers to not outright reject emails from you. This is largely outside the scope of wiki management and in the scope of general server management. Set up SPF records in your DNS to let providers know which servers are authorized to send email from your domain Ensure your IP address is not listed in any DNS blacklists, and if it is, go through the processes of those lists to get it delisted Set up MX records in your DNS so that you can receive bounce emails which contain further details of rejections In MediaWiki, configure the outgoing email address appropriately With all of those set up, check system logs to ensure that the mails are being accepted and sent onwards. If they are, checking for bounce replies is helpful to see why something is rejected. Otherwise check firewalls and other things that may block connectivity. If you are attempting to send email from a home server, it is possible your ISP is implementing blocking of their own and you may need a completely different setup (such as connecting to a remote SMTP server to send email).

This is a browser security feature; most browsers do not allow clicking on file links from an http/https website. There is no solution to make it work, upload the relevant file locally to your wiki and link to it using regular wikilinks.

This forum is not for Wikipedia support, so we can't provide much help to you here. The easiest thing to do would be to try resetting your password while on a different IP (for example, if you got that message on your home wifi, try a cellular connection). Failing that, your best bet is to reach out to the Wikipedia admins for assistance; the block message should contain some instructions on how to do that.

By default the extension will omit the tracking code if your browser sends a "Do Not Track" signal to the website. I am guessing this is what is happening for you, as some more privacy-focused browsers send this signal by default, and most other browsers can be configured to send that signal in their privacy settings. The extension page on mediawiki.org goes into more detail on how to configure this behavior, as well as a means of exempting user groups from being tracked.

If you still have access to your old database server (the server itself, not just backup files): Export it as a .sql file using the mysqldump program via the command line Copy the .sql file generated to the new computer Import the .sql file using the mysql program via the command line If you no longer have access to the old database server, you are potentially out of luck if your existing .sql file did not import successfully.

The location of your real files should not match the virtual directory you set up for short URLs. Good: Files in /w, e.g. https://example.com/w/index.php Article path in /wiki, e.g. https://example.com/wiki/Main_Page Bad: Files and article path in the same location (e.g. both in /wiki) Files and/or article path in website root You are in one of the "bad" cases which is why those rewrite rules are not working for you. Extra care is required when doing one of the configurations listed above as "bad", and even with a correct configuration certain article names matching file or directory names will become impossible to create on your wiki.

Correct

If it's big and may cause timeouts on the web, use the importDump.php maintenance script from the command line. This involves first uploading the xml file onto the server somewhere, and then running the script on the file. It will still take a long time, but will not time out because maintenance scripts do not have time limits on execution.

I recommend taking a look at the help page about Templates. It goes over what templates do (and don't do), and how you can easily copy templates from one wiki to another. Keep in mind that many templates require extensions such as ParserFunctions, Scribunto, or TemplateStyles to be installed on your wiki before they will work properly. You can find that help page at Help:Templates on mediawiki.org. You don't need a template to make an FAQ page -- the template is just some additional wikitext behind the scenes.

You can define the MW_CONFIG_FILE constant somehow (such as via the auto_prepend_file php.ini setting) to be the absolute path to the settings file you wish to load. Note that this must be a path on your server's filesystem, not a URL.

Unfortunately, there is no way to accomplish this built into MediaWiki, and I do not see any extensions currently existing that perform this task.

Lack of highlighting generally indicates that the call to pygments is failing for some reason or another. You may wish to temporarily enable debug logging to better understand why this is happening. Chances are the issue lies with your choice of OS: I believe that the extension only ships a linux binary of pygments, but not a mac binary. You may need to install pygments separately and point to it via $wgPygmentsPath.