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, so instead I prefer to put useful bits of info I want to share on my user page here.

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, especially when the bug is actually an  undocumented feature. I am always trying to improve my bug hunting skills and methods.

On 2012-07-03 04:56:24 UTC I submitted a patch for a critical bug that had the potential to bring down a server, in 38136. My patch was applied and marked as fixed on 2012-10-17 16:27:59 UTC. That was my first patch, and I hope to find more opportunities to fix the bugs I find. Maybe that will help to avoid being "shot" for an unwelcome contribution of bug reports and workaround solutions.

Bug hunter appreciation day
Bug hunters take on the most difficult and frustrating jobs, but they seldom get thanked for it. Grief is what they get. The excerpts below are originally from Reddit, A bug hunter amongst programmers is like a Jew amongst Nazis: How should they react to bug reports?

John T. Haller:


 * "Badon ... blah blah blah ... troubleshooting ... blah blah blah ... 32 hours ... blah blah blah ... IE didn't function ... blah blah blah ... complaining ... blah blah blah ... politely asked ... blah blah blah ... proved my point ... blah blah blah ... right?"

badon:


 * "blah blah blah ... I solved the problem ... blah blah blah ... Did you sleep well?"

Mediawiki etc.

 * I did some very minor bug fixes to the config for Extension:JSBreadCrumbs.
 * Bugs and fixes
 * Category:MediaWiki Releases
 * User:Badon/Extension:Semantic_MediaWiki/Manual
 * Markup spec
 * Help:Links
 * Help:Images
 * Help:Contents
 * Manual:Parameters to index.php
 * m:Help:List (Needs to be moved to Help:Lists)
 * Project:WikiProject SysAdmins
 * Project:Help
 * Manual:Collapsible elements
 * RL/DM
 * http://test.wikipedia.org/wiki/User:Krinkle/CollapsingTestpageMw
 * Automatic SMW refreshData, [ SMW query management and smart updates]
 * User:Nischayn22/Gsoc
 * http://greensmw.wordpress.com/
 * http://semantic-mediawiki.org/wiki/SQLStore_Update
 * How to become a MediaWiki hacker

Support

 * Web chat
 * WikiMedia mailing lists
 * Project:Support_desk
 * MediaWiki commercial support

Localization

 * Extension:Translate
 * Help:Magic_words

Image annotation

 * Google search: image annotator
 * W3C image annotation
 * Kanzaki Image Annotator
 * Lupo's ImageAnnotator
 * fotonotes.net

Data integrity

 * Data corruption
 * ZFS
 * PCBSD (with very easy ZFS!)
 * Parchive
 * MultiPar

Miscellaneous

 * David Edward Hughes, Inventor of radio
 * TorChat

Extension:ReplaceText known issues
Yaron Koren has been described as the "rock star" of MediaWiki developers due to the enormous quantity of code he writes, but he very often dislikes the contributions of others in his projects, especially when they address security issues or inadequate documentation. So, this improved documentation about the bug testing work several of us did for security issues in Extension:ReplaceText (version 0.9.5, November 2012) has to be made available here on my user page, instead of Yaron's extension page. One of us already submitted a modified SpecialReplaceText.php to fix the most serious of these issues, so this documentation could become outdated when Yaron releases a future version.

If you need something fixed immediately, please support Yaron's generous gifts to the MediaWiki community by hiring him and/or his team at his company WikiWorks. Your support will benefit all of us who use Yaron's extensions. Note that this should not be construed as an endorsement, because I have not used WikiWorks myself yet. For more information about supporting MediaWiki developers, see User:Badon and User:Badon#Giving gifts to Project?, and a list of other commercial support options.

UPDATE 2013 January 22:

I tested and produced a patch that partially works for getting around these problems with Replace Text 0.9.6. I also uploaded my slightly edited version of Woozle's SpecialReplaceText.php for people who just want to replace the file and get back up and running until Replace Text can be more properly fixed.

Large replacements taking a long time
The replacement actions themselves are structured as MediaWiki "jobs", to ensure that the system is not overloaded if the user wants to do many at the same time. This means that a large set of replacements will not be done immediately, and may take minutes, hours or even longer to complete. Jobs get activated every time a page is viewed on the wiki; to speed up the process (or slow it down), you change the number of jobs run when a page is viewed; the default is 1. For information on how to change it, see the $wgJobRunRate page.

Large replacements error message
If you have a large number of replacements, some of them may not get done; or you may see an error message that reads "You must select at least one namespace". See: 38170, 43472. In both cases, that's due to security features of PHP and the Suhosin extension that limit the number of form inputs to reduce the effectiveness of some types of DoS attacks. This can be worked around by temporarily compromising those security features. Restore them immediately when you're done with using Replace Text. You do not need to wait for the jobs to complete. Here are the workarounds:


 * The PHP setting max_input_vars (available since PHP 5.3.9) typically defaults to limit the number of replacements to 1000. You can try setting this parameter to a number larger than the number of replacements you want to do, like 3000, for example.
 * If you have the Suhosin PHP extension installed on your server, you can try temporarily disabling it while you do the replacements.
 * If you have Suhosin installed but don't want to disable it, you can simply increase the value of the variables suhosin.post.max_vars and suhosin.request.max_vars.

Suppressing redirects when changing page names
In order for redirects not to be created on page moves, i.e. if the "Save the old titles as redirects to the new titles" checkbox is unchecked, you will have to give the relevant user the 'suppressredirect' permission. Assuming you've given the 'replacetext' permission only to sysops, you would need to add the following to LocalSettings.php:

Compressed revisions are not searchable
If your revisions are compressed (that is, if $wgCompressRevisions is enabled in LocalSettings.php) then ReplaceText will not work, because it makes use of SQL queries that can't search compressed text.

Widgets
Extension:Widgets is a very powerful extension that's simple to use, and thoroughly replaces the obsolete Extension:RawMsg. Here's a few widgets I made that you can use on your own wiki with the Widgets extension installed. It is very useful when you want to show someone how to do something on your wiki.

UPDATE 2013 Febuary 03:

It appears Extension:WidgetsFramework is well on its way to resolving most or all of the problems with Extension:Widgets. I particularly like the benevolent community-centered approach used by the friendly developers of that extension. I have never experienced any kind of snide arrogance or abuse from them, so I'm eager to give it a try. With their leadership, I'm hoping to be able to contribute to their project without having my work alienated to my user page anymore. Hallelujah!

Google translate widget
 This widget enables Google translate tools. You may use the widget like this:

&lt;pre&gt;

&lt;/pre&gt;

 function googleTranslateElementInit { new google.translate.TranslateElement({   pageLanguage: 'en',    multilanguagePage: true,    layout: google.translate.TranslateElement.InlineLayout.SIMPLE  }, 'google_translate_element'); } 

It's not required, but if you add the following to your MediaWiki:Common.css, your widget will display nicely on the right side of wiki pages, on the same line as the page H1 title header thing:

/* For the Widget:Google_translate in MediaWiki:Sitenotice */
 * 1) siteNotice { height:0; }
 * 2) localNotice { height:0; margin-bottom:0; }
 * 3) siteNotice p { margin:0; padding:0; } /* Clean easy-to-read wiki formatting while producing superfluous tags WITHOUT extra spacing in the sitenotice */

/* For the Widget:Google_translate in MediaWiki:Sitenotice */
 * 1) google_translate_element { text-align:right; position:relative; top:-0.67em; }

Twiddla widget
 This widget allows you to add a Twiddla meeting to a page. [ Edit the page] to see the widget text. You may use the widget like this:

&lt;pre&gt;

&lt;/pre&gt;



HTML5 video and subtitles widget
Widgets are usually pretty easy to make, but this one was a challenge. If you use this widget, I would be delighted to hear about it. It features not only video, but also user-entered multi-lingual subtitling. It's annotation for video! A big "Thank You!" to everyone who made this widget possible. You know who you are.

UPDATE: This widget does not work as well as I had hoped. I have discovered several flaws in the subtitling that sometimes cause other things to not work. I recommend ditching this widget in favor of the YouTube widget for now.

 This widget enables HTML5 video and audio using the html5media JavaScript component. This widget also optionally enables Universal Subtitles using the US Amara Widgetizer. You may use the widget like this:

&lt;pre&gt;

&lt;/pre&gt;


 * url is the URL of the video, and is the only required parameter.
 * width and height are optional video size dimensions. width=640 and height=360 is the default.
 * poster is an optional image URL to display while the video is loading. A video frame is ideal.
 * controls is an optional parameter that will show controls (play, pause, volume, etc) immediately upon load, before playback begins, when the value is yes, which is the the default value if not specified. Use the value no not show controls.
 * preload is an optional parameter that will preload the video immediately upon load, before playback begins, when the value is auto. If not specified, the value none will be used to not preload. The value metadata will only preload metadata. Note that not preloading the video will cause the subtitlesforall parameter to not take effect until the user begins playback.
 * subtitlesforall will enable subtitles for all videos on a page when the value is yes. Note that not preloading the video will cause the subtitlesforall parameter to not take effect until the user begins playback.

Recommended widths and heights
height=215 height=236 height=360 height=450 height=576 height=300 height=315 height=480 height=600 height=768
 * For 16:9 wide screen format videos
 * width=400
 * width=420
 * width=640
 * width=800
 * width=1024
 * For 4:3 monitor format videos
 * width=400
 * width=420
 * width=640
 * width=800
 * width=1024

Recommended software

 * Screen recording
 * http://camstudio.org/
 * http://www.hyperionics.com/hc/downloads.asp
 * Video format encoding
 * http://www.mirovideoconverter.com/ - To convert to WebM format.

How to setup incompatible browsers to view WebM video
Browser support for HTML5 WebM video is now widespread. Only a few browsers cannot display HTML5 WebM video. The most notable browsers are Microsoft Internet Explorer (IE or MSIE, including mobile versions) and Apple Mac Safari (including iPad, iPhone, etc, versions). However, most of those web browsers can be made to work by installing a plugin to enable HTML5 WebM video.

How to setup your HTTP server for the correct WebM MIME type

 * http://www.webcoder.de/2010/06/04/how-to-configure-your-webserver-for-webm-video-and-audio-files/

Uploading
Upload your videos at the Special:Upload page.

Subtitling best practices

 * http://blog.universalsubtitles.org/2011/08/09/best-practices-for-subtitling-videos/

Future ideas

 * https://www.google.com/search?q=subtitles+html5+video - There are other subtitlings options that should be explored and further developed, that do not rely on third parties like Amara Universal Subtitles. They could allow the wiki to host the subtitles after they're created using US Amara tools (or other tools), and they could then be translated on-wiki using Extension:Translate.

 <script src="http://api.html5media.info/1.1.4/html5media.min.js"> <video style="background-color:#000000;" src="" width="" height="" poster="" controls preload="" >

YouTube widget
<pre style="white-space:pre-wrap;"> This widget allows you to add the YouTube video player to a page. [ Edit the page] to see the widget text. You may use the widget like this:

&lt;pre&gt;

&lt;/pre&gt;


 * id is the YouTube video ID, taken from the last part of the YouTube URL, like this (colored red ): http://www.youtube.com/watch?v= DWef69ItVrU
 * width and height are optional video size dimensions. width=420 and height=315 is the default.
 * showmore will suggest more videos if the value is yes. If not specified, the default is no.
 * subtitlesforall will enable subtitles for all compatible videos on a page when the value is yes. YouTube videos will not be affected by other videos if the value is not given or is no (the default).
 * https://developers.google.com/youtube/player_parameters

<script type="text/javascript" src="http://s3.www.universalsubtitles.org/js/unisubs-widgetizer.js"> <param name="movie" value="http://www.youtube.com/v/?version=3&amp;hl=en_US&amp;rel=0"> <param name="allowFullScreen" value="true"> <param name="allowscriptaccess" value="always"> <embed src="http://www.youtube.com/v/?version=3&amp;hl=en_US&amp;rel=0" type="application/x-shockwave-flash" width="" height="" allowscriptaccess="always" allowfullscreen="true">  <iframe width="" height="" src="http://www.youtube.com/embed/?rel=0" frameborder="0" allowfullscreen>

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. Here are some hosting suggestions:
 * 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.
 * If you can't get ZFS, consider at least using MultiPar to protect your files. Read on Wikipedia about MultiPar's underlying Parchive technology.
 * 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:DynamicFunctions
 * Extension:ReplaceText
 * Extension:MyVariables
 * Extension:CSS

Other extensions

 * Extension:Semantic MediaWiki
 * Extension:Semantic Forms
 * Extension:Semantic Maps
 * Extension:Labeled section transclusion

Advanced MediaWiki programming tips

 * Whitespace is the enemy. If you can't find it when it's screwing something up, it's because they're wascally whitespace wabbits.
 * Whitespace wabbits like this always bite me at first, but I hunt them down later:

<pre style="white-space:normal;">


 * 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, like this:


 * To get this, where you can see two  next to each other:

This%20line%20is%20perfect%20except%20for%202%20spaces%20before%20the%20last%20%20word }}


 * You can also persuade the web browser to preserve whitespace using CSS, so you can see where the problems are. Use the CSS white space properties to reveal them.
 * 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  paragraph for each 2 newlines), like this:


 * Do not use  inside   if you are going to test it later with an , 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 's within nested   tests than to place your   statements inside a  . It makes debugging mysterious whitespace much easier. Like this:

Distributed template job queue management
When a high-usage template is edited, it can dominate the MediaWiki job queue for days or weeks, sometimes more. The simple solution to this problem is to create several identical versions of the same template, each with a different number. Then, when edits need to be made, the template changes can be rolled out gradually to all the identical templates. While the job queue is processing each numbered template, other jobs can get into the queue before the next template is edited. This also improves testing of template changes, because errors do not affect the entire site, and multiple changes to the same template do not further clog the job queue.

About 30 numbered, identical templates can be used for MediaWiki sites up to about the 100,000 page level. You can use Extension:ReplaceText to find and replace the "main" template with a randomly numbered identical template, like this:


 * Find:
 * Replace:

See also: Bug 37570: Enable parser functions and magic words in Semantic Forms template definition to allow distributed template job queue management.

I have some fancy distributed template management code that I might be willing to share if you ask me about it. I don't want to release it under an open source license yet, until I'm sure it will get used by someone other than direct competitors to my own sites. In other words, it shouldn't be hard to persuade me to release it, if you ask.

The ultimate solution to every difficult problem
If you're having no success in solving a difficult problem, you can keep pathetically hacking away at it, or you can put down your psychological torture devices and help someone else solve their problems. Every time I get stuck on something because:


 * I don't have enough skills.
 * I don't have enough experience.
 * I don't have enough knowledge.
 * I've spent too much time coding and my brain is fried.
 * All of the above.

I always find the solution after spending time helping other people solve their problems. Why? Well, for starters, even if I know exactly how to solve the problem, I usually still need to freshen my knowledge by re-reading documentation and doing some easy searches. After a few minutes to a few days of answering questions on the mailing lists, forums, talk pages, and IRC, most of the time I have read and written enough documentation (the answer to someone's question) to stumble upon a fresh idea for solving my own issues.

Whenever I can't sleep at night because some problem is challenging me, I find peace and inspiration by helping others. That works for me, and maybe it will work for you too.

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 wish-list, 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 and helpful 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.

See also: WMF Benefactors.