Posts Tagged ‘mediawiki’
If you use bugzilla and mediawiki then you need to take a look at BugzillaReports – http://www.mediawiki.org/wiki/Extension:BugzillaReports. This extension allows you to integrate Bugzilla reports into mediawiki pages. It’s gone through a beta programme over the past 6 months with the stable 1.0 release out a couple a weeks ago. I’ve now released it onto Google code – http://code.google.com/p/bugzillareports/ – to make it easier to deal with incoming requests and also allow other developers join in a make direct changes. Download it, try it out and hopefully you find it useful.
Cheers,
Ian
In response to How the Wikipedia reputation engine works and why Wikipedia should not allow anonymous edits …
Great write up – I’ve always been fascinated by the way the Wikipedia content has evolved and especially around the different roles of the people making the content happen – right from the person watching the Oscars as it happens and editing the page with in seconds, all the way to the wiki gnomes keeping the garden clean. The wiki patterns @ http://www.wikipatterns.com/display/wikipatterns/Wikipatterns was enlightening for me on describing the different types of editors and administrators. Wikipedia is most of the time “correct”, but if it were to be a trusted source then there has to be some accountability for the content and that does mean edging away from anonymity and away from the very thing that has allowed it to grow so rapidly. For me, it’s quite a positive sign on the web community that there is a so much stronger force trying to make it “right” as opposed to the minority who mislead or vandalise. I often wonder whether Wikipedia should try to be like a trusted encyclopedia / journal – or whether it is simply a different beast with agile-mostly-correct content. Then I start philosophising on who do I really trust and have to remind myself to always take what I read and hear with a pinch of salt, even from the most trusted of sources.
Hi – I’ve just released an update to the bugzilla reports extension for MediaWiki – see BugzillaReports @ MediaWiki. We use this internally and find it very useful for generating slice and dice reports of our activities. Feel free to give it a try and contact me if you have any questions.
UPDATE: You can report issues or raise enhancements @ http://code.google.com/p/bugzillareports/issues/list
I just discovered the benefits of creating custom Firefox search plugins the other day, having hooked up a Firefox search plugin for our internal MediaWiki which I shared with my colleagues. The search plugin integrates with the MediaWiki apis which can be used to provide suggestions. This suggestion functionality is pretty neat, since it allows you to quickly scan what pages are available on your wiki (without hitting the search button) and then select what you’re looking to go directly to your chosen page. A quick click-to-install link can also be provided for your team. Follow the steps below to find out how.
- Create a base-64 encoded 16×16 pixel image to appear next to the search engine input box so it’s always clear which search engine you’re searching. You can use an online utility such as Antonin Foller’s
- Create an OpenSearch description XML file and include your base-64 encoded image, e.g.
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/"
xmlns:moz="http://www.mozilla.org/2006/browser/search/">
<ShortName>my wiki</ShortName>
<Description>my wiki</Description>
<Image width="16" height="16">data:image/x-icon;base64,
(put your base 64 encoded image here)
</Image>
<Developer>Ian Homer for bemoko</Developer>
<InputEncoding>UTF-8</InputEncoding>
<Url type="text/html" method="get"
template="http://wiki/index.php?title=Special:Search&search={searchTerms}"/>
<Url type="application/x-suggestions+json"
template="http://wiki/api.php?action=opensearch&search={searchTerms}"/>
<moz:SearchForm>http://wiki</moz:SearchForm>
<moz:UpdateInterval>8</moz:UpdateInterval>
</OpenSearchDescription>
where http://wiki is the base URL to your media wiki installation.
- Host this description XML file on a server of your chosing.
- Create and host an HTML page that links to the absolute URL of your hosted description XML file. The link must use the AddSearchProvider JavaScript API as demonstrated below.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" dir="ltr">
<head>
<title>search engine loader</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<script type="text/javascript">
function addEngine(engineURL) {
if (window.external && ("AddSearchProvider" in window.external)) {
window.external.AddSearchProvider(engineURL);
return false;
} else {
alert(error_opensearch_unsupported);
return true;
}
}
</script>
</head>
<body>
<div id="wrapper">
<a onclick="return addEngine('http://host/searchmywiki.xml')">
install my wiki search engine plugin
</a>
</div>
<body>
</html>
- Open this HTML file in Firefox and click on the link to install the plugin … and of course circulate the URL to this HTML page with your colleagues so they can do the same.
… now even less excuses for people to say that they “can’t find it on the wiki”.
I’m a big fan of wikis and MediaWiki is my flavour. It’s a rock solid platform and has never let me down. I’ve picked up lots of best practices, patterns, tips & tricks and little hacks over the past few years and I’ll be sharing them with you over the next few months on this blog. There’s no better place to start things rolling than with a list of my favourite extensions. Extensions are what bring the MediaWiki to life and really allow you to take control of your Wiki content:
- Semantic MediaWiki has to come top of this list. To me it is the killer-extension on MediaWiki today. By assigning meta data to your pages you can really slice and dice your content. You can put your content modelling hat on and generate dynamic content, generating pages from contact lists of your team to glossaries to page tagging. It ensures that you only need to enter content once, allows you create different views of the system and really get to grips your content. All that you’d expect from a Semantic web. To top it off the Semantic Media Wiki team have slowly but surely reached the v1 of the extension over the past year or so, maintaining a high level of quality at all times.
- Next up is InputBox. Very simple, but elegant extension that allows you to create a new page from a template. If you need to create many pages of the same form, such as system requirements, then create a template from which you can spin off all the pages. Great for encouraging a standard page structure and makes it a lot easier for new comers to the wiki to follow a prescribed work-flow.
- Next 4 are some core function libraries that you’ll benefit from on a day-to-day basis as you create ever more sophisticated templates. StringFunctions gives you string replace and substring functions among others.
- ParserFunctions gives you such functions as if, ifeq and switch.
- VariableExtensions allows you access previously set variables, allowing you to do counters or interact between templates.
- I know I shouldn’t, but DynamicFunctions does give you that extra control of URL parameters. Dirty and hacky at times, but it has allowed me to go that extra distance at time, when it’s the last resort.
- You should always reference your sources. To help you manage your references and collect them all up nicely up at the bottom of the page try Cite.
- Gadgets looks really promising by allowing a little customisation / go-faster stripes on your wiki. A gadget is essentially a JavaScript and/or CSS which is applied to your page. Sysop users can install new gadgets using the standard wiki interface and then any user can choose (via a preferences edit) which gadgets they want to. There’s many out there and the list seems to be growing all the time. I said this is promising, because although I found a few interesting such as the pop-up preview on hover over links or WY(sort of)SIWYG, I couldn’t find any that really assisted on a day-to-day basis and, more importantly, enough to recommend to users of the wikis I manage. I suspect this’ll change soon as I discover new and improved gadgets.
- Eye-candy is good – especially when it makes things more usable. This is what SyntaxHighlight does. It brings those code blocks to life with some decent colouring, making them oh-so-much clearer. And what a fantastic list of supported languages.
- I leave Semantic Forms to last to end on a high, no means because I value it any less that of the ones above. Semantic Forms allows you to create forms for your data entry. With this in place users don’t even need to write any more wiki text to create pages – in fact you can enforce that they don’t so you really have control over how specific page types get managed. It integrates so well with the Semantic Media Wiki it surprises you. For example it can autocomplete text fields with a slick JavaScript module that lists best fit data as you type. This extension essentially wraps up a lot of the extensions mentioned above to improve the UI and protect the normal user from the sometimes cryptic wiki language.
One thing that always amazes me is the quality of both the MediaWiki core and the extensions provided by the community. It’s always a pleasure to come to either install a MediaWiki system, install extensions or upgrade the stack. It all just works and when I slip up (as I occasionally do) – it invariably tells me what I’ve done and what I need to do.
I’ll continue with this MediaWiki series in a few weeks time. Please let me know if there’s any particular areas you’d like me to cover or perhaps any use cases or samples you’d like me to run through.