I’m a pretty social girl. Whenever I see something new in social media that I think will have a big impact, I jump on the bandwagon as soon as I can. This past week Facebook released this new “like” button for people to use on their websites. It allows people to like pages that are not part of Facebook, and posts links to the Facebook news feed. Pretty sweet.

I like it!

I added it to The Pet Wiki as soon as I could. There are two versions – the FBML version and the iframe version. I went with the iframe version because I don’t have the JavaScript SDK running on my site. The iframe version works really well and has all the fuctionality of the FBML version. To add it, include this code in you skin:

<iframe src=”http://www.facebook.com/plugins/like.php?href=<?php echo urlencode($skin->mTitle->getFullURL()); ?>&amp;layout=standard&amp;show_faces=false&amp;width=450&amp;action=like&amp;colorscheme=dark” scrolling=”no” frameborder=”0″ allowTransparency=”true” style=”border:none; overflow:hidden; width:450px; height:20px”></iframe>

This version does not show the little pictures of people who like the page. If you want it to show the pictures, set show_faces=true. I also modified it to be a lot smaller than the original widget. You can play with the height and width to suit your site. I have like in my header – I stuck it right in the <h1> tag in the skin. I like seeing it at the top. Some people are trying to convince me to put it at the bottom of the page, so that I can include the faces as well. I still have to think about it. What do you think?

Google recently announced that they were donating $2 million to the Wikimedia foundation. According to a press release from the Wikimedia foundation, they plan to use part of that money to make “Wikipedia easier to use and more accessible.”

That’s incredible news for little wikis like The Pet Wiki. Sure, reading a wiki is fine, but trying to add content to it can be a bit confusing. Wikitext, which was invented to make editing wikis easier, can be difficult to use. Here’s a funny video from WetPaint:

The whole idea was that people shouldn’t need to know how to add html tags. Wikitext is easier than html, but it’s a far cry from the WYSIWYG editors that we have all come to know and love. A while back I tried to use FCKeditor. It was much easier to use. I was thrilled. The only problem with it was that it was horribly slow to load. Pages took forever. I didn’t want any barriers for people to add content, and the time was a bigger barrier than the original wikitext, so off it went.

Wikimedia has begun this all out usability initiative. Although they are not deviating away from wikitext, they are giving tools that will make it much easier for people to add and edit content. This new, nifty edit bar at the top of the edit box gives users a lot more freedom to write. By not being bogged down, I think it will be much easier for people to be creative.

New Wiki Toolbar

They are adding outline tools for editing large articles, and just making the whole edit screen a lot more friendly.

There are other parts to the initiative, like a whole new skin for wikis, but since I created my own Wiki skin it won’t affect me quite as much as a lot of other people.

These changes went out as a beta on Wikipedia a while ago. I have been waiting on pins and needles for the next version release of the MediaWiki in order to benefit from the wonderful work that has been done. The second version of the beta has already been released. Now with the loot that they got from Google, I hope that Wikimedia will be able to get it done really soon. I’m sure that I’m not alone when I say that you guys at Wikimedia (and MediaWiki.org) are totally cool!

One click away...

I have to say one of the coolest things about working with people is to see them succeed. When you put the right person in the right job, they flourish, and you get to enjoy all the benefits of their wonderful work. I recently found Rony Perez, a great part time programmer.

In my post on My Favorite MediaWiki Extensions, I mentioned that although I already had the Facebook Connect working on the site, there was still a lot of work to be done, and that I was looking for a programmer to help me finish the job. Well I found someone, and he has been amazing to work with.

Originally, all we had was the minimal functionality of just creating a new user account with a Facebook ID. That was nice and all – it made it really easy for people to create an account. My biggest problem with this was that I really had no way to contact people after they created the account. Sure, I could write on their message boards that came with the SocialProfile extension that I added, but that wasn’t really enough. Unless they went back to the site, and back into their profile, there was no way for them to see that they got a message.

Email:

With the user’s OK, Rony was able to get me email addresses for people when they sign up for a new account. It takes the information from their Facebook profile. There is a screen that asks users if they want to share that information from us, so we’re not prying where we don’t belong, but it seems if you’re going to the trouble to connect with Facebook, users don’t mind sharing that information too. This is huge.

This is what shows up in the Newsfeed

Publishing:

The next thing that Rony did to make Facebook Connect a really powerful feature it that we are now able to publish new and modified pages on The Pet Wiki into the user’s newsfeed.

This is totally using Facebook Connect the way that it was meant to be. Think about it. If you spend time working on a page, don’t you want to let your friends know about it? They can read what you wrote and let others know about it. It’s incredibly viral.

Merging:

Have an old account, and what to start using Facebook Connect? No problem. Rony also added merging of regular accounts to Facebook accounts. Nothing gets lost. It’s very cool. I took the “Merge” feature out of the skin. I’ll be putting it back very soon.

The next thing to do will be to fill out the SocialProfile from information from the Facebook profile. That will be happening very soon.

All the work that has been done on the Facebook Connect extension will be shared back with the MediaWiki community. The original license is a GPLv2 license. People were nice enough to share it with us, it’s a really nice feeling to be able to give back.

Thank you Rony, for all the amazing work that you’ve done on this. I can’t wait to start the next project.

Finding your way

There are two types of people in this world: searcher and navigators. Searchers are the direct people who know what they want, find the search box and type away. Navigators look around and see what other information is out there that might interest them on any given subject. They might not realize what they are looking for. They might just want to go on an expedition. They may just be the type that hates to ask directions.

For the adventurers out there that want to swim through the river of information, it is important to make their path as painless as possible. When it comes to the MediaWiki, there are a few ways to do just that.

You know how there are those cool links at the bottom of the pages in Wikipedia that contain links to similar subjects? Like the page on the Mets’ Daniel Murphy that has links to all the people on the Mets current roster at the bottom of the page. If all that information gets in your way, all you need to do is hide it.

It’s great for Wikipedia, but how do you get it on your own MediaWiki site? There are a couple of things you have to do. One involves template, the other involves modifying MediaWiki:Common.js and MediaWiki:Common.css.

Let’s start with templates. To create templates, all you need to do is create a page called Template:TemplateName (change TemplateName to whatever you want to call your template). Now that you have the page, set it up to look the way that you want and you are ready to use it. Use standard WikiText or html.

You can even be clever about it and send variables to the templates. Here’s an example:

The origin of this dog breed is {{origin}}

To call the template on any page in your wiki, all you need to do is type {{TemplateName}}. If you set up a way to send parameters, like in our dog breed example, call it by typing {{DogBreed|origin=”United States”}}

That’s a very quick overview of templates. You can do a ton of stuff with them, but I don’t want to get too off the topic of navigation. The idea is to create a template with a lot of links that can be used in a lot of places. In the Daniel Murphy example, the same template used to show all the links to the other players also exists on all the other players pages. One template for 40+ team members. Not bad. Saves a lot of time in typing, and to make a change, you update it in one place and all the pages that use the template will have the change as well.

Templates are cool, but having a lot of links all over the place can get to be a bit much. That’s where the second part of my plan comes in. Notice that the box has a little hide/show link on the right hand side. To make sure that all those links don’t get in the way, it’s nice to be able to store them away. To do that, MediaWiki has added an easy way to modify and add the css and javascript files that run in the background for every page. You don’t need any ftp access (you do need administrator privledges) and can make the modifications directly in your browser. The pages that need to get modified are your MediaWiki:Common.js and MediaWiki:Common.css

Disclaimer: I didn’t write any of this code – this is stuff that I put together from both MediaWiki and Wikipedia’s sites. I’m repeating it here because I found it a bit hard to find and get working correctly.

Add this to your MediaWikiCommon.css

/* Standard Navigationsleisten, aka box hiding thingy
   from .de.  Documentation at [[Wikipedia:NavFrame]]. */
div.NavFrame {
    margin: 0;
    padding: 4px;
    border: 1px solid #aaa;
    text-align: center;
    border-collapse: collapse;
    font-size: 95%;
}
div.NavFrame + div.NavFrame {
    border-top-style: none;
    border-top-style: hidden;
}
div.NavPic {
    background-color: #fff;
    margin: 0;
    padding: 2px;
    float: left;
}
div.NavFrame div.NavHead {
    height: 1.6em;
    font-weight: bold;
    background-color: #ccf;
    position: relative;
}
div.NavFrame p,
div.NavFrame div.NavContent,
div.NavFrame div.NavContent p {
    font-size: 100%;
}
div.NavEnd {
    margin: 0;
    padding: 0;
    line-height: 1px;
    clear: both;
}
a.NavToggle {
    position: absolute;
    top: 0;
    right: 3px;
    font-weight: normal;
    font-size: 90%;
}

Add the following to your MediaWiki:Common.js file:

/** Collapsible tables *********************************************************
 *
 *  Description: Allows tables to be collapsed, showing only the header. See
 *               [[Wikipedia:NavFrame]].
 *  Maintainers: [[User:R. Koot]]
 */

var autoCollapse = 2;
var collapseCaption = "hide";
var expandCaption = "show";

function collapseTable( tableIndex )
{
    var Button = document.getElementById( "collapseButton" + tableIndex );
    var Table = document.getElementById( "collapsibleTable" + tableIndex );

    if ( !Table || !Button ) {
        return false;
    }

    var Rows = Table.rows;

    if ( Button.firstChild.data == collapseCaption ) {
        for ( var i = 1; i < Rows.length; i++ ) {
            Rows[i].style.display = "none";
        }
        Button.firstChild.data = expandCaption;
    } else {
        for ( var i = 1; i < Rows.length; i++ ) {
            Rows[i].style.display = Rows[0].style.display;
        }
        Button.firstChild.data = collapseCaption;
    }
}

function createCollapseButtons()
{
    var tableIndex = 0;
    var NavigationBoxes = new Object();
    var Tables = document.getElementsByTagName( "table" );

    for ( var i = 0; i < Tables.length; i++ ) {
        if ( hasClass( Tables[i], "collapsible" ) ) {

            /* only add button and increment count if there is a header row to work with */
            var HeaderRow = Tables[i].getElementsByTagName( "tr" )[0];
            if (!HeaderRow) continue;
            var Header = HeaderRow.getElementsByTagName( "th" )[0];
            if (!Header) continue;

            NavigationBoxes[ tableIndex ] = Tables[i];
            Tables[i].setAttribute( "id", "collapsibleTable" + tableIndex );

            var Button     = document.createElement( "span" );
            var ButtonLink = document.createElement( "a" );
            var ButtonText = document.createTextNode( collapseCaption );

            Button.className = "collapseButton";  //Styles are declared in Common.css

            ButtonLink.style.color = Header.style.color;
            ButtonLink.setAttribute( "id", "collapseButton" + tableIndex );
            ButtonLink.setAttribute( "href", "javascript:collapseTable(" + tableIndex + ");" );
            ButtonLink.appendChild( ButtonText );

            Button.appendChild( document.createTextNode( "[" ) );
            Button.appendChild( ButtonLink );
            Button.appendChild( document.createTextNode( "]" ) );

            Header.insertBefore( Button, Header.childNodes[0] );
            tableIndex++;
        }
    }

    for ( var i = 0;  i < tableIndex; i++ ) {
        if ( hasClass( NavigationBoxes[i], "collapsed" ) || ( tableIndex >= autoCollapse && hasClass( NavigationBoxes[i], "autocollapse" ) ) ) {
            collapseTable( i );
        }
        else if ( hasClass( NavigationBoxes[i], "innercollapse" ) ) {
            var element = NavigationBoxes[i];
            while (element = element.parentNode) {
                if ( hasClass( element, "outercollapse" ) ) {
                    collapseTable ( i );
                    break;
                }
            }
        }
    }
}

addOnloadHook( createCollapseButtons );

/** Dynamic Navigation Bars (experimental) *************************************
 *
 *  Description: See [[Wikipedia:NavFrame]].
 *  Maintainers: UNMAINTAINED
 */

// set up the words in your language
var NavigationBarHide = '[' + collapseCaption + ']';
var NavigationBarShow = '[' + expandCaption + ']';

// shows and hides content and picture (if available) of navigation bars
// Parameters:
//     indexNavigationBar: the index of navigation bar to be toggled
function toggleNavigationBar(indexNavigationBar)
{
    var NavToggle = document.getElementById("NavToggle" + indexNavigationBar);
    var NavFrame = document.getElementById("NavFrame" + indexNavigationBar);

    if (!NavFrame || !NavToggle) {
        return false;
    }

    // if shown now
    if (NavToggle.firstChild.data == NavigationBarHide) {
        for (var NavChild = NavFrame.firstChild; NavChild != null; NavChild = NavChild.nextSibling) {
            if (hasClass(NavChild, 'NavContent') || hasClass(NavChild, 'NavPic')) {
                NavChild.style.display = 'none';
            }
        }
    NavToggle.firstChild.data = NavigationBarShow;

    // if hidden now
    } else if (NavToggle.firstChild.data == NavigationBarShow) {
        for (var NavChild = NavFrame.firstChild; NavChild != null; NavChild = NavChild.nextSibling) {
            if (hasClass(NavChild, 'NavContent') || hasClass(NavChild, 'NavPic')) {
                NavChild.style.display = 'block';
            }
        }
        NavToggle.firstChild.data = NavigationBarHide;
    }
}

// adds show/hide-button to navigation bars
function createNavigationBarToggleButton()
{
    var indexNavigationBar = 0;
    // iterate over all < div >-elements
    var divs = document.getElementsByTagName("div");
    for (var i = 0; NavFrame = divs[i]; i++) {
        // if found a navigation bar
        if (hasClass(NavFrame, "NavFrame")) {

            indexNavigationBar++;
            var NavToggle = document.createElement("a");
            NavToggle.className = 'NavToggle';
            NavToggle.setAttribute('id', 'NavToggle' + indexNavigationBar);
            NavToggle.setAttribute('href', 'javascript:toggleNavigationBar(' + indexNavigationBar + ');');

            var isCollapsed = hasClass( NavFrame, "collapsed" );
            /*
             * Check if any children are already hidden.  This loop is here for backwards compatibility:
             * the old way of making NavFrames start out collapsed was to manually add style="display:none"
             * to all the NavPic/NavContent elements.  Since this was bad for accessibility (no way to make
             * the content visible without JavaScript support), the new recommended way is to add the class
             * "collapsed" to the NavFrame itself, just like with collapsible tables.
             */
            for (var NavChild = NavFrame.firstChild; NavChild != null && !isCollapsed; NavChild = NavChild.nextSibling) {
                if ( hasClass( NavChild, 'NavPic' ) || hasClass( NavChild, 'NavContent' ) ) {
                    if ( NavChild.style.display == 'none' ) {
                        isCollapsed = true;
                    }
                }
            }
            if (isCollapsed) {
                for (var NavChild = NavFrame.firstChild; NavChild != null; NavChild = NavChild.nextSibling) {
                    if ( hasClass( NavChild, 'NavPic' ) || hasClass( NavChild, 'NavContent' ) ) {
                        NavChild.style.display = 'none';
                    }
                }
            }
            var NavToggleText = document.createTextNode(isCollapsed ? NavigationBarShow : NavigationBarHide);
            NavToggle.appendChild(NavToggleText);

            // Find the NavHead and attach the toggle link (Must be this complicated because Moz's firstChild handling is borked)
            for(var j=0; j < NavFrame.childNodes.length; j++) {
                if (hasClass(NavFrame.childNodes[j], "NavHead")) {
                    NavFrame.childNodes[j].appendChild(NavToggle);
                }
            }
            NavFrame.setAttribute('id', 'NavFrame' + indexNavigationBar);
        }
    }
}

addOnloadHook( createNavigationBarToggleButton );

/** Test if an element has a certain class **************************************
 *
 * Description: Uses regular expressions and caching for better performance.
 * Maintainers: [[User:Mike Dillon]], [[User:R. Koot]], [[User:SG]]
 */

var hasClass = (function() {
	var reCache = {};
	return function( element, className ) {
		return (reCache[className] ? reCache[className] : (reCache[className] = new RegExp("(?:\\s|^)" + className + "(?:\\s|$)"))).test(element.className);
	};
})();

To use these to get your fancy hide/show sections, you need to use the following html divs:

<div class=”NavFrame collapsed”>
<div class=”NavHead”>Title of the Box</div>

<div class=”NavContent”>

The html/links that you want to use

</div>
</div>

To see more information on how to use this type of navigation, check out Wikipedia’s explanation.

I happen to use Dynamic List Pages in my navigation sections. That creates a lot of links of pages that are in the same category. To see how it turned out on The Pet Wiki, check out Great Danes. At the bottom of the page you’ll see my handy work.

That gives some nice links that drill down into related areas, but what if I want to get back to the main sections? Don’t worry, MediaWiki has taken care of that too. There’s a nice little page called MediaWiki:Sidebar which lets you easily modify the left side bar of your site. I used it to add links to my main categories: Dogs, Cats, Birds… (you get the idea) so that people will be able to get to the main section that they are looking for. The syntax is pretty simple. For the title of the section, add * and for pages that you want to link to **. Here’s an example from The Pet Wiki:

* navigation
** mainpage|mainpage-description
** Dogs|Dogs
** Cats|Cats
** Birds|Birds
** Rodents|Rodents
** Horses and Ponies|Horses
** Reptiles|Reptiles
** Other Pets|Other Pets
** All Pets|All Pets
** portal-url|portal
** helppage|help
* TOOLBOX

The first part is the page that you want to link to, followed by the title.

There are more ways to add links, but I think that these are the two most effective. Besides providing people with a way to get around your site, adding links has a nice SEO advantage as well. The code provided is totally readable by search engines, and this is a great way to give spiders more access to your pages.

<div xmlns:cc=”http://creativecommons.org/ns#” about=”http://www.flickr.com/photos/geebee2007/3516653918/”>Image: <a rel=”cc:attributionURL” href=”http://www.flickr.com/photos/geebee2007/”>http://www.flickr.com/photos/geebee2007/</a> / <a rel=”license” href=”http://creativecommons.org/licenses/by/2.0/”>CC BY 2.0</a></div>

I talked about installing extensions last week. This week I figured that I’d dive into which extensions I love to use.

Before I get started on my list of favorite MediaWiki extensions, I want to say that it is amazing how much people have contributed to making MediaWiki one of the most fun and useful platforms to use. There are so many great extensions out there, that it is really hard to choose which are my favorites. I’ll try to keep the list as focused as possible. You MediaWiki developers make it really hard!

Here’s my list – I couldn’t figure out what the order of importance was, so I just put them in alphabetical order.

• AWC’s Forum – The AWC Forum extension is more than your exeryday extension. It doesn’t really run inside the normal wiki part of your wiki. It is a full powered forum that runs in your mediawiki’s wrapper. It’s a little more intense to set up than your regular extensions. To get all this functionality, database tables need to be added to your wiki. Not to fear, the extension comes with a setup program that installs them for you. Like any forum, it allows users to have group conversations, and includes a system for direct messaging one another.
  
• CanonicalHref – Is there a way to get to pages in your wiki using different urls? This is an SEO no-no. You want to make sure that the search engines can only get to a page of content from one url. If not, the SEO power may be split among the different URLs that have the same content. By adding a canonical url to each page, you tell the search engines which url should be used for this page, no matter how they got there. The Pet Wiki runs on version 1.15.1 of the MediaWiki. I’ve been told that this extension will be part of the MediaWiki core code when 1.16 is released.
• CharInsert – I find WikiText (the markup language that is supposed to make it easy for people to add to a wiki) very cumbersome. There are lots of square brackets all over the place and I’m never 100% certain that I got it right. That’s ok. By adding CharInsert extension, I get a nice grouping of WikiText functions that I can use to both get it right and save time. I find that I use it a lot when I’m adding categories to pages. It’s a huge time saver.
• ContributionCredits – It’s nice to give credit where credit is due. If people spend their precious time adding to the wiki, there is no reason that they shouldn’t also get credit. ContributionCredits is a nice way to display just that.
• CreateBox – You decided to set up a wiki because it’s a great way for people to share their knowledge, right? The one thing that I found really hard to explain to people is how to add new pages. No more. By adding CreateBox to my homepage, it’s easy for people to add content. All they need to do is type in the box and hit the create button, and they are ready to type away.
  
• DynamicPageList – This is one of the most useful extensions that I’ve ever found. It’s really incredible. It creates lists of all the pages in the same category. A good example of it in action is the Dogs page on The Pet Wiki. By adding a couple of lines to the page, it displays all pages categorized as dogs. You can only imagine how much work it was to add one breed to that list before. Now it is done automatically.
  Code:
  <dpl>
  category = Dog Breeds
  columns = 3
  </dpl>
• EmbedVideo – This does exactly what you would expect it to do. It allows you to embed video easily into your wiki from the major video providers, like YouTube, Google Video and Dailymotion.
  
• FBConnect – I have to put FBConnect in my favorites, but I really have a love hate relationship with this extension. This is an extension that is still in beta, and is missing some functionality to make it a realy winner, but the concept is sound. Instead of making people go through the nasty process of registering for an account, they can now hook in to The Pet Wiki with their Facebook user account.
  I’m currently looking for someone to help me finish developing this extension. Whatever changes are made to it will be shared back to MediaWiki.org. If you know anyone interested in giving me a hand, send me a line.
  
• ShareThis – This is a cool extension that allows people to share information from your wiki through a slew of different types of social bookmarking. It comes with some very standard ones, but you can add some of your favorites (or take out some that might not be relevant to your wiki) to customize it just the way that you like.
  
• Slideshow – This is an extension that I don’t use enough. It does exactly what you would expect it to do – it takes pictures that you’ve uploaded onto you wiki and displays them as a slide show. You can customize the speed and the transitions of the slides.
• SocialProfile – This is the mother of all extensions. Those nice people at Wikia have created a bunch of wonderful extensions that they are kind enough to share with everyone. What SocialProfile does is create an amazing way for people to create a profile and link with other people. Besides allowing people to use an avatar, so that you can see who you are talking to, it also allows people to message one another. You can “friend” people, the same way that you do in Facebook (you can also “foe” people, but I took that out). Like the AWC forum, this extension creates database tables specifically for its own use. I’ve modifed it in The Pet Wiki to allow people to give little bios of their pets.

There are a ton more extensions out there. If you’re new to this, I would suggest going to MediaWiki.org and browsing through the extensions. Which ones do you like?

ShareThis extension on The Pet Wiki

One of the most fun things about using MediaWiki to build your site is all the cool extensions that people have created to make your site better. When you look at your site and say “Wouldn’t it be great if…”, someone has probably already thought the same thing and has created an extension that you can use. I won’t say that the extensions are always a perfect fit, but they are there, and can be modified to do what ever you want them to.

Here’s an example from The Pet Wiki: I’m a social kind of gal, and I really like to share and allow others to share what they read. What better way to do this than add social bookmarking to my site. The first thing that I did was go to MediaWiki.org and search for “extension social share.” (Using Google also works.) Viola! I got “Extension:ShareThis” in the search results.

Each extension page has instructions on how to install it. For most extensions, all you’ll need to do is ftp files to the extensions directory and modify your LocalSettings.php file to get it up and running. Some are a bit more complicated, but only a bit.

Since you already set up a MediaWiki development environment, you should check to make sure that the extension works in your dev environment. This is very important. You can crash your whole site by turning on an extension that doesn’t work with your site.

Even if it does seem like you’ve done damage, it’s very easy to remove the extension by removing the offending line from your LocalSettings.php file. Always make sure to move the extension files before you make your modifications to LocalSettings.php. Updating LocalSettings.php turns the extension on. Depending on the extension, it is also used to set properties for the extension.

One thing that is particularly amazing about using extensions is that it lets you upgrade your MediaWiki wiki to new versions without needing to worry about losing all the work that you’ve put into adding funtionality. I personally can’t wait for MediaWiki version 1.16 to come out. A lot of incredible work has been done to enhance usability. As soon as it’s out, I’ll be able to upgrade and not lose the look and feel of what I’ve put together. Man, those people at MediaWiki.org are a bright bunch!

There are a lot of great things about creating a wiki. There is a sense of community and collaboration. People are able to share their knowledge. Depending on how the wiki is set up, anyone can go in and create and edit content. Sounds good, right? Most people are really good and play nicely on The Pet Wiki, but there are a few that I’ve been trying to nip in the bud for some time now. They add links to other sites that have nothing to do with animals. I have no problem allowing links to other pet sites, but no gambling, legal advice or medication please! Here are the strategies that I’ve used to fight spam:

• No follow: It’s nice to be a good SEO citizen and share the wealth with other good sites out there, but people can and will take advantage. Originally, when I first went out, I allowed search engines to follow all the links in the site. Spammers took advantage of this and stuck all kinds of links to who knows what kinds of sites. Setting the wiki to have “no follow” links reduced the number of new spam links added. To set your wiki to be “no follow,” make sure that $wgNoFollowLinks = true; is set in your LocalProperties.php file.
• Block: By nature, I hate censorship. It’s just one of those things that you learn in school that sticks with you for life. All that goes out the window when it comes to spammy links. I block those suckers with reckless abandon. Most of the time, what I’m blocking are random IP addresses. I usually give it a time limit, so that if another user coming from the same IP address tries to edit a page, they can still get to it eventually. I also don’t stop new account creation from that IP address for the same reason.
• AkismetKlick: Akismet is the spam blocker that WordPress uses. They’ve put together a list of naughty spammers, so by adding the AkismetKlick extension for MediaWiki, you’ll be able to block these known culprits. I don’t usually suggest people use experimental extensions, but I’ve been using it now for over half a year without any negative consequences.
• No more Talk: MediaWiki opens itself up for dicussions on every page. Unfortunately, they also open up a perfect place for spammers to do their dirty work. It was a hard decision to make, but I decided take talk pages out. They were used far more often by spammers than by anyone else. To take them out:
  1. I removed the ablilty to added or edit talk pages by all users by adding:
     

     $wgGroupPermissions['*']['edittalk'] = false;
     $wgGroupPermissions['*']['createtalk'] = false;

     to the LocalProperties.php file

  2. I removed the tab from the skin of the wiki. The first thing to do is add #ca-talk { display:none; } to my main.css. Next, go into your skin.php file. Look for:
     

     foreach($this->data['content_actions'] as $key => $tab) {

     and add the following check:

     if($key != ‘talk’){
     ….
     }

     This will block the talk tab from being written into the HTML page. Note: this is to get rid of the regular page discussions. User talk pages will not be affected.

     Even though I’ve removed these ways for people to communicate to each other, I’ve added some very cool extensions that foster communication and community. I’ll get more into that next time.

The measures that I’ve put in place have nearly completely removed my spam problem. What do you do to get rid of spam from your wiki?

The Pet Wiki

So, you have a MediaWiki site up and running, you set up a local copy of the MediaWiki environment, you created a development environment and you have a wiki skin ready to be modified. Now what? Here’s where the fun begins.

What do you want your wiki to look like? If you have graphic skills great. Create a mockup and convert that image into standard css and html. If you are graphically challenged, find someone who isn’t and get their help. I called on PetWebDesigner.com to come up with the basic design, and I took it from there. (My daughter created the logo.)

For the sake of simplicity, let’s say that you name your skin MySkin. To modify your skin, you will be editing two files: MySkin.php, found directly in the skins folder and main.css, which is in skins/myskin folder. There is no need to touch anything besides these two files and your LocalSettings.php file, which is in the root directory.

Let’s start with changing the logo. I put the logo for The Pet Wiki in the skins/thepetwikiskin folder. Since I’m working on a few different wikis (check out The Met Wiki), it’s easier for me to keep the different logos for the different skins straight. After you’ve saved the file to the place you want, you’ll need to add a line to your LocalSettings.php file, located in the root directory of the wiki. Add or modify the following line:

$wgLogo = “$wgScriptPath/skins/myskin/YourLogo.jpg”;

If you keep the logo somewhere else, change the path to match where it’s coming from. That’s it. Your logo has now been changed.

The first thing I did, before trying to modify anything, was put a bunch of debug text in MySkin.php. Brilliant text like “Where is this,” so I could figure out the different elements and how to move them around. I modified the php file as little as possible. Most of the work gets done in the main.css.

A few things to keep in mind:

1. Each section of the page is its own div. No tables are used to create the page. Be careful with how you layer them or some may get lost. If a section gets lost, check and set the z-index correctly. They’ll show up again. (To use z-index, make sure that your position is absolute.)
2. More often than not, to change the location of any of these divs, you’ll change the padding  for the element in main.css.
3. The p-personal div (the login pod) is not connected to the other navigation divs. If you want to move it to the left hand side, you need to deal with it separately. All other left hand navigation will move when you move the p-navigation div.
4. The tabs at the top are actually done as a list.
5. If you don’t want to use a specific element and it’s getting in the way, hide it.
6. Make styles for specific elements that are not already defined. You can add as much as you want to tweak it to be perfect for you.

I wanted to change the search box to be front and center and to use graphics, so I needed to create a new function in the php file to handle the formatting. I then called the function from the class where I wanted it to go and hid the old search functionality, and walla, new search box added.

You will also need to take out the references to the monobook css from MySkin.php.

Change:

$out->addStyle( ‘monobook/main.css’, ’screen’ );

to:

$out->addStyle( ‘myskin/main.css’, ’screen’ );

And take out all references to other css files. Delete the following:

$out->addStyle( ‘monobook/IE50Fixes.css’, ’screen’, ‘lt IE 5.5000′ );
$out->addStyle( ‘monobook/IE55Fixes.css’, ’screen’, ‘IE 5.5000′ );
$out->addStyle( ‘monobook/IE60Fixes.css’, ’screen’, ‘IE 6′ );
$out->addStyle( ‘monobook/IE70Fixes.css’, ’screen’, ‘IE 7′ );

These did nothing to fix my skin, and caused me a lot of headache that was solved when I deleted them. Ironic that the files are ‘Fixes’.

If you’ve been following this series of blog posts, you should have set up source control. I suggest saving to source control when you’re happy with large changes. Don’t wait until the end of the day. You may find that you need to go back a few steps. Css changes are hard to remember, so don’t lose the good with the bad.

Test your wiki on multiple browsers before you release. I tested on FireFox, IE, and Chrome, but still got it wrong and went out with a skin that didn’t work properly on IE 7 (I had IE 8 installed). Css is treated differently in each browser. Make sure it works on the major ones before you go out.

Are you happy with what you have and are you ready to go live? Move the files over, including the logo. Move the skin files over before you move the changes that you make to the LocalSettings.php. Login on your live site and change your personal preferences to use your new skin. You won’t have the logo yet, but everything else should work. If you’re happy with what you see, reset your preferences to use the default skin. Change the following line in LocalSettings.php so that it uses your skin as the default.

Change:

$wgDefaultSkin = ‘monobook’;

to:

$wgDefaultSkin = ‘myskin’;

Move it over, and you’re done.

Just go out and play around with it. Use big numbers and crazy colors to figure things out. We built the whole development environment so we could have a good time and not break anything on your live site. Have fun.

Getting to Work on the Wiki

So you’ve installed the MediaWiki and you’ve set up a MediaWiki development environment. Now what? The next step is to get down and dirty and skin the thing. Skinning a wiki is the fun part. There is nothing like an amazing user interface to draw people into your site.

As a philosophy, I never start from scratch, at least not when it’s at all possible not too. There are a lot of other people out there who are a lot smarter than me. Why not use things that are tried and true before reinventing the wheel? I have personally found this way of doing things highly successful and efficient.

To skin our wiki, we’ll take MonoBook and modify it to suit our needs. There are a lot of things that are really great about MonoBook. Things that just work in that skin which don’t in other. Other skins that I’ve used break the RSS feeds to the site. That’s a no-no. When I wanted to submit the new pages that were added to a directory project, I found that the RSS was broken. By basing my skin on Monobook, the RSS is now in fine working order.

The MediaWiki people are truly genius. They built the Monobook skin to write the HTML in a way that moves the content to the top of the page. All the menus etc. are under the content. Very cool SEO benefit. Check it out by viewing the source of the page (on The Pet Wiki or any other site that uses Monobook).

Go to where you installed the MediaWiki and look for the skins folder. You’ll find the monobook folder and MonoBook.php.  Copy them and rename them to whatever you want to call your skin. If you’re not sure what you want to call it, don’t worry – skins are very easy to rename. For this article, let’s call it MySkin. Capitalization is important. The folder name should be in lowercase and the php file name should start with a capital letter (I like to capitalize each word in the name – like ThePetWikiSkin.php). It will work if you don’t do this, but it’s always a good idea to follow standard programming conventions.

Open MySkin.php in your development environment. If you are using Eclipse, if you haven’t already, make a project for development and open it from there. The first thing you’ll need to do is change a few of the basics.

Change:

class SkinMonoBook extends SkinTemplate {

/** Using monobook. */

function initPage( OutputPage $out ) {

parent::initPage( $out );

$this->skinname  = ‘monobook’;

$this->stylename = ‘monobook’;

$this->template  = ‘MonoBookTemplate’;

}

to:

class SkinMySkin extends SkinTemplate {

/** Using monobook. */

function initPage( OutputPage $out ) {

parent::initPage( $out );

$this->skinname  = ‘myskin’;

$this->stylename = ‘myskin’;

$this->template  = ‘MySkinTemplate’;

}

Next change:

class MonoBookTemplate extends QuickTemplate {

to:

class MySkinTemplate extends QuickTemplate {

Save MySkin.php. You’re not going to see much yet, but to make sure that your skin actually works, login to your wiki, click “my preferences” at the top right, and go to the skin tab. You should see MySkin in the list. Select it and save your preferences.

It may not look like much yet, but this is the basis for all the fun you will have for making the wiki your own. Congratulations. Next time we’ll get into how to customize your skin to give your site more personality.

Pet Wiki'ing?

This is a follow-up to the last MediaWiki article I wrote. Check out “Setting Up Your Local MediaWiki Environment” to set up the MediaWiki on your Windows machine.

Now that you have a copy of the MediaWiki running on your machine, it’s time to create an environment so that you can start manipulating your wiki to suit your needs.

Before I go any further, I want to make it perfectly clear that I do not suggest that you make any changes to the core of the MediaWiki. Unless what you’re doing is going to be incorporated into the main code for the MediaWiki, stay away. The people who do work on the main code do an amazing job and each release comes out with great new features and improvements. You want to make sure that you can reap the rewards of all their hard work. Make sure that you are able to upgrade your wiki to the latest version when the new MediaWiki comes out. If you do change the core code, upgrading will mean losing or reintegrating any changes you make.

So, if you’re not going to work on the MediaWiki itself, what are you going to work on? There are two main areas that are perfect for making your wiki site stand out: Skins and Extensions. You can work on both of these to make your site unique without doing any damage to the MediaWiki itself.

What’s a skin? A skin for a wiki is a lot like a skin of a human. It is the out outer shell that makes your wiki look nice. The skin that MediaWiki comes with, Monobook, is OK, but there’s so much more that you can do to make your wiki unique.

What are extensions? The developers for MediaWiki are really smart. They’ve created a way to extend the abilities of the MediaWiki without needing to modify the core code. Extension are little snippets of code that you can plug in to extend what the MediaWiki can do. A couple of examples of extensions that I use are anti-spam and youtube. Both of these extensions were created by other people, but were shared on the MediaWiki site. Extensions are very easy to install, and can add a lot to your site.

Now for your development environment. My personal preference for an integrated development environment (IDE) is Eclipse for PHP by Zend. It integrates nicely with source control and it’s completely free. To modify CSS and PHP files, you can use a regular text editor, like Notepad, but an IDE is just much nicer to work with.

On to source control. I am working on The Pet Wiki by myself, but I still use source control. Why? Because I want to get back to stable revisions of the code that I’ve created. Source control helps you compare different revisions and helps find where bugs may have slipped in along the way. I use Subversion, which I downloaded from Collabnet. Subversion is very easy to use. After it is installed, you can control checking in and out files in Windows Explorer. All the tools are in your right-click menu. Subversion also plays nicely with Eclipse.

Have any problems setting up Eclipse or Subversion? Give a holler. I’ll be happy to help you through it.

Image: http://www.flickr.com/photos/greggoconnell/ / CC BY 2.0