Created attachment 12815
It's the entire extension in a gzip tar.

Attached:

foreach over a db result set should work, unless .. maybe you're using a too old MediaWiki core?

btw for uploading patches: please upload a proper diff, instead of uploading a whole "fixed extension".

(In reply to comment #0)

This is the result of attempting to use a foreach on a database result
object.

The correct way would be to use:
while ($row = $dbr->fetchObject($res)) { ... }

No, that isn't the correct way.

https://www.mediawiki.org/wiki/Manual:Coding_conventions/PHP#Assignment_expressions

Also, you shouldn't have included the ._*.php files

(In reply to comment #2)

foreach over a db result set should work, unless .. maybe you're using a too
old MediaWiki core?

btw for uploading patches: please upload a proper diff, instead of uploading
a
whole "fixed extension".

The extension is listed as being compatible with 1.18+. The oldest snapshot for 1.19+ still has these bugs in it against the 1.19 base.

Created attachment 12816
Diff Patch

Attached:

(In reply to comment #6)

Created attachment 12816 [details]
Diff Patch

To clarify: Is that for informational reasons (local changes to make things "somehow" work), or is this meant for maintainers to merge into the codebase?

Attached:

Hi Alexia and thank you for the patch! I've added support for creating the database tables via update.php in gerrit change #76455.

Some thoughts and criticism on your patch/this bug report:

• Regarding "You can't foreach over database results": as Reedy pointed out in comment 3, this is incorrect, since you not only can, but you should as it's the recommended way and it's been like that for years. while() loops are *so* 2006. :)
• You wrote in comment 5 that "The extension is listed as being compatible with 1.18+." While that indeed is the case, you should take the information on MediaWiki.org with a grain of salt at least when it comes to extensions not deployed on Wikimedia Foundation websites. For the extensions that I maintain (you can see a full list of them at http://www.mediawiki.org/wiki/User:Jack_Phoenix/extensions), I usually try to ensure that they work with the latest stable release of MediaWiki. Sometimes this works, sometimes not; for example, QuizGame had been broken for over a year until I fixed it on 27 July 2013 and SocialProfile was broken for a while until a third-party user contributed a patch that fixed it. tl,dr: backwards compatibility is nice, but not mandatory. If you want a version of the extension that works with older releases, you'll need to check the version history and try to find it yourself.
• While moving the wfComments function into the CommentsHook class, you forgot to move over the other related functions in Comment.php, especially the displayComments function. It's confusing in my opinion that the hook registration happens in one file but the callback is in another file.
• Changing dirname( FILE ) . '/' to DIR is OK, but not necessary; dirname( FILE ) . '/' is the older, pre-PHP 5.3 way of fetching the directory name of the current file.
• In the LoadExtensionSchemaUpdates, you check if $updater is null; this is unnecessary and has been like that since MediaWiki 1.16 or so. Nowadays you can and should safely assume that $updater is _never_ null and act accordingly. Also, in that same function, in that very same if loop, you declare six (!) global variables, of which one (theoretically) is needed ($wgExtNewTables), but since you don't need that if loop at all, you also don't need any globals. Fun!
• I'm not sure if adding a simple database updater function is enough to claim copyright on the code. It's been done many times by various developers in different extensions, so it's hardly original. Again, this is a very minor thing but I'll have to say it's not something I'd do. (It's true that many of the extensions I've originally written have been released into the public domain, but this does not apply to other people's code that I maintain and social tools fall into that category.)
• Coding style! Please please please take a look at http://www.mediawiki.org/wiki/Manual:Coding_conventions and format your code accordingly. Basically, indent with tabs, not with spaces.

Your statement about Gerrit is generally speaking rather correct, too: Gerrit is where patches generally go to die unless you're active and poke people to review 'em. Not to mention that its UI is pretty horrendous, let alone its backend...
Still, submitting a patch there is preferrable to uploading entire .tar.gz files.

(And yes, I don't get people who nit-pick over commit messages either; commit messages are nice and informative but they definitely shouldn't be the main focus of a commit, the code should be. It's irrelevant how grammatically correct or incorrect the commit message is if the code itself is awful.)

Comment on attachment 12815
It's the entire extension in a gzip tar.

Fix attachment type. This is not compatible with bugzilla "patch".

Comment on attachment 12816
Diff Patch

Fix attachment type. This is a patch, not plain text.