User:Badon



I do mostly testing, bug hunting, and documentation writing. I have a particular interest in doing it for Semantic MediaWiki and related extensions, but I jump in anywhere I feel I can be helpful. I usually avoid documentation writing for SMW and related extensions, except on my user page here, where I like to add useful bits of info I want to share.

I have officially reported 75 bugs as of January 1, 2012 (and a few more unofficially *). 56 of them are either FIXED or still open, and the rest are DUPLICATE, WONTFIX, or LATER. That gives me a 75% "usefulness" rate in my bug reports, with the remaining 25% often resulting in improved documentation (when the bug is actually an undocumented feature). I am always trying to improve my bug hunting skills and methods.

Here's some other things I care about:


 * Bugs and fixes
 * Category:MediaWiki Releases
 * User:Badon/Extension:Semantic_MediaWiki/Manual
 * MediaWiki commercial support
 * WikiMedia mailing lists
 * Markup spec
 * Help:Links
 * Help:Images
 * m:Help:List (Needs to be moved to Help:Lists)

Semantic MediaWiki 1.7 undocumented breaking changes
The official Semantic MediaWiki documentation is obsolete. In fact, the official SMW site is still running an obsolete version of SMW. Documented below are some crucial differences that upgraders will need in moving from SMW 1.6.x to SMW 1.7.x.

#ask query for page names
If you upgraded to Semantic MediaWiki 1.7 and suddenly nothing works on your site, it is because there were undocumented breaking changes made to the #ask query syntax. In earlier versions, this used to produce page names:

Now it produces a table with the page names repeated such that there are two columns containing the same page name data, that looks like this:

These queries now produce the same output, identical to the older behavior of SMW prior to 1.7 that would be expected from the first example where only the page names were output:

I'm still not sure if that intentional, or is a bug, but I think it is intentional. The new behavior seems reasonable, and simpler, even though it's a frustrating breaking change that is undocumented, not backwards compatible, and requires site-wide changes to fix broken queries. If this was intentional, it should definitely be documented very prominently so users will know in advance that upgrading will break older queries, and explain what they need to change to fix the broken queries so they will display as intended with SMW 1.7.

count format
This used to produce 0 if there were no results:

Now, it produces nothing instead of zero. You can get a zero this way (using Extension:Variables for #vardefine):

Then, you have a variable that contains the number 0 if your query has no results. The reason you use #vardefine is so you only need to run the query once. Without it, you may need to run it multiple times, every time you want to use the number of results.

However, when your query is on a property, it will still give you 0 like it always has, even if the property does not exist on your wiki:

This is inconsistent behavior, and is probably a bug, described here: count format not producing 0 on non-existing category queries

#ask multiple property comma delimited list format
This used to produce a comma delimited list of values if a property was specified more than once, so that it has more than one value:

Some property::value 1 Some property::value 2

The output would look like this:

value 1, value 2

Now it produces a table with the multiple properties listed in a column, like this:

These queries now produce the same output as they did with the older versions of SMW:

The output will look like this:

value 1, value 2

Note that there is a serious bug that inserts 2 invisible spaces after the comma, instead of just one that you will see in your web browser when you run the queries above on a wiki that has SMW installed. The extra space is invisible because web browsers do not display more than one space at a time - all other spaces are hidden. If you try to do comparison operations, you will get incorrect results. The bug is described in detail here:

https://bugzilla.wikimedia.org/show_bug.cgi?id=33478

Bug hunting tips


This section may evolve into a full guide for debugging. For now, he's a few tips:


 * Check to make sure you haven't accidentally pasted the wrong text into a page. Semantic Forms pages and template pages getting swapped can produce errors that take down the wiki (until the code prevents those error conditions).
 * Check your clipboard manager's hotkey settings (if you have one) to make sure that you're not accidentally triggering hotkey functions that can be screwing up your pastes.
 * Use code inspectors like FireFox FireBug, Opera Dragonfly, or Chrome Inspector, to look at what HTML, CSS, JS, etc is being generated on a wiki page that isn't behaving like you think it should.
 * Use some code to automatically show an error message if you paste code into the wrong page by accident, like this (with Parser functions):


 * Strip down the problem code or circumstance until the bug goes away. That will be your bug demo.
 * If you're struggling with isolating the bug, try setting up a fresh MediaWiki install with the bare minimum of extensions and other "accessories" so you can reproduce the bug with minimum confusion.
 * Try running your test MediaWiki on a separate host from your usual host, so you can eliminate the possibility of a hosting quirk as being the source of your bug. I recommend No Support Linux Hosting for a really cheap hosting solution that makes it easy to set up as many as you want, as long as you're skilled enough to not need support for setting up a website.
 * Make sure common data corruption is not the problem by doing your production hosting on a ZFS system. I think nearly all mysterious failures that can't be traced to a bug are caused by normal data corruption. Data corruption is something that I hope is one day not considered normal anymore. No Support Linux Hosting virtualizes their Linux systems on top of a ZFS storage backbone, so you can use ZFS with Linux even though Linux doesn't support ZFS yet. Another recommendation for ZFS hosting is Entic.net, with very good support and Cartika, which I haven't used yet, but I would like to. All of my recommended hosts will not cause "bugs" to suddenly appear due to data corruption. You can also set up your own ZFS hosting with FreeBSD, which has software support that's almost as good as Linux, and ZFS support that's almost as good as Solaris.
 * Finally, if you're sure you've found a bug, report it.

Advanced MediaWiki programming toolkit

 * Help:Magic words
 * Extension:Variables
 * Extension:ParserFunctions
 * Extension:StringFunctions
 * Extension:Arrays
 * Extension:HashTables
 * Extension:Loops
 * Extension:ExpandTemplates
 * Extension:ReplaceText
 * Extension:MyVariables
 * Extension:CSS

Other extensions

 * Extension:Semantic MediaWiki
 * Extension:Semantic Forms
 * Extension:Semantic Maps

Advanced MediaWiki programming tips

 * Whitespace is the enemy.
 * If you can't get rid of the whitespace that's screwing up your wiki pages (especially in tables), put this in your MediaWiki:Common.css to make most of the annoying whitespace "disappear":

.wikitable p { margin:0; padding:0; }


 * Since MediaWiki and web browsers do not show all whitespace characters, finding extra whitespace can be done with the urlencode magic word.
 * Use HTML lists and tables instead of wiki lists and tables. It makes formatting much easier, and less fragile.
 * Use at the end of lines to prevent the buildup of empty wiki paragraphs (1 for each 2 newlines), like this:


 * Do not use inside #vardefine if you are going to test it with an #if, because in your variables will cause them to always pass the test. Like this:


 * is not needed inside functions that do not directly or indirectly output anything, like in string manipulation code.
 * It is better to use many #vardefines within nested #if tests than to place your #if statements inside a #vardefine. It makes debugging mysterious whitespace much easier. Like this:

Giving gifts


If you are an awesome MediaWiki helper, please put your Amazon wishlist on your user page. Note that you will not be able to stay anonymous if you do that. If you want to remain anonymous, "printable" eBay gift certificate codes can be emailed to you. If you're a recipient of help from an awesome MediWiki helper, here's where you go to get an eBay gift certificate code to show your appreciation:

https://www.paypal.com/cgi-bin/webscr?cmd=_ebay-gift-certificate

Be sure to select the option:


 * I will print out the gift certificate and deliver it myself.

And then select the amount you want to give. Don't enter in anything else.

Buying stuff for people on their Amazon wishlist, and sending "printable" eBay gift certificate codes, are both anonymous for the sender too! I recommend that you stay anonymous when sending people gifts for several reasons:


 * 1) Everyone loves a mystery
 * 2) It does not create any expectations of future gift-giving
 * 3) It encourages everyone to be polite to each other, since there's no way to know who's sending the gifts and who isn't

That last one is the most important. Even if only 2 or 3 people are sending gifts, as long as they do it anonymously, it makes the MediaWiki community much more friendly for every one of the thousands of people involved.