Jump to content

Skizzerz

Administrators
  • Posts

    160
  • Joined

  • Last visited

Posts posted by Skizzerz

  1. 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.

  2. 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.

    1. Set up SPF records in your DNS to let providers know which servers are authorized to send email from your domain
    2. 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
    3. Set up MX records in your DNS so that you can receive bounce emails which contain further details of rejections
    4. 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).

  3. 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.

  4. 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.

  5. If you still have access to your old database server (the server itself, not just backup files):

    1. Export it as a .sql file using the mysqldump program via the command line
    2. Copy the .sql file generated to the new computer
    3. 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.

  6. The location of your real files should not match the virtual directory you set up for short URLs.

    Good:

    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.

  7. 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.

  8. 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.

  9. 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.

  10. 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)
  11. 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 present in package managers from e.g. Debian stable for quite some time. Unless you are doing a very exotic setup (or if you're on Windows) there's generally no need to install the underlying dependencies manually.

  12. 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)

  13. Check Special:Version on the wiki to see if they have any extensions that seem related to the feature in question, and then searching mediawiki.org about it is your best bet. There's no one answer that will 100% work for any arbitrary feature. For things that appear in the page itself, editing/viewing the source of the page may help as well (you may need to go through some nested template rabbit holes first though)

  14. You need to login to the API first (generally this is done by using a bot password generated at Special:BotPasswords). You will need to ensure the bot password used has the appropriate scopes to do whatever you want it to do (such as edit pages).

    The login API will attempt to set some cookies. You are required to save these cookies in your python script and present them to all future API requests, so it can pull up your logged-in session.

  15. You need to use the #tag parser function, see https://www.mediawiki.org/wiki/Help:Magic_words#Miscellaneous for more information on that. <ref> does not allow embedding any wiki markup inside of it, but {{#tag:ref}} does

    Example (untested, may require modification to work):

    {{#tag:ref|Contents of the primary footnote/reference goes here.{{#tag:ref|Secondary footnote/reference goes here|name=secondary}}|name=primary}}

    This example is the equivalent of the following. Note the following markup does not work, this is meant to just give a better visualization of what the above text is doing:

    <ref name="primary">Contents of the primary footnote/reference goes here.<ref name="secondary">Secondary footnote/reference goes here</ref></ref>

     

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.