Skizzerz

If you're using the wikipedia dumps, the "all pages" dump will include templates.

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.

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 article names matching file or directory names will become impossible to create on your wiki.

The first one will cause issues so I wouldn't recommend it. For options 2 or 3:
Make a very heading, such that it wraps around multiple lines on a desktop browser. See which of the options looks better there. Try it on tablet and mobile devices (or use browser dev tools to emulate those device sizes if you don't have any actual devices available), focusing mostly on normal-sized headings. These headings will probably not wrap on tablet, but may wrap on mobile. See which of the options looks better there. As for where to put it: depends. Common.css affects every skin, Vector.css affects only the vector skin. Given that skins can put edit links pretty much wherever they want, there's no guarantee that your change for vector will work properly on other skins.

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.

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)

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; }  

This is unfortunately not possible with just the Inputbox extension. You may be able to make use of the Page Forms extension for this purpose (it's part of Semantic MediaWiki but can be installed standalone if you don't want all of SMW installed). However, I've never actually tried it out myself so I cannot say for certain whether or not it will work. You can grab the extension at https://www.mediawiki.org/wiki/Extension:Page_Forms

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

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.

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.

By default, nobody has permissions to do anything when Extension:OAuth is installed. You can adjust this by setting $wgGroupPermissions at the bottom of your LocalSettings.php. Here is a sample configuration:
$wgGroupPermissions['user']['mwoauthmanagemygrants'] = true; // All logged-in users can manage what access consumers tied to their accounts have. Do NOT change this line to a different group. $wgGroupPermissions['user']['mwoauthproposeconsumer'] = true; // All logged-in users can propose new consumers $wgGroupPermissions['user']['mwoauthupdateownconsumer'] = true; // All logged-in users can update details of their own consumers. $wgGroupPermissions['sysop']['mwoauthmanageconsumer'] = true; // Administrators can manage consumers (approve requests, deactivate consumers, etc.) // Optional permissions. Uncomment (remove the leading #) to enable. #$wgGroupPermissions['sysop']['mwoauthsuppress'] = true; // Administrators can hide details about a consumer #$wgGroupPermissions['sysop']['mwoauthviewsuppressed'] = true; // Administrators can view details about a consumer that were hidden #$wgGroupPermissions['sysop']['mwoauthviewprivate'] = true; // Administrators can view private details about a consumer, such as the Secret Token. It is recommended that you do NOT enable this. // If your wiki is not using SSL (HTTPS), do not include this line. If your wiki is using SSL (HTTPS), ensure this line is present. $wgMWOAuthSecureTokenTransfer = true;  

Extension:OAuth sets up the OAuth server. In other words, it lets other applications connect to you. Depending on what you want for your OAuth deployment, you'll want one of two things:
If you want your wiki to be the canonical source of users, install Extension:OAuth. From there, you can register consumer applications on your wiki to obtain consumer keys and secret keys for use elsewhere to connect to your wiki. (More on this process further below) If you want your wiki to connect to some other wiki or OAuth source, install Extension:OAuthAuthentication. I'm not sure if this extension has been updated yet to work well with most recent versions of MediaWiki, so you may experience some issues when using it. Please note that the OAuthAuthentication extension is written to support logging in via other wikis running Extension:OAuth. I do not believe it supports being a generic OAuth client (for example, to auth against Google or GitHub), but I could be wrong as I've never personally tried it. To locate your consumer key and secret key, go to the wiki with Extension:OAuth installed (this will be your wiki in case 1, or the other wiki in case 2), and browse to the page [[Special:OAuthConsumerRegistration]]. It will be listed as "OAuth Consumer Registration" under the "Users and Rights" heading in the special pages list. From there, follow these steps:
Click "Request a token for a new consumer" Fill out the request form as per this image:
Click "Propose consumer." You will be given your Consumer Token and Secret Token. Write down your Secret Token now, you will not be able to view it after leaving this page.
Before the consumer can be used, it must be approved. If you are authenticating against a wiki you do not control, follow the approval process there. If you do control the wiki with Extension:OAuth installed, browse to [[Special:OAuthManageConsumers/proposed]]. If you get a permission denied error, ensure that you have given yourself the mwoauthmanageconsumer permission via $wgGroupPermissions in LocalSettings.php: $wgGroupPermissions['sysop']['mwoauthmanageconsumer'] = true;  
Once approved, you need to add some configuration in LocalSettings.php to the wiki with Extension:OAuthAuthentication installed:
 
$wgOAuthAuthenticationUrl = 'https://otherwiki.com/w/index.php?title=Special:OAuth'; // This assumes that otherwiki.com is where Extension:OAuth is installed. Change as necessary $wgOAuthAuthenticationConsumerKey = 'bf0252aa9e521f1463a0ba171ba20367'; // Consumer Token $wgOAuthAuthenticationConsumerSecret = '248f75d271d9fa34ea7d9da2264c0cb1400a54e5'; // Secret Token // Insert other configuration defined by Extension:OAuthAuthentication if needed. Check its extension page on mediawiki.org for more details.
 
If you are not using Extension:OAuthAuthentication (in other words, you're setting up an OAuth server so that non-MediaWiki clients can log in using wiki credentials), then you will need to configure those clients as step 5 instead of adding things to LocalSettings.php. The Callback URL in your registration in step 2 should also be modified to be appropriate for that external client.