Skizzerz

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 artic

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.

(Moderation: moved to MediaWiki Support forum and removed personal details from message) The functionality you're after is achieved with the MultimediaViewer extension.

Blank page indicates a PHP error: see here for how to diagnose it: https://www.mediawiki.org/wiki/Manual:Common_errors_and_symptoms#You_see_a_Blank_Page I note that your wiki is currently running 1.31.0 which has known security vulnerabilities. You should ensure you always keep MediaWiki up-to-date. Right now, that means upgrading to one of the following versions: 1.31.12 LTS (EOL June 2021) 1.35.1 LTS (EOL September 2023)

MediaWiki 1.30 went end of life a year and a half ago (June 2019), and is no longer receiving any security or maintenance updates. You should definitely upgrade that wiki if it is exposed to the internet in any fashion. See Version lifecycle for more information on MediaWiki EOL dates. For PHP and MySQL versions, check the Compatibility page The general recommendation is to install the dependencies (apache, PHP, mysql) via your distribution's package manager and then keep them updated via said package manager on a regular basis. MediaWiki remains compatible with the older versions pr

If you're already on Apache 2.4.x, upgrading it to a later version of 2.4.x shouldn't introduce any issues with upstream applications. There should be nothing you need to do for your wiki, just upgrade apache. (that said, you should also endeavor to keep the rest of your tech stack up to date, which means updating mysql, mediawiki, your server's kernel, etc. as things come in)