Jump to content

User:Badon

From mediawiki.org
This user is a proud MediaWiki extension developer and participant in WikiProject Extensions.
This user is an official member of the MediaWiki Bug Squad.
This user was an editor on MediaWiki.org.

I am an unpaid volunteer for the Wikimedia Foundation, and I do mostly software 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, LATER, or buried forever. That gives me a 75% "usefulness" rate[1] in my bug reports, with the remaining 25%[2] often resulting in improved documentation, especially when the bug[3] is actually an undocumented feature. I am always trying to improve my bug hunting skills and methods. In the years since 2012, I have become much more confident that I can find bugs, isolate them, and report them.

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 bugzilla: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.

I also sometimes do bug hunting for the Tor Project, TrueOS (formerly known as PC-BSD), Corz checksum, CorzSpaZio, MultiPar, HexChat, Notepad++, pfSense, Jitbit Macro Recorder, Deluge BitTorrent Client, TypeMatrix keyboards (hardware bug testing), Hot Alarm Clock, Proxifier, Simple Machines Forum (SMF), Reddit, GOG.com, tSIP, and many, many others.

I am the founder and project lead for the Coin Compendium (CC) project (blog)) and livebusinesschat.com (LBC) (blog).

Unfortunately, I have gradually become largely inactive on WMF projects due to the difficulty of playing Whac-A-Mole with the endless granting and revoking of IPBE's on every WMF site, including Wikipedia, despite having a global IPBE that is intended to work everywhere. I literally had to spend more effort begging for individual IPBE's at each individual WMF project than actually contributing, and by the time the IPBE gets granted (AGAIN!!!!!!), I've forgotten what it was I wanted to contribute, and other IPBE's have been revoked and require more begging. Occasionally I try to contribute something, but then I see that I'm still blocked, and then I remember why I quit trying to contribute.

Lately (2016, 2017, and 2018) I have been enjoying the Reddit community, especially the parts of it for coin collectors. I'm particularly proud of these subreddits and multireddits:

Magnetic field lines don't exist

[edit]

Stop teaching this to children, because it's wrong.

Remember children, there is no such thing as a "magnetic field line". Anyone who uses that phrase does not know what they're talking about. Magnetic fields are continuous fields. There are no lines.

The idea that magnetic fields have lines comes from the childhood demonstration of a magnet under a sheet of paper with iron filings on it. The iron filings bunch together and concentrate the magnetic field in a "line" pattern in the iron. The "lines" would not exist without the iron influencing it.

This gross misunderstanding by the finest minds of the 21st century is almost identical to mistaking the rings of Saturn as "gravity lines". It's wrong. It's absurd.

So, yes, it's literally children who learned this wrong in childhood, and as adults they keep repeating it (wrong) while they're busy giving each other PhD's.

Hidden CAPTCHA's

[edit]

See my video, with explanation in the text below it:

Hidden CAPTCHA's are the most common site-breaking bugs on the internet

Famous photo is fake

[edit]

The photo above is praised in Wikipedia by people who don't know it's a staged fake:

This is a featured picture, which means that members of the community have identified it as one of the finest images on the English Wikipedia, adding significantly to its accompanying article.

And:

This image was selected as picture of the day on Wikimedia Commons for 13 November 2006. It was captioned as follows:

English: Lathe operator machining parts for transport planes at the Consolidated Aircraft Corporation plant, Fort Worth, USA (1942).

This photo is obviously a staged fake, and the woman isn't really manufacturing anything. Reasons:

  1. No eye protection! No eye protection!
  2. The scroll-chuck does not have the jaws installed, and the scrolls are visible.
  3. No chuck jaws means no part being worked.
  4. The center of the chuck is visible, but there's nothing there.
  5. Low light requires a long exposure, but there is no evidence that the chuck is spinning.
  6. If there were a really small, nearly invisible part going through the center of the spindle and clamped down with a small collet chuck (unlikely when a massive scroll chuck is already installed), it would require such high turning speeds that even a fast flash would not be able to conceal all evidence of motion. Once again, this woman is not making anything in this photo.
  7. The woman is posing to appear to be feeding the turret head, but there are no tools installed in the turret.
  8. There is no measurement equipment visible. No dial indicators, no calipers, no micrometers. She's allegedly making aircraft parts, which typically have among the most stringent tolerance requirements. With no measurement equipment, she couldn't be making anything that must be fitted to other parts. Basically, that means she's limited to paperweights and door stops (etc).
  9. The number of tooling mounts attached to the machine seems excessive. They're so tightly packed on there you wouldn't be able to see the tooling and workpiece very well. That's convenient if you want to distract from the fact that there is no tooling or workpiece, nor even chuck jaws installed.
  10. The tooling mounts are all crowded in the area of the chuck. That might be normal if you're working very, very small parts, but those tooling mounts are massive, and the scroll chuck is massive too. So why is everything moved so close to be crowding the workpiece area? There's only one other reason: That's the standard position to move all of the lathe's components when the lathe is in storage, because it covers the machine's ways to keep them in contact with oilt, which protects them from dust and rust when the machine goes unused for a long time. It also prevents the heavy machine from sagging and distorting the shape of the ways, which would at least reduce the accuracy of the machine, and could also possibly cause irreparable damage if the machine settles into a non-neutral position with stresses in the frame.
  11. The woman is posing to appear to be feeding the turret head, and she should be watching the cutting process at the chuck, but she is instead looking down into space, past the wrenches in front of her and behind the turret head, NOT at the chuck. If she were looking at the chuck or workpiece in the position she is standing in, much less of her face would be visible, and the photo wouldn't be so nice.
  12. The woman's clothing is filthy, but lathe machinists don't normally get that dirty, even in the worst cases.
  13. The woman tied her apron in front, instead of the back. That's how dumb people, dead people, and people who want to die by getting pulled into a machine will tie it. Still, I've seen some people do it that way if they're not smart enough to tie behind their backs. They're not very good machinists, either.
  14. Her hat is resting gently on top of her perfectly groomed hair. If she leaned in to inspect the workpiece, it would slip off toward the left side.
  15. Normally the bill of the hat would be backwards, so the machinist can lean in to examine the dial, spindle, or vernier scales on calipers or micrometer equipment. It would be in the way facing forward, and machinists don't normally wear their hats that way. I'm not sure why the hat is even in the photo, let alone posed wrong. Maybe the photographer liked the color balance of the hat with her skin color, and so decided to have her wear it instead of dispensing it for the duration of the photoshoot. She probably wears a hat (or something similar) for safety, to keep her hair away from the machine, but a baseball-style hat would have to be backwards to be compatible with the job. Maybe the photographer just thought it looked classier facing forward, but still added enough of the "grungy" look he was trying to get, so he decided to have her wear it in an unnatural pose?
  16. The hat looks flawlessly perfect, like it is new. She wouldn't be able to keep it that clean with all that filth all over her. Even a real machinist that doesn't get so filthy would not be able to keep a hat 100% spotless like her hat.
  17. Oily grime is conspicuously placed on the top of her right arm, but there's nothing on her left arm. Most of the mess on a lathe comes from cutting oil being flung from a spinning part, close to the chuck, ON THE LEFT. If she got dirty at all, it would get the top of her LEFT arm dirty, NOT the top of her right arm.
  18. Her shirt DOES have a vertical string of droplets in a pattern of stains typical for a lathe machinist on the lower part of her left sleeve, but it is old and dried, as would be expected for an experienced lathe machinist. If that much dirt and staining on her clothing and skin were from real work happening at the time of the photograph, it would be impossible to keep her left arm as clean as it is. More likely, it took many years of abuse to get the shirt that dirty, and I'm guessing she was told not to wash it for a while before posing for the photo (assuming she's a real machinist, and not just a posing model).
  19. For a lathe machinist, if she got dirty at all (other than hands), typically the top of her left arm would be dirty, and the bottom much more clean. Then, the top of her right arm would be clean, and the bottom dirty. Put your hands out in front of you like you're holding a basketball (positioned for operating lathe controls), and imagine the oil droplets coming at you from the chuck on your left. The dirt on this woman's arms is not consistent with someone who got dirty working on a lathe.
  20. There are no chips in her hair, and no oil on her face or neck that would be natural for the amount of filth on her clothes and the top of her right arm. If her grime were authentic (maybe from working a horizontal mill before posing for the lathe photo), she would have some speckles of grime in those places too.
  21. The lathe is covered in dust. It hasn't been turned on in months. There's so much dust on it, I would guess it has been at least a year since it has been operated.
  22. An oily lathe that gets a worker as dirty as she is would require frequent wipe-downs. Even if that huge quantity of dust were deposited (from a neighboring building demolition?} a day ago, all dust is abrasive and it damages the fine workings of the machine, so rule #1 is to wipe down all dust, debris, and leaking oil before operating the lathe. Once again, this machine is not actually operating in the photo, and it probably hasn't been turned in many months.
  23. If there were enough oil on this lathe to get her that dirty, there would be enough oil to prevent the machine from rusting during normal use. But no, it's covered in light rust spots. This machine hasn't been turned on in so many months that the change in air temperature from the day-night cycle and advancing seasons has caused sufficient moisture to condense on the steel that it penetrated the ubiquitous coating of oil and caused some rust.
  24. Does the top of the turret have a shimmering reflective puddle of oil on it? I see a reflection of one of the jaw channels in the chuck, and what looks like a long yellow reflection from the photographer's lighting equipment. There's another oil puddle next to one of the bolts in the dusty area near the lower right corner of the photo. When a machine sits idle for many months, oil in the workings can seep out and pool. It's a fire hazard and makes a drippy, smokey mess when you turn the machine on, so once again, it appears this machine has been idle in storage for many months.
  25. Other than the dust, rust, and pooling oil leaks, this lathe is flawlessly clean. It has obviously been prepped for storage or maintenance. It could not possibly remain that clean if it were actually in daily use.

Here is the same person from the left side, in the same scene, but located at the back end of the lathe, farthest from the chuck and workpiece:

  1. Magically appearing grime on the top of her left arm (facing the camera) that wasn't there in the other photo.
  2. The hat is fixed so it's not tilted anymore.
  3. Still no filth on the bottom of her right arm.
  4. Notice that the left side of her apron is dirtier than the right side. The apron is authentic because that's the side closest to the spinning chuck and workpiece, which fling cutting fluid around. However, her clothing is still unnaturally dirty.

Here is another photo that shows the same model machine, from the same photographer, in the same facility, at the same time (October 1942):

  1. Still no eye protection!
  2. Same hat again, with the same weird tilt.
  3. No excessive filth smeared on her skin and clothing.
  4. Bad lighting.
  5. No rust or dust on the machine.
  6. Functional tooling installed in the turret.
  7. Machine actually operating.

Could it be that the photographer was unsatisfied with the above photo, and decided to stage a scene to get a more attractive result? The company couldn't shut down functioning machines and delay the war effort just for a photo, but maybe they had one out-of-service that the photographer could use, and he could have someone pose next to it when he was ready for the shot? Indeed, the staged photo is much more attractive. It may be seen as a beautiful photo today, but that means it's just entertainment - not a scene from history.

I don't know what the photographer's intentions were for the staged photo. I'm guessing it would have been used to encourage others to support the war effort of the time. If I'm right about that, then I doubt it was ever presented as factual history. Instead, it would have been included in a larger work, like recruitment posters, which are promotional advertising like any other, with no connotations of objective truth. Either way, the people presenting the staged photo as real history are mistaken. Why elevate falsehoods to such heights, no matter how pleasing they are, when the truth is so readily available? Like the photo above, or this one, from a different photographer that didn't meddle with the scene as much:

It's an actual working machine, with an aluminum workpiece, tooling, chips, an inspection mirror, a test indicator for measurement, hair tightly bound for safety, and a clean work area. The only things that are unnatural in the photo are the lipstick and make-up, new clothing, and lack of an apron. She's not wearing eye protection, but since she's doing inspection at the moment, that might be forgivable by 1940's standards. Today, eye protection is required by everyone within line-of-sight throwing distance of the machines, and it is not allowed to be removed. People will always bend and break the rules, and that's when accidents happen, especially if a worker is being distracted by a visiting photographer.

In the background of the above photo is someone's hand with a ring on one finger. The person is actually operating a grinding wheel with their right hand (the photo may be mirror-reversed), and the grinding wheel is clearly spinning. Jewelry is not allowed near machines because an accident without jewelry takes a chunk of flesh that will heal, while an accident with jewelry will take the whole finger or hand, or arm, or torso...depending on which body part detaches first. The incidental occurrence of this safety problem in the background appears authentic to me. The people in the photo are actually doing their real jobs with functioning equipment, at the time of the photo.

Originally posted: List of problems that indicate it is fake.

TrueCrypt hidden message

[edit]

There is a hidden message on the new sourceforge TrueCrypt site. The first line of the site is this:

WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues

If you take just the first letter of each word, except the word "WARNING":

Using TrueCrypt is not secure as it may contain unfixed security issues

you get this:

uti nsa im cu si

It's Latin that roughly means:

Unless I want to use the NSA

So, the full message seems to be this:

WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues, unless I want to use the NSA

Which is English that roughly means:

Don't use TrueCrypt because it is under the control of the NSA

I have been informed that I may be the first to publish this hidden message. I wrote up a more formal article at LBC that contains this information, which is on Reddit here: Hidden message on the new sourceforge TrueCrypt site.

Bug Hunter Hate

[edit]

UPDATE 2014-11-21

[edit]

This is one of the best ideas I've seen, and it has been ignored for 7 years! Suggestions for Ohloh 2.0: I'd like to see bug tracker activity ... - Open Hub. Here's a direct link to my comment where I give my support to the idea.

Why so many bugs?

[edit]

Why does Mediawiki (Wikipedia) and extensions have so many bugs? It's because there are hundreds of developers working on the code base simultaneously using a continuous integration development model. Although there are always a lot of bugs, at least the software is always in a state where it works well enough that the bugs can be isolated and fixed. Ambitious software projects far smaller than MediaWiki tend to never deliver a functional product if they don't use a continuous integration development model. The problem with a continuous integration development model is that it moves forward so quickly that it's impractical to thoroughly test new code before putting it into service.

Programming is a fun thing to do, and the developers that do it not only enjoy the creative process in their software, they also receive recognition and accolades for their work. Very often, they receive monetary payment too. By not doing rigorous bug testing, it's a little less work, and a little more glory for the developers, which works out great for them in a continuous integration development model. But, somebody has to do the bug testing eventually, or the problems will mount until the developers start getting more complaints than glory. If the developers aren't doing the testing, then that work is left for bug hunters.

You're distracting ... go away!

[edit]

Bug hunters take on the most difficult and frustrating jobs, but they seldom get thanked for it, and they certainly don't get any recognition or accolades. Sometimes, they receive immediate hostility from the first mention that bug testing is being done, much like spammers - "You're distracting ... go away". Some developers have grown so accustomed to praise that they turn into violent primadonnas that can't respond properly to bug reports.

Partly because of my negative experiences with bug reporting in MediaWiki, I haven't done very much bug hunting for the Wikimedia Foundation since 2012, but I'd like to get back into it (2014). Getting into the "bug hunter mindset" means I've started keeping notes and reporting problems I've found with other software I like and use. One of my recent bug reports was for the PortableApps platform, specifically the updater. I was experiencing several problems, but I didn't know at first whether they were distinct bugs, or the same problem with multiple consequences, or something else, so I searched for previous bug reports. I found these:

  1. Updater hangs
  2. Updates fail and Downloads stop at 39.8Mb during attempt to update large app.

The first one described exactly the same symptoms I was experiencing that made the PortableApps Updater fail completely. The second one reminded me of other problems I experienced before the updater failed completely, and I suspected it might be related. Indeed, the person who initially reported the problem asked:

[I want] to know if I am alone or this is something others are experiencing.

I saw that no one had made any progress in helping the person, so I posted a response that I thought would be helpful (my most effective bug hunting technique). It said:

Others are experiencing similar issues, but there's not a consensus yet about what is happening, and whether they're related problems or not.

I was immediately chastised for my good deed, before anything more could be discussed:

Millions of people use the updater daily without issue. I realize it is frustrating having an issue on your end, but that's no reason to go around posting in unrelated bugs like this one.

And things just got worse from there...

I solved the problem

[edit]

As it turned out, 5 out of 8 of the computers we tested experienced some other bug (discussion #1 above) with the PortableApps Updater that I was not able to isolate before they spontaneously resolved themselves. The one that didn't resolve had received an automated Microsoft Internet Explorer (IE) update that was unsupported, and some unknown interaction from that prevented the PortableApps Updater from succeeding somehow. All 8 computers had no internet connectivity problems, and all 8 had working installations of IE, which was trivial to test.

I also was able to determine that the problems on all 8 computers that were tested, in both of the 2 discussions I participated in, actually ARE related! They are all caused by a single design flaw in the updater.[4] That flaw uniquely prevented ONLY the updater from functioning, while all other software had no internet connectivity problems. The design flaw was bad enough that even for very different problems the updater wouldn't time-out or give an error message in about half of the cases I tested. After 2 days of bug hunting with no sleep, I had succeeded in isolating a very difficult bug, and then I posted a solution of how to fix it, which goes beyond mere bug hunting - I solved the problem - but none of those contributions were welcomed. Actually, they were spurned, like pearls before swine.

The silly-fied excerpts below are originally from Reddit, with an added link to connect the 2 parallel discussions:

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?

Note:

I'll admit, after 30+ hours working on these bugs without any sleep, I was a little excited about isolating the most difficult bug case AND producing a fix for it (bonus points!), when it wouldn't spontaneously resolve on its own. That was the bug triggered by a seemingly unrelated problem with an automated Windows Update of MS IE. It wasn't the only problem in the 2 discussions I participated in, but it was part of a class of several problems with the PortableApps Updater that resulted in poor reliability.

The updater was overly complicated, but it wasn't able to do basic things like time-out and give an error message if an update fails. Total reliance on Microsoft's Internet Explorer is unnecessary, and a bad design decision that resulted in many other problems that have nothing to do with IE. It's not often that I can both isolate a bug, and produce a fix for it, so forgive me for relishing that small success - After all, there is no other reward for bug hunters. Still, it's not a good reason for developers to hate unpaid volunteer bug testers like they're irritating bugs themselves.

...and your little bug too!

[edit]

John T. Haller finished up by giving me a publicly visible "Final Warning" that makes him look like a fair and well-meaning person. In reality, he had already non-publicly banned me so that I would be unable to respond - and you can bet I would have responded because I tend to indignantly resist injustice (especially when it hurts the innocent people I was trying to help by bug-hunting for them). He abused that advantage to dishonestly manipulate the public's perception of me, which goes beyond mere ambiguous rejection, to violent hate.

John T. Haller accused me of spamming "ads" in my forum signature, after he had already deleted my forum signature so that no one can see for themselves what was there (unlinked public service mentions of MultiPar, FreeArc, and TypeMatrix keyboards, which you can see in my signatures on most of the forums I participate in). He insulted me by accusing me of trolling, and claiming I did not following his troubleshooting instructions (which I did, and more). Once again, this isn't my first time doing bug testing, and such jabs clearly stem from irresponsible unrestrained hostility.

John T. Haller seems to hate bug hunters. Not "dislike" them, not "prefers groupies instead" - we're looking at immediate, unprovoked, raw hatred directed at somebody who would have been hailed a hero if I were the developer responding to those people's questions, instead of just a lowly unpaid volunteer bug tester. That hate manifested almost immediately when it became clear that a thorough investigation was being done.

There's no place like home

[edit]

Fortunately, the Wikimedia Foundation is not a one-man show like the PortableApps platform is. I have experienced similar Bug Hunter Hate (BHH) when reporting bugs to MediaWiki developers, but there are enough other people involved that some of them might eventually step in to defend the lowly unpaid volunteer bug hunter if he's getting more than his fair share of BHH abuse. BHH is everywhere, so much so that I think we just have to accept it as an inherent fact that goes with the territory. From there we can do our part in reducing it as much as possible.

Other victims

[edit]

Here are some doozies:

The right way to treat bug hunters

[edit]

Not everybody is as evil as Facebook and others that react extremely negatively to bug reports:

Haters spotted in the wild

[edit]

As I document more instances of bug hunter hate, maybe I will be able to identify a pattern that gives more confidence in deducing the psychological reasons a few people (Yaron, Jeroen, Elad, Mark Zuckerberg, John Haller, etc) react so paradoxically negatively this way when someone else solves their problems for them for free. Incidentally, I was the subject of a recent major bug report for Sopel, due to my routine IRC use accidentally triggering the bug: [Bug] Sopel spams on 'disconnected by services' ¡ Issue #1026 ¡ sopel-irc/sopel. That's pretty funny!

"And you wonder why you get the reactions you do"

[edit]

A bug hunter found a bug that cripples important features on a Simple Machines Forum (SMF). I did not know about the bug, and there's no way I could have known if I didn't accidentally find the bug report. Meanwhile, before I learned of the bug, there was an "incident" that disrupted the cooperation in one of the projects I'm involved in. The bug causes new PM message notifications to fail, so people were not reading their messages, and the senders of those messages thought they were being ignored.

I reported this bug a second time, and when the developers refused to disclose it or fix it, the "bug" became indistinguishable from malware. That is not good for the reputation of SMF, my favorite forum software, so I did my best to explain why this bug needs to be either disclosed as a known issue, or fixed. It turned out the bug had already been fixed in the paid version of the software, but the developers never listed that as a selling point. Crippleware is only malicious if the crippling is done without the user's knowledge or consent, and that's exactly what was being done.

In the end, after taking much abuse and many insults, everyone agreed that I was right from the beginning - the bug should be disclosed as a known issue. But the abuse didn't stop there. Here's what Arantor had to say (see Re: Menu Editor Lite):

And you wonder why you get the reactions you do.

It's this attitude that drives people away from open source development. I have dozens of mods I could release via this site but I won't precisely because if I did I'd then have to deal with this sort of attitude, whether it was you personally or someone else.

And my response:

I don't wonder, I know. It's because of what I call the "bug hunter hate" phenomenon. It's extremely common, and I don't think anyone realizes they're doing it. They just react defensively with machine guns and barbed wire when someone reports a bug. That's why your accusations are so vague:

  • "[badon has] this attitude"
  • "[badon has] this sort of attitude"

It's just a visceral personal dislike of the people who report bugs. I have noticed that often, the worse the bug is, and the more important it is to disclose it or fix it, the more negative the reactions are. The behavior of many developers in this regard is indistinguishable from the malice you get from a virus or a punch in the nose. Only a few people react this way. You can see some good examples here:

https://www.mediawiki.org/wiki/User:Badon

What you interpreted as

  • grandstanding
  • attitude
  • roused to a cause
  • browbeating
  • attention-getting
  • melodrama
  • self-righteousness
  • exaggerating
  • chicken little impression
  • emotionally charged
  • a page right out of Trump's book
  • childishness
  • malicious behavior
  • acting like a victim
  • rudeness
  • being out-of-line
  • attacking
  • arguing
  • not being well-informed
  • not being accurate

...was really just routine bug hunting, reporting, and follow-up for some rectifying action after the bug gets reported (disclosure or a fix). You're not the first people to be so abusive to volunteer amateur bug hunter hobbyists like me, and you won't be the last.

It's amazing that people can be so cruel to volunteer bug hunters without even realizing they're doing it. I hope my information here will help people become more aware of it, so they can avoid these kinds of unnecessary conflicts. In the issue above, several people spent significant amounts of time and effort to insult me and resist my attempts to persuade them that disclosing a critical flaw is the right thing to do.

Although I encounter this kind of thing pretty often, I'm always amazed at how important it is to these people to keep doing the wrong thing, and thoroughly abuse anyone who suggests they should do the right thing instead. In this case, doing the wrong thing was MORE IMPORTANT than actually making money from the paid version of the software being discussed. Incredible. Disclosing the bug in the free version would have been an ideal opportunity to sell the paid version that does not have the bug. But no, we love that bug more than anything, and we want to keep it a secret so no one else can take that bug away from us. Money? Pish-posh. We're talking about LOVE here!

UPDATE 2016-04-30

It looks like they REALLY don't want to let me get away with a successful bug report. Now they're deleting and rewriting my posts, and harassing me with anonymous threats. YIKES! All that over a bug that takes less than 5 seconds to fix or disclose.

Some other things I care about

[edit]

Mediawiki etc.

[edit]

Support

[edit]

Localization

[edit]

Image annotation

[edit]

Data integrity

[edit]

Miscellaneous

[edit]

Extension:ReplaceText known issues

[edit]

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#Giving gifts 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

[edit]

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

[edit]

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: bugzilla:38170, bugzilla: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

[edit]

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: 

$wgGroupPermissions['sysop']['suppressredirect'] = true;

Compressed revisions are not searchable

[edit]

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

[edit]

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

[edit]
<noinclude>__NOTOC__
{{#ifeq: {{FULLPAGENAME}} | Widget:Google translate
	|
	| <span class="error" style="font-size:3em;">This code is on the wrong page! It's supposed to be on [[Widget:Google translate]]!</span><br /><br />
}}
This widget enables [http://translate.google.com/translate_tools Google translate tools]. You may use the widget like this:

<pre>
{{#widget: Google translate }}
</pre>

[[Category:Widgets]]
</noinclude><includeonly><div id="google_translate_element"></div><script>
function googleTranslateElementInit() {
  new google.translate.TranslateElement({
    pageLanguage: 'en',
    multilanguagePage: true,
    layout: google.translate.TranslateElement.InlineLayout.SIMPLE
  }, 'google_translate_element');
}
</script><script src="//translate.google.com/translate_a/element.js?cb=googleTranslateElementInit"></script></includeonly>

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 */
#siteNotice { height:0; }
#localNotice { height:0; margin-bottom:0; }
#siteNotice p { margin:0; padding:0; } /* Clean easy-to-read wiki formatting while producing superfluous <p></p> tags WITHOUT extra spacing in the sitenotice */

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

Twiddla widget

[edit]
<noinclude>__NOTOC__
This widget allows you to add a [http://www.twiddla.com/ Twiddla] meeting to a page. <span class="plainlinks">[{{fullurl:{{FULLPAGENAME}}|action=edit}} Edit the page]</span> to see the widget text.
You may use the widget like this:

<pre>
{{#widget: Twiddla }}
</pre>

[[Category:Widgets]]
</noinclude><includeonly>
<a href="http://www.twiddla.com/New.aspx?title=" title="Twiddle this page!" onclick="this.href+=document.title;"><img src="http://img.twiddla.com/images/buttons/twiddle_this_100x20.gif" border="0" alt="Twiddle this page!" /></a></includeonly>

HTML5 video and subtitles widget

[edit]

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. 

<noinclude>__NOTOC__
{{#ifeq: {{FULLPAGENAME}} | Widget:Html5media
	|
	| <span class="error" style="font-size:3em;">This code is on the wrong page! It's supposed to be on [[Widget:Html5media]]!</span><br /><br />
}}
This widget enables HTML5 video and audio using the [http://html5media.info/ html5media] JavaScript component. This widget also optionally enables [http://www.universalsubtitles.org/en/ Universal Subtitles] using the [http://www.universalsubtitles.org/en/get-code/ US Amara Widgetizer]. You may use the widget like this:

<pre>
{{#widget:Html5media
| url=http://www.somewebsite.com/somevideo.webm
| width=640
| height=360
| poster=http://www.somewebsite.com/someimage.png
| controls=yes
| preload=none
| subtitlesforall=yes
}}
</pre>

* '''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 ===
* For 16:9 wide screen format videos
** width=400<br /> height=215
** width=420<br /> height=236
** width=640<br /> height=360
** width=800<br /> height=450
** width=1024<br /> height=576
* For 4:3 monitor format videos
** width=400<br /> height=300
** width=420<br /> height=315
** width=640<br /> height=480
** width=800<br /> height=600
** width=1024<br /> height=768
=== 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 ===
[http://en.wikipedia.org/wiki/HTML5_video#Browser_support 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 [http://www.webmproject.org/users/ 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 [http://www.mediawiki.org/wiki/Extension:Translate Extension:Translate].
[[Category:Widgets]]
</noinclude><includeonly><!--{if $subtitlesforall == 'yes'}--><script type="text/javascript" src="http://s3.www.universalsubtitles.org/js/unisubs-widgetizer.js"><!--{/if}--></script><script src="http://api.html5media.info/1.1.4/html5media.min.js"></script><video style="background-color:#000000;" src="<!--{$url|validate:url}-->" width="<!--{$width|default:400|validate:int|escape:'html'}-->" height="<!--{$height|default:300|validate:int|escape:'html'}-->" poster="<!--{$poster|validate:url}-->" <!--{if $controls == 'no'}--><!--{else}-->controls<!--{/if}--> preload="<!--{$preload|default:none|escape:'html'}-->" ></video></includeonly>

YouTube widget

[edit]
<noinclude>__NOTOC__
{{#ifeq: {{FULLPAGENAME}} | Widget:YouTube
	|
	| <span class="error" style="font-size:3em;">This code is on the wrong page! It's supposed to be on [[Widget:YouTube]]!</span><br /><br />
}}
This widget allows you to add the YouTube video player to a page. <span class="plainlinks">[{{fullurl:{{FULLPAGENAME}}|action=edit}} Edit the page]</span> to see the widget text.
You may use the widget like this:

<pre>
{{#widget:YouTube
| id=DWef69ItVrU
| width=640
| height=360
| showmore=yes
| subtitlesforall=yes
}}
</pre>

* '''id''' is the YouTube video ID, taken from the last part of the YouTube URL, like this (colored <span style="color:#FF0000;">red</span>): http://www.youtube.com/watch?v=<span style="color:#FF0000;">DWef69ItVrU</span>
* '''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
[[Category:Widgets]]
</noinclude><includeonly><!--{if $subtitlesforall == 'yes'}--><script type="text/javascript" src="http://s3.www.universalsubtitles.org/js/unisubs-widgetizer.js"></script><object width="<!--{$width|escape:'html'|default:'420'}-->" height="<!--{$height|escape:'html'|default:315}-->"><param name="movie" value="http://www.youtube.com/v/<!--{$id|escape:'urlpathinfo'}-->?version=3&hl=en_US<!--{if $showmore == 'yes'}-->&rel=0<!--{/if}-->"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/<!--{$id|escape:'urlpathinfo'}-->?version=3&hl=en_US<!--{if $showmore == 'yes'}-->&rel=0<!--{/if}-->" type="application/x-shockwave-flash" width="<!--{$width|escape:'html'|default:'420'}-->" height="<!--{$height|escape:'html'|default:315}-->" allowscriptaccess="always" allowfullscreen="true"></embed></object><!--{else}--><iframe width="<!--{$width|escape:'html'|default:'420'}-->" height="<!--{$height|escape:'html'|default:315}-->" src="http://www.youtube.com/embed/<!--{$id|escape:'urlpathinfo'}--><!--{if $showmore == 'yes'}-->?rel=0<!--{/if}-->" frameborder="0" allowfullscreen></iframe><!--{/if}--></includeonly>

Bug hunting tips

[edit]

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):
{{#ifeq: {{FULLPAGENAME}} | the page the code is supposed to be on
 |
 | <span class="error" style="font-size:3em;">This code is on the wrong page!<br />
   It's supposed to be on [[the page the code is supposed to be on]]!</span><br /><br />
}}
  • 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:
      1. 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.
      2. 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.
      3. 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.
      4. 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

[edit]

Other extensions

[edit]

Advanced MediaWiki programming tips

[edit]
  • 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:
[[Some invisible SMW property::Some value| ]] <!-- This is supposed to be invisible, but the space in front of this comment will cause a <pre/> tag to be inserted by the MediaWiki parser. -->
  • 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:
{{urlencode: This line is perfect except for 2 spaces before the last  word }}
To get this, where you can see two %20 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 <nowiki /> at the end of lines to prevent the buildup of empty wiki paragraphs (1 <p></p>paragraph for each 2 newlines), like this:
{{#if: something
| do this
| or do this
}}
{{#if: something
 | do this
 |<!-- Don't do anything. -->
}}
  • Do not use <nowiki /> inside #vardefine if you are going to test it later with an #if, because <nowiki /> in your variables will cause them to always pass the test. Like this:
<!-- This is wrong. -->
{{#vardefine: MyVariable |
 {{#if: something
  | do this
  |<!-- Don't do anything. --><nowiki /><!-- This is a problem. -->
 }}<nowiki /><!-- This is a problem. -->
}}
{{#if: {{#var: MyVariable }} <!-- MyVariable will always pass the test because it always has 2 <nowiki /> in it. -->
 | It will always do this
 | It will never do this
}}

<!-- This is right. -->
{{#vardefine: MyVariable |
 {{#if: something
  | do this
  |<!-- Don't do anything. Notice that there is no space in front of this comment, which could also screw this up. -->
 }}
}}
{{#if: {{#var: MyVariable }}
 | It will sometimes do this
 | Or, it will sometimes do this
}}
  • <nowiki /> is not needed inside functions that do not directly or indirectly output anything, like in string manipulation code.
  • It is better to use many #vardefine's within nested #if tests than to place your #if statements inside a #vardefine. It makes debugging mysterious whitespace much easier. Like this:
<!-- This is wrong. -->
{{#vardefine: MyVariable |
 {{#if: something
  | do this
  |<!-- Don't do anything. -->
 }}
}}
<!-- This is right. -->
{{#if: something
 | {{#vardefine: MyVariable | do this }}
 | {{#vardefine: MyVariable |}}<!-- Don't do anything. -->
}}

Distributed template job queue management

[edit]

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: {{Some template}}
  • Replace: {{Some template {{subst:#rand: 1 | 30 }} }}

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

[edit]

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

[edit]
This is one of my favorite photos.

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.

Notes and references

[edit]
  1. ↑ "If you want to help, write decent bugs report like other people seem to manage."
  2. ↑ Sometimes valid bugs are marked as invalid, apparently for the purpose of humiliating bug hunters. No one would insist that a developer not mark a bug as fixed, but it's OK to do that to bug hunters, as in bugzilla:33479.
  3. ↑ bugzilla:32817#c7, bugzilla:30004#c6, bugzilla:29891#c3
  4. ↑ The flaw exists solely "to show download progress in NSIS". That feature isn't even used in the bug case where the updater hangs, in discussion #1. John T. Haller said a rewrite of the PortableApps updater is planned, so he is probably aware that it is unreliable. I don't know how that translates into immediate maltreatment behavior toward well-meaning bug hunters.
Retrieved from "https://www.mediawiki.org/w/index.php?title=User:Badon&oldid=3883185"