Recently I upgraded the MediaWiki software for the Flashlight Wiki I made in 2010. I had a list of customizations I made for version 1.16.0, but the upgrade is version 1.18.0. So based on the old customizations, here are the slightly different ones I needed for 1.18.0 and its new skin, Vector (old skin was Monobook). Rather than make a new list every time I upgrade the software, I am just updating this post, so really these customizations are for the current version which is v1.20.4.
Things done in LocalSettings.php file:
Change path to new 135×135 logo that I made (from FAQ). I had this on igirder.com, but moved it to the images folder since the images have to go with any reinstallation:
$wgLogo = "http://flashlightwiki.com/images/led.png";
I wound up putting in some pretty good security to keep spammers at bay (ASIRRA, below), so I didn’t want to add the bother of making users register an email address and then confirm it. However I realized that if I didn’t get their email address, they would have no way of recovering a forgotten password. Given that most users don’t edit that often, it seemed likely they could forget their password, so I enabled this again:
$wgEnableEmail = true;
$wgEnableUserEmail = true; # UPO
Put in new line for favicon path (from FAQ):
$wgFavicon = "http://flashlightwiki.com/images/favicon.ico";
Restrict edits to registered users who have been confirmed by the admin (from FAQ). During installation I had to choose whether new users could register (yes) and whether to allow user edits (yes), so I had to comment out the line that was generated allowing all users to edit. Then I added all of this:
// Prevent anonymous users from editing
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['createpage'] = false;
$wgGroupPermissions['*']['createtalk'] = false;
// Prevent registered, non-confirmed users from editing (from FAQ):
$wgGroupPermissions['user' ]['move'] = false;
$wgGroupPermissions['user' ]['edit'] = false;
$wgGroupPermissions['user' ]['createpage'] = false;
$wgGroupPermissions['user' ]['createtalk'] = false;
$wgGroupPermissions['user' ]['upload'] = false;
$wgGroupPermissions['user' ]['reupload'] = false;
$wgGroupPermissions['user' ]['reupload-shared'] = false;
$wgGroupPermissions['user' ]['minoredit'] = false;
$wgGroupPermissions['user' ]['delete'] = false;
// Allow confirmed users to edit
$wgGroupPermissions['confirmed' ]['move'] = true; // Only add this line if you want all users to be able to move
$wgGroupPermissions['confirmed' ]['edit'] = true;
$wgGroupPermissions['confirmed' ]['createpage'] = true;
$wgGroupPermissions['confirmed' ]['createtalk'] = true;
$wgGroupPermissions['confirmed' ]['upload'] = true;
$wgGroupPermissions['confirmed' ]['reupload'] = true;
$wgGroupPermissions['confirmed' ]['reupload-shared'] = true;
$wgGroupPermissions['confirmed' ]['minoredit'] = true;
$wgGroupPermissions['confirmed' ]['delete'] = true;
Enabled image uploads by making this statement true:
$wgEnableUploads = true;
Added a line to allow the wiki to generate thumbnails.
$wgMaxShellMemory = 524288;
In the previous installation I had a meta tag extension that let me include a meta tag for the main page description, but it gave an error with the new installation. Then I found an extension called MetaDescriptionTag that had been updated unofficially for 1.18.0. It works by inserting <metadesc>Description</metadesc> into the wiki page source. Using the unofficial version of MetaDescriptionTag, I recreated an extension called MetaKeywordsTag to do meta keywords. The source for MetaKeywordsTag is here.
require_once('extensions/MetaDescriptionTag.php');
require_once('extensions/MetaKeywordsTag.php');
MediaWiki can Cache pages for quicker rendering (only does this for unregistered visitors, but I guess that would be most of the traffic). I had this set to true at first, but I wound up turning this off after installing the WPtouch skin for mobile users because the cache doesn’t work right with two different skins.
$wgUseFileCache = false; /* default: false */
$wgFileCacheDirectory = "$IP/cache";
$wgShowIPinHeader = false;
I commented out the line setting the default skin as Vector and put this line in to use Vector for people visiting by computer and WPtouch for mobile users:
if (preg_match("/(mobile|webos|opera mini)/i", $_SERVER['HTTP_USER_AGENT'])) {
$wgDefaultSkin = 'wptouch';
}
else {
$wgDefaultSkin = 'vector';
}
When setting up the Wiki originally, I could pick a type of license, but picked none. Then I had to add some code to set that back up again. But when I was installing the upgrade, I picked Creative Commons Attribution NonCommercial ShareAlike and got all the code I wanted.
I wanted to be able to do footnotes like they do in Wikipedia, so I had to add the Cite extension by downloading a compressed file, putting it in my extensions folder, and extracting it. Then I had to add this line to the end of localsettings:
require_once("$IP/extensions/Cite/Cite.php");
Later I found out that to implement footnotes the same way Wikipedia does, you also need to enable the ParserFunctions extension, and should probably enable string functions, so I also added these two lines. There was still a template that had to be added to the wiki itself for the references to do right.
require_once( "$IP/extensions/ParserFunctions/ParserFunctions.php" );
$wgPFEnableStringFunctions = true;
People all over the world use the wiki, so I wanted to add the ability to translate a page. I used the Google Translator extension which adds a toolbox to the sidebar. To make all languages available, I left the list of languages blank in the 4th line below. However, this causes the toolbar to be a little too wide because two of the selections, Chinese (traditional) and Chinese (simplified), are so wide. So I went to Google’s toolbar customizer and selected all languages and then got rid of those two, plus a few others I felt were unnecessary, and added the resulting long list of two letter country codes (not shown below). To make the branding below the tool bar fit, I also needed to modify Common.css (see later):
require_once( "$IP/extensions/GoogleTranslator/GoogleTranslator.php" );
$wgGoogleTranslatorOriginal = 'en';
$wgGoogleTranslatorLanguages = '';
I decided to add some AdSense ads to the page just to see if I get any revenue. There is a MediaWiki extension set up for it, so I unzipped that in the Extensions folder. I also needed to set up a new ad in AdSense that was 120×240. This generated some code for the ad, but I only needed a few key parts of the code, adding the following to localsettings.php. The last line is an option that hides ads from registered users, but I’d like to see what ads are showing up, so it is commented out. The instructions said to make a change to main.css, but I didn’t do that (couldn’t find main.css at first, but it is in skins/monobook) and it seems to work fine:
require_once( "$IP/extensions/GoogleAdSense/GoogleAdSense.php" );
$wgGoogleAdSenseClient = 'ca-pub-8914738878891900';
$wgGoogleAdSenseSlot = '2337837216';
$wgGoogleAdSenseID = 'flashlight';
// Show the AdSense box only for anonymous users
#$wgGoogleAdSenseAnonOnly = true;
I wanted to have some kind of filter to keep bots from registering, so I installed the extensions ConfirmEdit and ASIRRA, adding the following lines to the end of the file. Also set the triggers for only when a new account is created or a person logged in incorrectly last time (like if someone was trying to hack an account password):
require_once( "$IP/extensions/ConfirmEdit/ConfirmEdit.php" );
require_once( "$IP/extensions/ConfirmEdit/Asirra.php");
$wgCaptchaClass = 'Asirra';
$wgCaptchaTriggers['edit'] = false;
$wgCaptchaTriggers['create'] = false;
$wgCaptchaTriggers['addurl'] = false;
$wgCaptchaTriggers['createaccount'] = true;
$wgCaptchaTriggers['badlogin'] = true;
Once I prevented bots from registering, I wanted to delete the bots that had signed up already, but you aren’t supposed to just delete users, so instead you can merge the users and then delete them (this probably matters more if users had made any edits, but the bots were never confirmed, still better safe than sorry). So I downloaded and installed the User Merge and Delete Extension, adding the following lines to localsettings, and then commenting them out once I had merged everyone.
# require_once( "$IP/extensions/UserMerge/UserMerge.php" );
# $wgGroupPermissions['bureaucrat']['usermerge'] = true;
In doing weekly backups, I noticed the database was getting really big. This turned out to be the objectcache getting out of hand. I added the PurgeCache extension and enabled a special page to purge the cache (had to give the admin developer privileges):
require_once( "$IP/extensions/PurgeCache/PurgeCache.php" );
I wanted to get a reminder if I was leaving a page that I was editing without saving changes. This works using the Vector extension, but it must be enabled first. Then you can make this feature available as a user preference. Vector introduced collapsible left menus which by default collapsed the Google Ads. I couldn’t figure out how to make the default be expanding the ad, so I disabled the feature in the last line.
require_once("$IP/extensions/Vector/Vector.php");
$wgDefaultUserOptions['useeditwarning'] = 1;
//Disable warning globally
//$wgVectorFeatures['editwarning']['global'] = false;
//Make warning a user preference
$wgVectorFeatures['editwarning']['user'] = true;
//Vector extension adds collapsible menus, but I don't want them
$wgVectorFeatures['collapsiblenav']['global'] = false;
Lastly, I had to add these two lines to allow short URL’s (using unrecommended method (also had to modify .htaccess to make this work, see next section):
$wgArticlePath = "/$1";
$wgUsePathInfo = false;
Modifications to .htaccess file
First, when using an add-on domain like this, there are a lot of ways to see the web pages, and I only want people to be able to see them as http://flashlightwiki.com/stuff
But since it is a subdomain *and* and add-on domain, people could get to by seeing the subfolder on igirder http://igirder.com/flashlightwiki/stuff as well as http://flashlightwiki.igirder.com/stuff, so these lines in my .htaccess file redirect both of those (code from here, but I adapted it to get rid of the www. prefix on the destination):
RewriteEngine on
RewriteCond %{HTTP_HOST} ^(www\.)?flashlightwiki\.igirder\.com [NC,OR]
RewriteCond %{HTTP_HOST} ^!www\.flashlightwiki\.com [NC]
RewriteRule ^(.*)$ http://flashlightwiki.com/$1 [R=301,L]
After that add these lines to redirect www.flashlightwiki.com to flashlightwiki.com (not sure what the second two lines do):
RewriteCond %{HTTP_HOST} ^www.flashlightwiki.com [NC]
RewriteRule ^(.*)$ http://flashlightwiki.com/$1 [R=301,L]
RewriteCond %{REQUEST_URI} ^/flashlightwiki($|/.*$)
RewriteRule ^.* http://flashlightwiki.com%1 [R=301,L]
To get short URL’s to work, I had to make the changes shown just above to localsettings, but I also had to add this to the .htaccess file (for Wiki’s installed to root directory, which is what I did originally, not knowing any better). I did this after the stuff above so as to at least hopefully get people in close to the right format of URL before attempting any of this:
RewriteRule ^[^:]*\. - [L]
RewriteRule ^[^:]*\/ - [L]
RewriteRule ^/*$ /index.php?title=Main_Page [L,QSA]
RewriteRule ^(.+)$ /index.php?title=$1 [L,QSA]
I was having problems with people hotlinking to images on the wiki, so I added this not to the main htaccess file, but the one in the images folder, this allows images without a referrer or referred from the wiki itself or fiveforks.com; all others will see an image that says Flashlight Wiki:
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?flashlightwiki.com [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?fiveforks.com [NC]
RewriteRule .*\.(jpe?g|gif|bmp|png)$ http://igirder.com/hotlink.png [L]
Changes to MediaWiki:Common.css
All of the following changes are done within the Wiki itself by modifying special pages as an administrator. This is good because the changes are saved in the database and are not overwritten when installing a software upgrade. I made the background color of the pages a light yellow. I thought it would be good to have internal links one color and external links the traditional blue (purple if a link has been visited before). Wiki also has red links for links to pages that don’t exist yet (dark red if you’ve tried to visit the page before). So I thought green would be good, but it was kind of hard to do light green and dark green, so I did dark green for unvisited internal links and brown for visited links. There doesn’t seem to be a special class for internal links, so instead I set the general links to green and brown and then set external links to blue and purple. The general a:link overrode the Mediawiki default for red links to articles that don’t exist so I had to reinstate that (also adding light red if you’ve visited the link before, which was too close to brown that I was using for visited internal links, so I changed it from a55858 to cc6666). Here’s the code:
div#content {
background-color: #ffffdd;} /* light yellow */
a:link {color: #006600;} /* dark green */
a:visited {color: #996633;} /* brown */
a.new {color: #cc2200;} /* red */
a.new:visited {color: #cc6666;} /* light red */
a.external {color: #0000ff;} /* blue */
a.external:visited {color: #800080;} /* purple */
By default, the main page says Main Page at the top, but that seems kind of pointless, so you can use this to get rid of it:
.page-Main_Page h1.firstHeading { display: none; }
Also on the main page, I have two columns set up with lists of topics under sub-headings. But the [edit] link for the subheadings on the left showed up right next to the list on the right. On the main page I had put a divider between the left and right, but in Internet Explorer, the divider wasn’t working. I got rid of the line under each heading by using === headings instead of the more major == headings in the wiki markup, which I think is a little cleaner anyway. But to get rid of the [edit] link I had to use the following CSS:
/* Hide subsection edit tags on Main Page */
.page-Main_Page span.editsection {display: none;}
The Google Translator tool says “Powered by Google Translate” and this was spilling into the page. I added this line to force the text to wrap above and below the Google image:
a.goog-logo-link img {display: block}
Changes to MediaWiki:Vector.css
The link color changes above somehow do not affect the links in the left sidebar Navigation and Toolbox boxes. Since those are all internal links and should be green, I put this code in the MediaWiki:Vector.css page:
div#mw-panel div.portal div.body ul li a:link {
color: #006600; /* dark green */
}
div#mw-panel div.portal div.body ul li a:visited {
color: #996633; /* brown */
}
Now all the internal links were green or brown except the tabs at the top of the main part of the page. Based on how I had to format the left side menu, this seems to work:
/* Also need to pick up the Read/Edit/View history tabs */
div.vectorTabs li a:link {color: #006600; /* dark green */
}
div.vectorTabs li a:visited {color: #996633; /* brown */
}
div.vectorTabs li.new a:link {color: #cc2200; /* red */
}
div.vectorTabs li.new a:visited {color: #a55858; /* light red */
}
That code didn’t work consistently until li was added, I guess because those links are list items (li). I still don’t understand CSS, but the # seems to be for id tags which identify a unique part of the page. The period represents a class and for some reason “new” is a class of li instead of the link, a. I had to add in the red and light red links because otherwise the first two lines made the discussion tab green even if there was no discussion (in which case it should be red). However then I noticed that Vector defaults to light red which should only be if you’ve tried to visit a page that doesn’t exist. Don’t know if that is a flaw or a feature. Maybe the red was too jarring? So I set it up with red and light red.
Changes to MediaWiki:Sidebar
This controls what links appear in the sidebar. I replaced some of the things in Navigation with links to the Terminology and Flashlight Manufacturers pages. I also rearranged the order to push the Toolbox to the bottom and get the Translate and AdSense boxes up higher. This is formatted as a Wiki list (*) with sub-entries (**):
* navigation
** mainpage|mainpage-description
** Terminology|Terminology
** Flashlight Manufacturers|Manufacturers
** recentchanges-url|recentchanges
** randompage-url|randompage
** helppage|help
* SEARCH
* googletranslator
* googleadsense
* TOOLBOX
* LANGUAGES
Changes to MediaWiki:Prefs-help-realname
Changed this system message to warn people registering that their accounts will not be activated until they send me an e-mail or PM at CPF or BLF.
Changes to MediaWiki:Welcomecreation
Added a reminder to this system message to people who have successfully created an account with a mailto link to confirm their account. Since you only see this when you register, I don’t think it will be a problem having my e-mail address exposed.
Things I still want to do:
A guy from a Spanish language flashlight site said he would do some translating if I could enable other languages like Wikipedia does. The only way to get true multi-language support is to install a wiki for each language and have a “family” of wikis. So for now the Translate toolbar will have to do.
The title of the main page of the wiki is no longer “Main Page – Flashlight Wiki” but just “Flashlight Wiki” In the past version I couldn’t figure out how to get rid of Main Page, and now it is just gone.
I’d like to set up support for equations, but my first try to do that wasn’t successful (see comment of Jan. 2, 2011).
File size uploads are restricted to 2MB by default, but I’d like to change that to 500kb or smaller so people don’t upload giant images. This might require tweaking server settings that I don’t have access to though.