Skizzerz

You need to change the user rights assignment for the translate right. At the moment, it seems that either '*' or 'user' (all users or logged in users) are given the translate right, and you should change that to a specific user group, such as making a new Translators group. See here for a sample configuration which adds a new translate group (which you can then assign to users you want to be able to translate via Special:UserRights)

A broken layout like that is usually caused by you either having extra open tags or extra closed tag (like you have a <div> but no corresponding </div>, or you have an extra </div> without the associated <div> earlier on). Doesn't have to be div, could be any block-level tag such as <table> too. If you're copying templates from Wikipedia, you're going to need a handful of settings and extensions installed in order to make them work correctly. Click the links in each point for more info. Ensure that Tidy is enabled: $wgTidyConfig. My recommendation is to use the first example on that page under the Examples heading; it will require that the tidy PHP extension (not MediaWiki extension) is installed on your server. If Tidy is not enabled, broken layouts like the above can happen due to how the wikitext parser operates differently when not using Tidy, even if there is no actual issue with your wikitext. Ensure that you have installed the following MediaWiki extensions: ParserFunctions and Scribunto

You can disable the parser cache sitewide with the following in your LocalSettings.php. I do not recommend this except on small wikis: $wgParserCacheType = CACHE_NONE; There is an extension which supposedly let you disable the cache on a per-page basis. I have not used or tested it, and make no guarantees that they are compatible with modern versions of mediawiki: https://www.mediawiki.org/wiki/Extension:MagicNoCache In addition, other extensions may disable the cache on pages they are used, such as DynamicPageList.

Pages in MediaWiki are cached, meaning that the page is not processed on each page view, but rather only once and then the process page served to users. If you want a truly dynamic page, you can install an extension that disables the parser cache (preferably on a per-page basis), but keep in mind that doing so will slow down page views for such pages and increase server resources.

Once Parsoid is installed, edit /etc/mediawiki/parsoid/config.yaml and modify the uri string to point to your wiki's api.php endpoint. For example, https://example.com/w/api.php Then, install and configure VisualEditor as a mediawiki extension by following the 2nd link in my above post.

Installing Visual Editor is a two part process: Installing Parsoid service Installing Visual Editor For some linux distributions, Parsoid is present in package repositories and can be installed from them. See here for details on installing and configuring Parsoid. Once Parsoid is installed, follow the Visual Editor setup instructions for info on how to configure VE to work with Parsoid.

1.16 is ancient. You'll probably want to restore it to a suitably ancient version of Ubuntu as well. My first guess is that the PHP version you have installed is too new; you'll probably want PHP 5.2, as I believe 5.3+ broke compatibility with super old versions of mediawiki. You will be able to verify this for sure by checking your server error logs. A 500 error should hopefully be logged somewhere in /var/log. Perhaps syslog, perhaps an apache error log.

This does not seem to be possible using only Special:PrefixIndex, so some other extension will be needed to generate this list. DynamicPageList can probably do it, but is likely overblown for your use case. It is possible to do this with a Scribunto module as well. I believe it should also be possible to omit the sub-pages from the PrefixIndex listing using a combination of ParserFunctions and StringFunctions (StringFunctions are included in the ParserFunctions extension, but are disabled by default), but it will be more limited in terms of functionality (can only support up to a hardcoded number of pages).

I edited your template code above -- you had line breaks in-between the if statements which were being rendered. I commented them out with <!-- --> so that you retain the visual spacing (for readability when editing) but the line breaks themselves do not appear when the template is used. I also put the header on a line by itself, as otherwise it could cause issues in some template invocations.

Yep. Replace that entire existing line with what I just said. No sub-template or blank.

Replace 1 with the name of the parameter, in your case Contact_Name. Do not use a sub-template, you don't need it for something this simple. {{#if: {{{Contact_Name|}}} | : {{{Contact_Name}}} }} The pipe at the end in the first parameter of #if is very important. If you do not have the pipe at the end, it will not default to blank, and therefore it will always try to execute the "then" clause of the if. You do not need an "else" clause with {{blank}} unless Template:Blank actually has contents (and isn't just empty). Omitting the "else" clause will automatically make it blank.

If you want to indent if there is something, and omit the line entirely if not, you will need to use ParserFunctions: {{#if: {{{1|}}} | : {{{1}}} }} Note that the colon must start its own line.

Add a pipe at the end of the parameter name: {{{1|default value if this parameter isn't specified}}} {{{1|}}} (blank default value) Will output the value of {{{1}}} if specified, and whatever is after the pipe (nothing in the case you want, so that second line above). (Side note: if you sign up for an account, you can post without needing mod approval, and you can do things like upvote and mark things as best answers)

I see the issue with the MSIE on Windows thing -- the email service I use scans all emails (inbound and outbound) for issues like viruses, phishing, etc. It follows the links in the email and apparently is written in .NET Framework so the User-Agent shows as IE. This is likely also why it is showing your email as already validated. Since all outbound emails from this domain are automatically generated, I don't see the need of scanning them, so I'll be disabling that.

You can set the following in your LocalSettings.php in order to make it appear on existing pages as well: $wgMultiBoilerplateOverwrite = true; It is not possible to merge it in instead of overwriting all existing content as of this time. You can create a feature request to alert the authors this is something you'd like to see (type/select MediaWiki-extensions-MultiBoilerplate into the "Tags" field. Leave "Assigned to" and "Subscribers" blank).

It looks like you have an outdated version of GoogleLogin, please download an updated version (the most recent one). There are no changes between 1.27 and recent mediawikis which should make it incompatible, and it appears there have been numerous bugfixes made since the version you have. The lack of special page showing up may be one of them. Go through the normal install instructions to update (including running `composer update --no-dev` and the update.php maintenance script). For question 2, as I said before, I seriously doubt it requires a Google+ id. What you can do is test with your own account, a dummy/test account, a co-worker, or your supervisor to see if they can log in without having a Google+ profile. For question 3, the user should click "Log in with Google" without filling in any of the other fields (username/password). If you still get this message even after doing that, and have updated to the latest version (as mentioned in the first paragraph), then something is screwy either with your setup or with the extension.

1. Make sure that those settings are underneath the require_once line for the extension. If you did that, re-run update.php just to be sure. After doing that, see if you can see "Administrate allowed domains for GoogleLogin" in your Special pages list (Special:SpecialPages). If not, we'll need to do some more investigation. What version of MediaWiki and what version of GoogleLogin did you install? 2. I would sincerely doubt that a Google+ profile is required for this extension to work, but I don't know for sure. The Google+ API mentioned in the documentation is how you set up the authentication against Google's servers, not a requirement that each of your users has to go through. 3. An account will be automatically created for them on-wiki the first time they log in using Google, there is no need to import users in bulk. By the way, it wasn't asked but you can disable normal login (and therefore force Google login) with the following settings at the end of your LocalSettings.php: $wgAuthManagerConfig = $wgAuthManagerAutoConfig; // disable local password authentication unset($wgAuthManagerConfig['MediaWiki\Auth\LocalPasswordPrimaryAuthenticationProvider']); // disable sign-ups on wiki $wgGroupPermissions['*']['createaccount'] = false; // but allow the auto-creation of accounts via GoogleLogin $wgGroupPermissions['*']['autocreateaccount'] = true;

As I'm working on rolling out new content and features for the site, I wanted to poll all of you for what you think would be great to see here. Please let me know in the poll as well as by posting your opinions To explain the options a bit more: Guides and manuals: This would be curated content created by myself and others who wish to submit content. It will aim to achieve a high level of quality and readability. Topics would largely cover places where the documentation on mediawiki.org is unclear, missing, bad, or out of scope. For example, I am working on a comprehensive installation guide which should be published to the public in the coming weeks. Helper applications: This would be things like the Pretty URL Generator -- little tools to make your life easier as a system administrator or wiki editor. Template, Module, and Gadget repository: This is where you (the community) can help chip in. I'd open up uploading of templates, modules, and gadgets that you feel are generally useful. You can publish them for others to use on their own sites. Other: Anything else. Let me know what in a reply!

You're missing the ParserFunctions extension. Go install it (it is likely already downloaded, as the extension ships with the tarball).

From Sam Reed on MediaWiki-announce. This is a security release. It is recommended you take action immediately in order to patch your MediaWiki installations. This security release includes a fix for a Remote Code Execution (RCE) vulnerability present in some configurations of MediaWiki. Not everyone is impacted. To test if you are impacted by this vulnerability, after following all patch instructions in the email (including running the "composer update --no-dev" command if you are installing MediaWiki from git instead of tarball), look through your server access logs for hits to a file named "eval-stdin.php". If you see this entry in your access logs, your server may have been compromised, take additional steps to investigate and secure the server. If you need assistance in how to proceed with this, or have any difficulty checking or validating if you were impacted, post in our support forum.

I'm looking for a volunteer moderator or two in order to assist with managing the site. I'm looking to have someone for the times I'm not available (due to sleeping and whatnot), so applicants outside of the Western US are preferred. Your duties include: Flagging/banning any spammers that slip through the spam filters. Approving content held for moderation (posts by guest/logged-out users require moderator approval before being shown). Helping out with other site duties, at your discretion and leisure. For example, updating the Announcements blog or adding new guides to the Manuals section. In return, you get a swanky blue title underneath your avatar and my eternal gratitude Apply at https://mwusers.org/modapps/1117. Applications close on November 30.

If you enable uploads and upload the article locally (via [[Special:Upload]]), you can view the contents of the article if it is a DjVu, PDF, or TIFF file by following the linked instructions above. Otherwise, no, this is not possible with MediaWiki. If you absolutely need that feature, and there are other wikis which do it for you, I recommend using one of those other wikis instead.

Assuming you're asking for a space to have a private article "draft" on-wiki, there is nothing like this out-of-the-box, and the only extension I see is unmaintained. You can copy/paste the wikitext into a local file while you're still working on it, using Show Preview on the wiki to see what it looks like but never actually saving the page until it's ready to go. If you don't care about the draft being public while it's a work in progress, you can also insert a work-in-progress notification on the top of the page while you're working on it. As for uploading data via [[Special:Upload]] and having the data displayed on-wiki, there are a couple file extensions that let you do that (some requiring MediaWiki extensions as well): DjVu PDF TIFF

There are a few ways to go about this; the way I would personally recommend is as follows: Ring 1 is your internal (not public-facing) wikis. Staff wiki, staging wikis, etc. Ring 2 are your public-facing wikis (main wiki, any other wikis run by the farm as opposed to users). Ring 3 are a select few user wikis, ideally active ones where the users/admins are good about reporting issues. Ring 4 is everything else. You would therefore have a directory structure as follows (assuming /var/www is your webroot): /var/www/ring1/w contains the wiki files for Ring 1 wikis /var/www/ring2/w contains the wiki files for Ring 2 wikis /var/www/ring3/w contains the wiki files for Ring 3 wikis /var/www/ring4/w contains the wiki files for Ring 4 wikis Configure each wiki to have the appropriate DocumentRoot depending on what tier it is in your webserver config. You can move wikis between the rings by changing the DocumentRoot for their VirtualHost. When it comes time to update, update Ring 1 first. This should be your dogfooding ring, so consider nightly (or more frequent than nightly) deployments. Train your staff to be diligent about reporting issues, or look into getting an actual QA department if you're big enough / have the funds. If there aren't any blocking issues in Ring 1, promote it to Ring 2 on a rapid but less frequent basis. Once every week or so. This gets you wider testing as the general public is now looking at stuff, but keep in mind that issues they find may go unreported. Having robust logging and notifications in place for server errors is therefore highly recommended. Once Ring 2 looks good, promote that to Ring 3. This means that Ring 3 is 2 weeks behind Ring 1 (Ring 1 -> Ring 2 every week/every other week, and once Ring 2 is good for a week then that old build is deployed to Ring 3 before 2 is refreshed from 1). Finally if Ring 3 is good for a couple of weeks, deploy it to Ring 4 (so, once a month). Note that the above strategy requires scheduled maintenance as you need to update every wiki in the ring at once since you're replacing the old files. You can work around that by staggering deployments within a ring as well, however you'll need deployment scripts to mess around with temporary RewriteRules so that upgraded wikis are redirected to new files while wikis awaiting updates stay on the old ones. You can use RewriteConds on %{HTTP_HOST} to only trigger the rules for certain domains/subdomains.