Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Skizzerz

  1. The "wiki ID" is a fancy term for "the name of the database where the wiki lives." So, something in your configuration is not setting the database name and/or database prefix correctly for this wiki. My guess has to do with the fact that it's a double subdomain "en.en" and your mapping of subdomain to database name is not changing that period to something else -- periods are not valid in database names or table prefixes.
  2. Skizzerz

    mw-config blank while trying to upgrade

    Did you get the new MediaWiki files via Git or by downloading the tarball? If you got it via Git, you will need to install and update all of the dependencies yourself. See here for more information. If you used the tarball, it appears that some of the files didn't get extracted properly or were possibly missed. Re-download the tarball and re-extract it to a new, empty folder. Then copy over your LocalSettings, updated versions of extensions, and images to the new folder. It's always recommended when upgrading with a tarball release to extract to a new folder as there may be issues caused by leaving around files from an old release that were removed in a future release. Unless you are already familiar with using Git and feel comfortable with your systems administration skills, I recommend using the tarballs.
  3. Skizzerz

    mw-config blank while trying to upgrade

    A blank page indicates PHP errors. See the how to debug manual for information on displaying the error messages so you can get more information. You may want to insert those error reporting lines at the top of mw-config/index.php instead of in LocalSettings.php.
  4. Very odd, is your wiki public? If so, please provide a link to it. If not, please provide the following info: What version of MediaWiki are you running? What extensions do you have installed? In either case, check your webserver configs (for example, the conf file as well as .htaccess files for apache) to see if there's any errant redirects or rewrites in there that is causing it to go elsewhere.
  5. Skizzerz

    Image Resize is not working!

    Yes, you'll need to follow up with them. If changing skins doesn't fix the thumbnails, however, then that wasn't the issue that we're after.
  6. Skizzerz

    Image Resize is not working!

    I see that MediaWiki is encountering some error when attempting to generate the thumbnails, however your server is not configured to report error details (this is usually considered a good thing from a security point of view). To get more information, you will need to enable debug logging and then attach the debug log here. To do that, set the following in LocalSettings.php: $wgDebugLogFile = '/path/to/debug.log'; You will need to modify this path to be a directory that your user account can write to, but is ideally not accessible via the web. Once you enable that, edit one of the pages that has a thumbnail error and save. This will generate a lot of output to that log file, including the error message for what is going on with the thumbnail. Once you get that log file after the page edit, you can remove that line from LocalSettings.php so that it does not fill up your disk with debug logs. The debug log will also contain some sensitive data which could allow someone to hijack your session, so I recommend taking the following security precautions: Do not log into any accounts while debug logging is active. Make sure you're already logged in beforehand. After turning debug logging back off, log out of your account in order to delete your session data from the wiki.
  7. Skizzerz

    Image Resize is not working!

    Thanks! Can you link to the particular page where the thumbnail is not appearing?
  8. Skizzerz

    Image Resize is not working!

    There are a few possible reasons for this, but without more information (such as a link to your wiki, if it is public), it is difficult to determine what exactly is going on here. This page has some possible issues and resolutions, but it is not comprehensive and also not very comprehensible in some cases. Perhaps the first thing to check is to see if you have $wgUseImageMagick = true; in your LocalSettings.php. If not, add it in.
  9. Block the offending user(s). If your wiki is open for anyone on the internet to register accounts, keep in mind that many vandals are quite persistent and will come back ("evading the block") to bother you again. Look into the guide on combating vandalism. It contains a number of extensions and configuration parameters that can be used to detect and outright prevent some behaviors. Determine a solution suitable for your community. Perhaps you rate-limit new accounts to 1 edit per 5 minutes until they've reached a certain time and/or edit threshold ("autoconfirmed"). Perhaps you run bots that patrol for bad actors and send out notifications for humans to look at before things get too out of hand. The exact solution is not a one-size-fits-all sort of thing and depends largely on your community and what you want the wiki to achieve. Increase monitoring of RecentChanges so that similar events can be caught more quickly in the future and the offending user blocked before they cause massive damage. Ensure you have scheduled backups of the wiki database, so that in a worst-case scenario type of thing you can roll back to a known-good backup. A large benefit of MediaWiki is that pretty much every action a user can take can be reverted. It's a time-consuming process to revert hundreds of edits manually (bots, extensions, and maintenance scripts can help with this), but it's doable. The amount of attention this requires may be beyond the capabilities of some small wikis, however. Those wikis may find it easier or better to implement measures that block or restrict bad behavior up front (even if it has a chance of affecting legitimate users as well) simply due to the resources needed to quickly patrol everything shortly after it happens are nonexistent. The end solution is largely up to you, however. See the link I gave for some tips on tools you can use that may help.
  10. Skizzerz

    Getting logged out after submitting a page Change

    I'm not sure if this will actually help or not, but try adding the following into your LocalSettings.php: $wgTmpDirectory = '/is/htdocs/user_tmp/wp10565584_JYRT1G91HG'; If that doesn't help, the next step is to enable debug logging for sessions to get greater insight into what's going on behind-the-scenes. See this article for information on how to set that up. To avoid tons of noise in the file, you may want to only enable logging for the session debug log group.
  11. Skizzerz

    Getting logged out after submitting a page Change

    Can you provide some more info? The output you gave makes it seem like MediaWiki thinks the session being sent to it is not valid/expired and therefore spins up a new one. There are a wide variety of causes for this, none of which are particularly obvious or easy to spot. The following information would be very helpful in diagnosing this further: 1. Your phpinfo() for the server. Easiest way to get this is to run php -i > phpinfo.txt from the command line; the information will be stored in a new file named "phpinfo.txt" which you can then upload as an attachment. 2. Any session-related or cache-related settings in your LocalSettings.php (do not upload your entire LocalSettings.php as it contains private info such as database passwords and secret keys)
  12. The page Special:AllPages lists every page on your wiki. You can link to it on your main page via [[Special:AllPages]] or you can include it as a list with {{Special:AllPages}}. If you're looking for anything more complicated than that, you'll likely want to install and use the DynamicPageList extension.
  13. Skizzerz

    Media Wiki connect speed

    The easiest way to speed up the site is to configure caching. Install the apcu PHP extension (this will require root-level access to your server; if you don't have that then ask your host to do it for you), and then set $wgMainCacheType = CACHE_ACCEL; in your LocalSettings.php. See here for more details on performance tuning, including other methods like opcode caching (this might already be set up, but make sure it's turned on) and database query caching (I recommend using the excellent "mysqltuner" script for this)
  14. That is being created by the CharInsert extension combined with the MediaWiki:Edittools page on your wiki. The link to the extension contains more documentation and examples of how to set it up. More advanced uses (such as what you see on Wikipedia with the "Insert" drop-down) also require the Gadgets extension.
  15. Method 1: Create or edit the page on your wiki MediaWiki:Retrievedfrom while logged into an Administrator account and delete the contents (so it is a completely blank page). That should suppress the message from appearing at all. Method 2: Create or edit the page on your wiki MediaWiki:Common.css while logged into an Administrator account and add the following code to the bottom: /* hide the "Retrieved from" message */ .printfooter { display: none; }
  16. These are called "Page status indicators." You can read more about them here.
  17. Skizzerz

    MinervaNeue text formatting not loading

    Could be a number of things; do you have a link to your wiki that you can share? This would let me poke around with my browser devtools and see if I can uncover anything (perhaps there are permissions issues accessing the files, or its looking in the wrong place, or there's a version mismatch between your MobileFrontend/MinervaNeue version and MediaWiki version, or it could be working just fine now but a bad cache is making it appear to not be the case)
  18. Skizzerz

    MinervaNeue text formatting not loading

    Try putting the wfLoadSkin underneath the wfLoadExtension call; I believe the order is important here and loading the skin first will cause issues.
  19. This indicates a misconfiguration in your email settings in MediaWiki. Can you please post the relevant bits of your LocalSettings.php that relate to email?
  20. Skizzerz

    MediaWiki 1.31 LTS Now Available

    MediaWiki 1.31.0 has now been officially released. This is a Long Term Support (LTS) release, meaning it will receive bugfixes and security updates for a period of 3 years (until June 2021). Below is a highlight of some of the release notes. To view the full release notes, click here. New System Requirements MediaWiki 1.31 now requires PHP 7.0 or higher. HHVM 3.18.5+ is still supported, but any users still on HHVM should look into migrating into PHP 7, as HHVM will no longer be supported in the future as Facebook will be dropping PHP support from the product. More Bundled Extensions The following extensions are now bundled with the MediaWiki download: CodeEditor -- provides a more friendly editing UI when editing CSS and JS pages MultimediaViewer -- opens clicked images in a lightbox instead of leading directly to the image page OATHAuth -- provides 2-factor authentication (2FA) support using apps such as Google Authenticator Replace Text -- provides a special page for admins to perform replacements across multiple pages of the wiki, for both page content and page titles Upgrading When upgrading MediaWiki versions, it is always important to take a backup of both your files as well as your database, as upgrades cannot be "rolled back" once performed. It is recommended to unpack the new files into a new, empty directory and then move over needed files (LocalSettings.php, images, extensions, skins) rather than unpacking the new files directly over the old ones. Unpacking over the old ones could cause files that were removed in 1.31 to remain in your directory tree, which could cause PHP errors down the line or cause security issues as those files will no longer be updated. The database changes in this release could take a while to run on large wikis.
  21. Skizzerz

    HTTPS Help

    You'll possibly need to modify some settings in LocalSettings.php as well. If you have any things in .htaccess, they may also need changes. As a note, when doing custom ports the port goes after the server name and before the path, e.g. https://example.com:82/mediawiki The redirect in your conf is technically unnecessary so long as you hardcode https into $wgServer in MediaWiki itself -- in that case, the wiki will take care of redirecting the user. Once you have everything working, set up HSTS (HTTP Strict-Transport-Security) so that visitors' browsers will automatically use https in the future.
  22. Skizzerz

    Tables & Templates

    Take another read through https://www.mediawiki.org/wiki/Help:Tables For putting multiple columns in a single line, use !! to separate them for header rows and || to separate for normal rows. If you have formatting, match the ! or |. {| class="wikitable" |+ Caption ! scope="col" style="color:red" | Column 1 !! scope="col" style="color: blue" | Column 2 !! scope="col" style="color: green" | Column 3 |- | data-sort-value="R1C1" | [[R1C1]] || data-sort-value="R1C2" | [[R1C2]] || data-sort-value="R1C3" | [[R1C3]] |- | data-sort-value="R2C1" | [[R2C1]] || data-sort-value="R2C2" | [[R2C2]] || data-sort-value="R2C3" | [[R2C3]] |} Produces the following: If that is what you are doing, try doing each column on its own line, or make use of HTML table markup (<table>, <tr>, <th>, and <td>) instead of using wiki markup for tables.
  23. Skizzerz

    Tables & Templates

    In MediaWiki markup, {| indicates the beginning of a new table and |} the end of a table. Your table row template should therefore not include those lines. I'm not entirely sure why you want to turn this into a template (as it is, in my opinion, more complex than just putting the raw table syntax on the page). If you do want to go down this route, you'll need to split things into 3 templates instead of wrapping it all into a single call to {{Table}}: [[Template:Table header]] would contain the table header, along with the parameters to make it sortable, collapsible, etc. [[Template:Table row]] (or just [[Template:Row]] if you want to save typing) would contain the markup to create a single row [[Template:Table footer]] would contain the final closing markup |} for the table and any other footer data you want Perhaps something like the following: Template:Table header {| class="wikitable {{#if:{{{sortable|}}}|sortable}} {{#if:{{{collapsible|}}}|mw-collapsible}} {{#if:{{{collapsed|}}}|mw-collapsed}}" {{#if:{{{center|}}}|style="text-align: center"}} {{#if:{{{caption|}}}| {{!}}+ {{#if:{{{caption-style|}}}|style="{{{caption-style}}}" {{!}} }} {{{caption}}} }} ! scope="col" | {{{1}}} {{optheader|{{{2|}}}}} {{optheader|{{{3|}}}}} {{optheader|{{{4|}}}}} {{optheader|{{{5|}}}}} {{optheader|{{{6|}}}}} Template:Optheader {{#if:{{{1|}}}| !! scope="col" {{!}} {{{1}}} }} Template:Table row |- | data-sort-value="{{{1}}}" | [[{{{1}}}]] {{optrow|{{{2|}}}}} {{optrow|{{{3|}}}}} {{optrow|{{{4|}}}}} {{optrow|{{{5|}}}}} {{optrow|{{{6|}}}}} Template:Optrow {{#if:{{{1|}}}| {{!}}{{!}} data-sort-value="{{{1}}}" {{!}} [[{{{1}}}]] }} Template:Table footer |} Then, you would use it as follows: {{table header |sortable=1 (if you want it to be sortable, otherwise leave this line out) |collapsible=1 (if you want it to be collapsible, otherwise leave this line out) |collapsed=1 (if it's default collapsed, otherwise leave this line out) |caption-style=font-weight: bold; ... (optional, you can leave this line out if no style) |caption=Caption goes here (optional, you can leave this line out if no caption) |First column header (required) |Second column header (optional, you can leave this line out) |Third column header (optional, you can leave this line out) |Fourth column header (optional, you can leave this line out) |Fifth column header (optional, you can leave this line out) |Sixth column header (optional, you can leave this line out) }} {{table row|Row 1 Cell 1|Row 1 Cell 2|Row 1 Cell 3|Row 1 Cell 4|Row 1 Cell 5|Row 1 Cell 6}} {{table row|Row 2 Cell 1|Row 2 Cell 2|Row 2 Cell 3|Row 2 Cell 4|Row 2 Cell 5|Row 2 Cell 6}} ... {{table footer}} First header and first cell are required, 2-6 are optional and are left out if omitted. If you aren't familiar with template syntax, there are a lot of tricks being used here. The #if parser function tests if a value is blank or not. If not blank, it outputs the text. Requires that Extension:ParserFunctions is installed (it is bundled with every mediawiki download) Numbered parameters don't require you to specify the name of them when calling the template; they're taken as positional unnamed parameters. You can still explicitly specify the name though (as 1=Value or 2=Value) -- which is required if the Value contains an = sign. The syntax {{{1|}}} means "If the parameter 1 was passed in, use the value for that. Otherwise use the value after the pipe, which in this case is blank/empty. This plays nicely into trick #1 above. The {{!}} built-in template expands to the pipe character |. Since | has a special meaning inside of templates, {{!}} is used to "escape" the pipe so it doesn't get looked at as part of the template, but rather as part of the resulting table markup. Overall though, this is probably more complicated than just encoding the table markup directly on the pages where you care about it...
  24. Skizzerz


    Version 1.0.0


    This extension automatically adds categories to new file uploads based on keyword metadata found in the file. The following metadata types are supported: XMP (many file types, including JPG, PNG, PDF, etc.) ITCP (JPG) ID3 (MP3) Categories are added to new uploads only (that is, uploads where a file description page does not already exist). This lets editors modify the categories without needing to worry about new versions of the file overwriting their changes. Any form of uploading is supported, whether that is via Special:Upload, the UploadWizard extension, uploading files via the API, or maintenance scripts to bulk-upload files. For installation instructions, please see the documentation page on MediaWiki.org. It is recommended that you "Follow" this download so that you can be notified automatically whenever there are updates. For support, please post a new topic on the forums. Free support is provided on a best-effort basis. Commercial support for this extension is available by purchasing a MediaWiki Support Subscription.


  25. Skizzerz

    Cannot find MediaWiki 1.3.0 RPM

    MediaWiki is not officially distributed via RPM. A number of RPMs have been created as unofficial community efforts, but due to the nature of this they often lag behind official releases. It is not recommended that you install MediaWiki via RPM, and instead download the tarball from the MediaWiki website and install it that way. If you want to create your own RPM, you'll need a fair bit of knowledge both in how RPMs are packaged as well as knowledge of how to install MediaWiki from the command line (CLI) by using the install.php maintenance script. I cannot provide much in the way of guidance in this matter as I don't have any experience in packaging RPMs. A second side-note regarding version numbering: don't treat the dot as a decimal point, but rather as a separator. MediaWiki versioning follows the standard of major.minor.patch. The version 1.3.0 is therefore major version 1, minor version 3, and patch version 0. 1.3.0 is ancient and no longer developed (and would be difficult to obtain). The most recent stable version of MediaWiki is 1.30.0, or major version 1, minor version 30, and patch version 0. 1.30.0 is 27 versions newer than 1.3.0.

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.