PostgreSQL

First, get PostgreSQL portable here (topic on portable freeware).
Unzip it anywhere you want, then launch PostgreSqlPortable.exe. At first you’ll need to initialize the database: click on “Initialize PostgreSQL 8.3″, choose a user name (you can leave the default on, I chose “root”), a password and the port (leaving the default 5432 is good, it will let you configure phpPgAdmin faster). The database initialization will then take a few seconds (over 15 seconds on my very slow PC…). Then click on “Start PostgreSQL 8.3″. On a restricted computer, you may get an error message “Error starting PostgreSQL”. This seems to be an issue on the launcher: PostgreSQL is probably still running successfully (check in the task manager if you see a few running postgres.exe).

Now, all you need is to configure PHP to be PostgreSQL-enabled. In XAMPP’s folder, find php/php.ini and uncomment (or create) the line extension=php_pgsql.dll. Restart Apache and voilà, PostgreSQL is now usable from your XAMPP installation.

phpPgAdmin

phpPgAdmin is to PostgreSQL what phpMyAdmin is to MySQL: every newbie needs it, most power-users enjoy it. It can be downloaded from phppgadmin.sourceforge.net. Extract it in XAMPP’s htdocs folder (e.g. in htdocs/phppgadmin). Copy the default configuration file (conf/config.inc.php-dist) and rename it to conf/config.inc.php. Then in this file edit the following lines:

• $conf['servers'][0]['host'] = 'localhost';
• $conf['servers'][0]['defaultdb'] = 'postgres';: not sure if that’s really needed but I configured it this way…
• $conf['extra_login_security'] = false;: so you can log in as root on the database. Not needed if you chose a custom username as the admin username (during the database initialization process). But I chose root, so leaving it to true gave me the infamous “Login disallowed for security reasons.” error.

Finally, phpPgAdmin triggers a deprecation warning in PHP 5.3. And this deprecation warning is quite misplaced, as you can see from the error it generates:

Warning: session_start() [function.session-start]: Cannot send session cookie – headers already sent by (output started at xampplite\htdocs\phppgadmin\classes\Misc.php:344) in xampplite\htdocs\phppgadmin\libraries\lib.inc.php on line 56

To fix this, you can either:
- fix Misc.php: replace, on line 344, $data =& new $_type($_connection->conn); with unset($data);$data = new $_type($_connection->conn);
- or turn off deprecation notices (NB: not tested): in php.ini, replace error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED with error_reporting = E_ALL & ~E_NOTICE or even error_reporting = 0.

That’s it, you can now access phpPgAdmin at http://127.0.0.1/phppgadmin/ (that is, if you chose the same path as me).

Sources and versions

• Installing phpPgAdmin
• PHP documentation – Runtime configuration
• PHP.net – References Explained – comment by Anonymous on 01-Sep-2009 08:07 about fixing the “Assigning the return value of new by reference is deprecated” notice in PHP 5.3

For this short guide I used:

• PostgreSQL Portable v1.2.0 (contains PostgreSQL v8.3.7-1), 23 Aug 2009
• XAMPP Lite 1.7.3 with PHP patched to 5.3.2 (see upcoming tutorial about this)
• phpPgAdmin 4.2.3, 29 March 2010

• <meta name="robots" content="noarchive" /> seems to be the “standard” one, “officially supported by Google, Yahoo!, Bing and Ask” (source). This tag is enough, the other methods I’ll list are just here for informational purpose. On a side note, this noarchive option seems pretty old, I found a reference to it back in 2000.
• <meta name="googlebot" content="noarchive" /> is Google-specific, that’s if you want to disable caching just for Google.
• <meta name="robots" content="nocache " /> is Bing-specific. But since Bing supports noarchive too, there’s no reason to use it…

On a side note, it’s also possible to disable the page snippet/abstract, at least on Google, using the following: <meta name="googlebot" content="nosnippet" />. Note that this option will also disable the cache.

Sources:

• Disabling the Google Cache:New Meta Tag : NOARCHIVE
• 6 methods to control what and how your content appears in search engines
• Official Google Blog: The Robots Exclusion Protocol
• Special Google searches – Webmaster Tools Help
• Meta tags – Webmaster Tools Help

As promised at the beginning, the uninteresting complete history:
- someone sent me the following funky Google error message:

In class com.google.gaia.frontend.page.ServiceLogin: com.google.gaia.client.GaiaRemoteException: Backend not available (backend says: Cookie decode task expired while queued)

- I search for it, then for parts of it, and eventually ended up on Google Blogoscoped
- this site referred at some point to a Wikipedia page dedicated to criticism of Google, where I found out that caching can be disabled.

Edit: bonus, the maintenance picture (rarer than the error one, although not exceptional) just popped up too. Here it is:

• Open inc/class_parser.php
• In function mycode_parse_url, find:
  $link = "<a href=\"$fullurl\" target=\"_blank\">$name</a>";
• Replace it with:
  $link = "<a href=\"$fullurl\" target=\"_blank\" rel=\"nofollow\">$name</a>";

Save, upload, and you’re done.

As for the website URL from the website field, well, do as indicated on this tutorial, which summarizes as: add rel=nofollow in the postbit_www template. Or, better (this will also deal with the website on the user profile page and not just on the “www” button), install the previously mentionned NoFollow Website Links extension.

At first I installed a plugin called Image signature Limit. I don’t know for sure if it works fine, as I didn’t test it specifically. The problem with this plugin is that it doesn’t fix signatures which have been created in the past, and also it only takes care about the pictures, not the text size. So I left it enabled to prevent further submissions of too huge sig pictures, and I looked after another solution: manual style edits.

In MyBB you can edit templates and styles from the admin panel. Of course this is very tedious if you use several templates, but luckily for me I use only one, so this solution is good for me.

1. open the postbit_signature template. Its content should be:
   <hr size="1" width="25%" align="left" />
{$post['signature']}
   Replace it with
   <div class="signature">
{$post['signature']}
</div>
2. open global.css and add:
   .signature img {max-width:600px; max-height:150px; overflow:hidden;}
.signature {border-top: 1px solid #aaaaaa; width:100%; margin-top:1em; padding-top:0.2em; max-height:200px; overflow:hidden;}

That’s it. You can change the maximum height and width you want, of course. We also replaced the very ugly <hr> with a lighter 100% width border, of course this part is optional, it’s not needed to limit the signature size but very needed to give a decent look to the board IMO. The max-height and max-width attributes are, as far as I know, part of the CSS 2 specification, and work on Firefox, Opera, Safari, MSIE 7+.

This “tutorial” was tested using the Default theme on MyBB 1.4.7. At the time I’m writing you can view the result on http://bbs.wiki4games.com.

MediaWiki does have a function to generate its own sitemap. The script is located in the maintenance folder and is called generateSitemap.php. It have to be run from the console (thus you need the php-cli package). In order to have a regularly updated map, we chose to configure its generation to run as a daily Cron job. The command is quite straightforward:

php /home/username/www/maintenance/generateSitemap.php --fspath="/home/username/www" --server="http://www.wiki4games.com" --compress=no

NB: as for some or most of the maintenance scripts, this script requires AdminSettings.php (in the wiki’s root folder) to be filled properly. This file basically contains the login and password for a database user, and can be created based on AdminSettings.sample.

• /home/username/www/maintenance/generateSitemap.php is obviously the absolute path to generateSitemap.php
• –fspath=”/home/username/www” is the path to the folder where you want to save the sitemaps. The script will generate quite a few files, at it will create one sitemap per namespace. Yet, if you want to submit it to Google, you must not place the sitemaps in a subfolder of the wiki (see farther)
• –server=”http://www.wiki4games.com” is optional (use it if auto detection fails… or systematically if you prefer)
• –compress=no disable sitemap compression. I don’t know if Google is able to read compressed sitemaps, so I disabled it (default is yes)

Submitting the map

To submit the sitemap to Google, go verify your site to Google Webmaster Tools (if you have soft 404 errors you’ll need to choose the meta tag verification, to add a meta tag just edit your default skin – eg skins/MonoBook.php -, search for “<head>” and add the meta tag somewhere after it) then submit the sitemap index, which is named something like sitemap-index-[database name]-[table prefix].xml. And wait for it to be crawled (should take a few minutes).

Fixing the errors

URL not allowed

URL not allowed
This url is not allowed for a Sitemap at this location.

This means that you placed your sitemap either in a level inferior to the pages you are listing (ie in a subfolder), either on another domain (if you’re listing https://www.mywiki.com, you can’t place the sitemaps in http://www.mywiki.com nor in https://www.mywiki.com/mymaps). So just move the sitemap to an appropriate place (very same domain and higher or same level as all the URLs listed).

Invalid URL

Invalid URL
We’ve detected that a Sitemap you’ve listed doesn’t include the full URL.

This is just a warning that shouldn’t prevent indexing. Yet for a nicer icon (valid instead of warning ) you may want to fix it. This warning is due to the fact that the sitemap index created by the script uses relatives URLs instead of absolute ones. To fix it, you’ll have to edit the script:

• open generateSitemap.php
• search for function indexEntry
• in this function, find "\t\t$filename\n" and add the path need to make the URL complete. For instance if your sitemap index is on http://www.mywiki.com/sitemap-index-wiki4games-wg_.xml, replace this text with "\t\thttp://www.mywiki.com/$filename\n" (note the slash!)

Regenerate your sitemap, then resubmit it to Google. All should be fine now… except if one of your maps has over 50k URLs (Google doesn’t accept this, you need to split them… and I don’t know how to do this :/)

1. Force the monobook skin for everyone (unless you want to edit every skin…) by putting this setting in LocalSettings.php:
$wgAllowUserSkin = false;
NB: this setting is new to MediaWiki 1.14! If you have an older version, either upgrade or see our previous tutorial

2. In your skins folder, create a file within a subfolder (for instance “0custom/ad_vertical.php”) with the following content (edit with your own Google Adsense code as well as your own alternative ad; also, make sure to choose a VERTICAL ad, since we are adding code in the left sidebar!):
<?php
if(!strstr($_SERVER['REQUEST_URI'], "Special:") &&
!strstr($_SERVER['REQUEST_URI'], "action=submit") &&
!strstr($_SERVER['REQUEST_URI'], "action=edit") &&
!strstr($_SERVER['REQUEST_URI'], "Template:"))
echo '<div id="v-g-ads" class="portlet">
<h5>Google ads</h5>
<div class="pBody">
<script type="text/javascript"><!--
google_ad_client = "pub-9471398824076666";
/* 120x240 for Wiki4Games sidebar */
google_ad_slot = "3512091103";
google_ad_width = 120;
google_ad_height = 240;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>
</div>
</div>';
else echo '<div id="v-g-ads" class="portlet">
<h5>Ads</h5>
<div class="pBody">
<a href="http://proxify.com/r/?s=1320"><img src="http://proxify.com/i/info-110x110.gif" width="110" height="110" alt="disable proxy" border="0"></a>
</div>
</div>';
?>

3. Edit MonoBook.php as follow:
Replace:
function languageBox() {
if( $this->data['language_urls'] ) {
?>
<div id="p-lang" class="portlet">
<h5><?php $this->msg('otherlanguages') ?></h5>
<div class="pBody">
<ul>
<?php foreach($this->data['language_urls'] as $langlink) { ?>
<li class="<?php echo htmlspecialchars($langlink['class'])?>"><?php
?><a href="<?php echo htmlspecialchars($langlink['href']) ?>"><?php echo $langlink['text'] ?></a></li>
<?php } ?>
</ul>
</div>
</div>
<?php
}
}
With:
function languageBox() {
if( $this->data['language_urls'] ) {
?>
<div id="p-lang" class="portlet">
<h5><?php $this->msg('otherlanguages') ?></h5>
<div class="pBody">
<ul>
<?php foreach($this->data['language_urls'] as $langlink) { ?>
<li class="<?php echo htmlspecialchars($langlink['class'])?>"><?php
?><a href="<?php echo htmlspecialchars($langlink['href']) ?>"><?php echo $langlink['text'] ?></a></li>
<?php } ?>
</ul>
</div>
</div>
<?php
}
include("0custom/ad_vertical.php");
}
NB: In fact we’re just adding the include at the end of the function.

4. Upload the stuff (don’t forget there are 2 files to upload, not just one), and you’re done

1. Open “includes/specials/SpecialVersion.php” with a text editor

2. Find the lines:
$this->softwareInformation() .
$this->extensionCredits();

3. Comment out the lines you want to hide (the first one is for MediaWiki, PHP and MySQL; the second one for the extensions), for instance if I want to only hide MediaWiki, PHP and MySQL versions, the new code is:
//$this->softwareInformation() .
$this->extensionCredits();

4. Upload the new file to your server.

That’s it. Don’t forget to reapply this “patch” every time you upgrade MediaWiki though!

A possibility (which I didn’t test) would be to create a tiny PHP page that outputs just the hash of your wanted new pass, save this as a text file and upload it in phpMyAdmin.

Another possibility is to follow the LimeSurvey wiki, which says to restore the install folder and run a password reset script (btw, this explains a lot why you need to delete/move the install folder after the installation process…).

My personal favorite, because I think it’s the fastest, is:

1. edit the file admin/usercontrol.php as follow:
   
   find if (SHA256::hash($_POST['password']) == $fields['password']) (in LimeSurvey 1.72 it’s on line 115)
   replace it with if(true)
2. now log in using your proper admin login and any password
3. go to user management and edit the your password (don’t worry, it won’t ask you to enter your old password)
4. edit admin/usercontrol.php back to normal, i.e. replace:
   if(true)
   with
   if (SHA256::hash($_POST['password']) == $fields['password'])

Now you’re done
It should be noted that with this method, anyone can log in to any account provided that they know the name of this account. So if your admin account is easy to guess (random example: if you let the defaut name “admin”), the method is a bit risky, particularly if you’re slow. In this case, putting an .htacces like the following one in the admin folder would be more reasonable:
Order Deny,Allow
Deny from all
Allow from [put your IP here]


I needed this one for various anti-leech protections, including on this very site (notably for the img server), as used in this .htaccess file:

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^http://patheticcockroach\.com/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://patheticcockroach\.com$ [NC]
RewriteCond %{HTTP_REFERER} !^http://[A-Za-z0-9]*\.patheticcockroach\.com/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://[A-Za-z0-9]*\.patheticcockroach\.com$ [NC]
RewriteCond %{HTTP_REFERER} !^$ [NC]
RewriteRule \.(jpg|jpeg|gif|png|bmp|7z|exe|xpi)$ - [F,NC]

• RewriteEngine on: loads mod_rewrite (NB: you still need to have mod_rewrite enabled in your Apache configuration, though)
• RewriteCond %{HTTP_REFERER} !^http://patheticcockroach\.com$ [NC]: RewriteCond is a directive which defines a condition under which rewriting will take place. The syntax is RewriteCond $StringToTest $Regex [$flags].
  %{HTTP_REFERER} refers to the referrer HTTP header (variable names have to be used like: %{variable name}). “!” means (like usual) “not”.
  ^http://patheticcockroach\.com$ is the regexp to which we compare the referrer. “^” means string start, “\” is used to escape the dots (which otherwise are part of regex syntax), “$” means string end.
  [NC] means we don’t care about the case.
  So this regex will match “http://patheticcockroach.com”, and with the additional mod_rewrite NC flag, this will also match, for instance “http://PATHETICcockroach.com”
• RewriteCond %{HTTP_REFERER} !^http://patheticcockroach\.com/.*$ [NC]: almost the same, except for the “.*”. “.” (dot) means “any character”. “*” (asterisk) means “the preceding element can be there zero to an infinite number of times”.
  So this will match, for instance “http://patheticcockroach.com/mpam4/?p=4″.
• RewriteCond %{HTTP_REFERER} !^http://[A-Za-z0-9]*\.patheticcockroach\.com$ [NC]: [A-Za-z0-9] means “one character in the range A to Z, a to z or 0 to 9″. As we saw earlier, “*” means “the preceding element can be there zero to an infinite number of times”.
  So this will match things like “http://notepad.patheticcockroach.com” or “http://ngfdg45FD.patheticcockroach.com”. Note that specifying A to Z AND a to z is redundant, since we specify at the end “[NC]“.
• RewriteCond %{HTTP_REFERER} !^$ [NC]: ^$ is the empty string, so if the user uses a very old browser which doesn’t send referrers (or most likely a browser configured to not send referrers), we still accept it.
• RewriteRule \.(jpg|jpeg|gif|png|bmp|7z|exe|xpi)$ – [F,NC]: RewriteRule is a directive which defines rules for the rewriting engine. The syntax is RewriteRule $Regex $Substitution [$flags].
  \.(jpg|jpeg|gif|png|bmp|7z|exe|xpi)$ matches “.jpg”, “.jpeg”, “.gif”, “.png”, “.bmp”, “.7z”, “.exe”, “.xpi”. We already saw the meanings of “\” (backslash), “.” and “$”. The parentheses are used the same way as most often, to group/sort operators. “|” (vertical bar) means “or”. So jpg|png means jpg or png. And \.(jpg|png) means .jpg or .png.
  “-” (dash) means we do no substitution. We already saw the NC flag. The F flag means the requested URL will be forbidden (if the RewriteConds are all true, eg if the URL doesn’t match our regex.

The funny thing is that, as I wrote this post, I got a bit more friendly to regexp and mod_rewrite… well, that was part of the objective I guess. The references I used today:

• mod_rewrite in the Apache 2.2 documentation (talks about RewriteEngine, RewriteCond, RewriteRule and much more)
• Regular expressions on Wikipedia: not the “decent manual” I was talking about in the intro, but still decent indeed
• Some page on regex on Micro$oft. I didn’t really use it, but this is what decided me to make this post, and there are some elements I’d like to check later… Okay, I’m just making a bookmark.
• A regex tester (making another bookmark indeed).