Skizzerz

MediaWiki 1.32 has been officially released. Below is a highlight of some of the release notes; you can view the full list here. Changes A new "Interface administrators" group was added, which has the ability to edit sitewide CSS/JS and the CSS/JS of other users. By default, no other group (not even "Administrators") has this capability anymore. We recommend that you do not grant this group to all of your existing administrators, instead only granting it to those who will be responsible for maintaining CSS/JS pages on the wiki. This increases your site's security in the event that an administrator account is compromised. The old editing toolbar has been removed (see image below if you aren't sure what toolbar this is). Use an extension such as WikiEditor, which is bundled with the tarball release, instead to provide an editing toolbar. If your wiki has customizations to add additional buttons to this toolbar, work on a migration plan to add them to the WikiEditor toolbar instead. (Image from Wikimedia Commons) The MediaWiki API (api.php) is now unconditionally enabled and can no longer be disabled. A cookie can now be set when an IP user is blocked to track that user if they move to a new IP address. This feature is disabled by default but can be enabled by setting $wgCookieSetOnIpBlock = true; in your LocalSettings.php. The on-wiki external image whitelist (MediaWiki:External image whitelist) is now disabled by default. If you were making use of this feature, set $wgEnableImageWhitelist = true; in your LocalSettings.php. This feature allowed for allowing embedding of external images ("hotlinking") from domains that wiki administrators specifically allow. Hotlinked images do not feature any controls such as resizing or adding captions, and leak your visitor's IP addresses to the external source. Furthermore, there is no guarantee that the image will remain available in the future, or that it will not be changed to something else. As such, we recommend that you always upload images locally if possible and do not use this feature. The Watchlist will now show 7 days of changes by default, up from 3. 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.32 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.

Unfortunately, what you seek is likely not possible by using [[Image:]] tags to embed images in pages. If you don't specify a width in the tag itself, MediaWiki defaults to 300px. You can change this default, but it will always be in px instead of percentages. An extension would be needed to change this for [[Image:]] tags, or you could directly embed the images by putting the full url of the image bare into the page (no link syntax around it) ($wgAllowExternalImages, $wgAllowExternalImagesFrom, or $wgEnableImageWhitelist) and then wrap that in a span/div which sets the width.

Use the built-in watchlist feature that @HSRobinson linked above to have your owners notified on pages that they are responsible for. For moderation of changes before they go "live" to the majority of users, the FlaggedRevs extension lets edits still be made but marked by default as "unchecked" -- a reviewer would then need to look over the edit and mark it as good before the revision is fully accepted as default. There is no feature in the extension to restrict that ability to certain people on a per-page basis (although that would be easily achievable via a custom extension that hooks into FlaggedRevs), either someone can review every page or they can't, but you can enforce with internal policies that owners should review only their own pages. Alternatively, you can make use of the discussion pages. Have non-owners suggest edits on the discussion page instead of making them directly, and then the suggested contents can be discussed with the owner until they approve the changes and edit the article itself to incorporate them.

Can you try upgrading your version of Translate? The latest version of the language bundle (2018.10) is compatible with MediaWiki 1.31 and I see that there were a few bug fixes for the Translate extension; it is possible that your issue was already fixed. The best way to update the extensions is as follows: Download the latest bundle. Archive the existing versions you have of those extensions in your extensions folder. A decent way to do this on a temporary basis is to rename the directories. For example, rename the "Translate" directory in your extensions directory to "Translate-old". Upload the bundle to your server and extract it into the extensions directory. This will create a brand-new "Translate" directory, among others. The reason why you should rename or delete the old version first is because there are sometimes issues with extracting the new version on top of the old version -- if a file was deleted between the old and new version, the old file will remain in-place and could cause issues with functionality or expose security risks. By renaming or deleting the old version first, you avoid these issues. Run the update.php maintenance script to perform any relevant database updates, or use the web installer to update if you don't have SSH access. You should always run the updater after updating MediaWiki or any extensions. After doing that, try it again. If it still doesn't work, check your error logs to see if anything is showing up there (and configure PHP to log errors if it isn't currently doing that).

That's very odd. Can you provide some additional information about your wiki? You can find all of this information on the Special:Version page on your wiki. MediaWiki version Translate version PHP version

You need to mark the page for translation before you can translate it. Are you saying that you've clicked "Mark this page for translation" but it did nothing? What happens when you click that link, any error messages or other indication of things happening?

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.

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.

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.

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.

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.

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.

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

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.

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.