New extension: Special:ExtensionStatus (opinions?)

List overview All Threads
Download

newer

older

don't show certain links with the...

Tool for Google Summer of Code:...

Moriel Schottlender

13 May 2013 13 May '13

4:26 a.m.

Hello everyone, I'd like to get your opinions and critique on my very first MediaWiki extension, which, I hope, will be helpful to other developers. I noticed that there's no easy way of seeing if extensions that we have installed on our MediaWiki require update, and there are even some extensions that get so little regular attention that when they do get updated, there's no real way of knowing it (unless we check specifically). It can be annoying when encountering problems or bugs, and then discovering that one of our extensions (probably the one we least expected) actually has an update that fixed this bug. So, I thought to try and solve this issue with my extension. Since MediaWiki's changes are submitted through gerrit, I thought I'd take advantage of that and perform a remote check to see if there are any new commits that appeared in any of the extensions since they were installed. How it works, briefly: the system compares the local repository date to the list of latest commits on gerrit's repo for the extension to see how many commits a user is behind on. If the user doesn't have a local git for the extension (or if they downloaded the extension manually) the system falls back to testing the local modification date for the files. It's not perfect, but it can give people a general idea of whether or not their extensions need some TLC. The extension is available on GitHub: https://github.com/mooeypoo/MediaWiki-ExtensionStatus along with screenshots and a short possible todo list. There's a list of things I plan to try and improve, some of them are meant to make the lives of newbie developers (like me!) easier, but I'd love it if I could get feedback from you all and see if you think this could be helpful to you. Would you like to see anything else in it? Do you think I'm in the right direction or am I doing it all wrong? Be merciless! Okay, maybe not *completely* merciless, but please don't hold back. This is my very first extension, and beyond wanting to make this a good extension, I also want to get a sense of whether or not I got into MW development right, and if there is anything I should have done (or be doing) differently. Please let me know what you think! Moriel (mooeypoo) -- No trees were harmed in the creation of this post. But billions of electrons, photons, and electromagnetic waves were terribly inconvenienced during its transmission!

Show replies by date

Daniel Friesen

13 May 13 May

6:21 a.m.

On Sun, 12 May 2013 21:26:42 -0700, Moriel Schottlender <moriel(a)gmail.com> wrote:

...

Hello everyone, I'd like to get your opinions and critique on my very first MediaWiki extension, which, I hope, will be helpful to other developers. ... The extension is available on GitHub: https://github.com/mooeypoo/MediaWiki-ExtensionStatus along with screenshots and a short possible todo list.

* Your RL module should have a remote path in addition to a local one, it's also proper to declare the media type for your css. You should also drop the `@CHARSET "UTF-8"`. * The wfMessage calls should probably be $this->msg instead. * i18n messages are generally used for opening and closing parenthesis iirc. * You want $this->getLanguage() not $wgLang. * Don't mess with the error_reporting setting in extension code.

...

... Please let me know what you think! Moriel (mooeypoo)

-- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

Moriel Schottlender

6:35 a.m.

On Mon, May 13, 2013 at 2:21 AM, Daniel Friesen <daniel(a)nadir-seen-fire.com>wrote;wrote:

...

Thanks a lot Daniel! Much appreciated. I also noticed I should go through the styleguide to make sure I follow the proper conventions (spaces, loops, etc). I'm going to go over it all in the next couple of days. One quick question -- I'm not sure I understand your first comment. What do you mean RL module? a remote path where? do you mean in the "$wgExtensionCredits[ 'specialpage' ][]" array? Thanks again! Moriel -- No trees were harmed in the creation of this post. But billions of electrons, photons, and electromagnetic waves were terribly inconvenienced during its transmission!

Daniel Friesen

7:02 a.m.

On Sun, 12 May 2013 23:35:12 -0700, Moriel Schottlender <moriel(a)gmail.com> wrote:

...

On Mon, May 13, 2013 at 2:21 AM, Daniel Friesen <daniel(a)nadir-seen-fire.com>wrote;wrote: Thanks a lot Daniel! Much appreciated. I also noticed I should go through the styleguide to make sure I follow the proper conventions (spaces, loops, etc). I'm going to go over it all in the next couple of days. One quick question -- I'm not sure I understand your first comment. What do you mean RL module? a remote path where? do you mean in the "$wgExtensionCredits[ 'specialpage' ][]" array?

In the $wgResourceModules['ext.ExtensionStatus']. You need to set a remote path in addition to the local one. Otherwise ResourceLoader (RL) will point things to the wrong path in debug mode. Since you're in an extension you can use 'remoteExtPath' => 'ExtensionStatus'.

...

Thanks again! Moriel

-- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

Yury Katkov

6:44 a.m.

I very much lie the idea of this extension: it's very useful to know what changes have been made in a software one is using. Does it only work with WMF's gerrit? Many extensions are not hosted there. I think that for them you can just compare the version number of the extension with its current version number on mediawiki.org. ----- Yury Katkov, WikiVote On Mon, May 13, 2013 at 8:26 AM, Moriel Schottlender <moriel(a)gmail.com> wrote:

...

Moriel Schottlender

7:31 a.m.

On Mon, May 13, 2013 at 2:44 AM, Yury Katkov <katkov.juriy(a)gmail.com> wrote:

...

Thanks for the comment Yuri! For the moment, it's only using gerrit for the extension repos, but the plan is to add more options after the extension is stable and passes some review about its value and the strategy I'm using. It's definitely planned. I was actually thinking of adding "alternative repo location" option for extensions that can't be found on gerrit, so users can put in the repository themselves. I didn't think about comparing the versions, I was thinking of trying to see if there are revisions in the commit history -- but this is a good idea. I'll check into that. Thanks! Moriel -- No trees were harmed in the creation of this post. But billions of electrons, photons, and electromagnetic waves were terribly inconvenienced during its transmission!

Markus Glaser

8:06 a.m.

Hi Moriel, I like that idea very much. In the use case I have in mind, though, I do have actual releases. Do you think it's possible for your extension to also consider tags? I am thinking of something like a tagging convention, e.g. "RELEASE v1.20". ExtensionStatus could then "parse" the tag and send it back to the user. Best, Markus (mglaser) -----Ursprüngliche Nachricht----- Von: wikitech-l-bounces(a)lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] Im Auftrag von Moriel Schottlender Gesendet: Montag, 13. Mai 2013 06:27 An: wikitech-l(a)lists.wikimedia.org Betreff: [Wikitech-l] New extension: Special:ExtensionStatus (opinions?) Hello everyone, I'd like to get your opinions and critique on my very first MediaWiki extension, which, I hope, will be helpful to other developers. I noticed that there's no easy way of seeing if extensions that we have installed on our MediaWiki require update, and there are even some extensions that get so little regular attention that when they do get updated, there's no real way of knowing it (unless we check specifically). It can be annoying when encountering problems or bugs, and then discovering that one of our extensions (probably the one we least expected) actually has an update that fixed this bug. So, I thought to try and solve this issue with my extension. Since MediaWiki's changes are submitted through gerrit, I thought I'd take advantage of that and perform a remote check to see if there are any new commits that appeared in any of the extensions since they were installed. How it works, briefly: the system compares the local repository date to the list of latest commits on gerrit's repo for the extension to see how many commits a user is behind on. If the user doesn't have a local git for the extension (or if they downloaded the extension manually) the system falls back to testing the local modification date for the files. It's not perfect, but it can give people a general idea of whether or not their extensions need some TLC. The extension is available on GitHub: https://github.com/mooeypoo/MediaWiki-ExtensionStatus along with screenshots and a short possible todo list. There's a list of things I plan to try and improve, some of them are meant to make the lives of newbie developers (like me!) easier, but I'd love it if I could get feedback from you all and see if you think this could be helpful to you. Would you like to see anything else in it? Do you think I'm in the right direction or am I doing it all wrong? Be merciless! Okay, maybe not *completely* merciless, but please don't hold back. This is my very first extension, and beyond wanting to make this a good extension, I also want to get a sense of whether or not I got into MW development right, and if there is anything I should have done (or be doing) differently. Please let me know what you think! Moriel (mooeypoo) -- No trees were harmed in the creation of this post. But billions of electrons, photons, and electromagnetic waves were terribly inconvenienced during its transmission! _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Moriel Schottlender

8:15 a.m.

On Mon, May 13, 2013 at 4:06 AM, Markus Glaser <glaser(a)hallowelt.biz> wrote:

...

I like that idea very much. In the use case I have in mind, though, I do have actual releases. Do you think it's possible for your extension to also consider tags? I am thinking of something like a tagging convention, e.g. "RELEASE v1.20". ExtensionStatus could then "parse" the tag and send it back to the user.

Hi Markus, Absolutely, I wish it was already a convention. I created the 'read the remote git' to go around that problem. I could, however, set the system to first check a release tag and then fall back to testing dates/commits like it does now if the release tag is unavailable. The problem with tags, though, is that we will need to have some common location that keeps the newest release on record so the extension can then compare the local tag against a remote update. I believe this is what's done in systems like Wordpress and Drupal, but their extension database system is completely different, too, and I don't think it fits MW at all. For that matter, their extensions are more 'individual-based' rather than collaborative to the community, that won't work here. It will also require extension updaters/developers to update those tags. I think it's fairly easy to add a local vs remote tag comparison, the question is how it can be implemented in terms of convention so all extensions end up following it. Is it realistic? -- No trees were harmed in the creation of this post. But billions of electrons, photons, and electromagnetic waves were terribly inconvenienced during its transmission!

Brian Wolff

8:22 a.m.

On 2013-05-13 5:16 AM, "Moriel Schottlender" <moriel(a)gmail.com> wrote:

...

On Mon, May 13, 2013 at 4:06 AM, Markus Glaser <glaser(a)hallowelt.biz>

wrote:

...

> I like that idea very much. In the use case I have in mind, though, I do > have actual releases. Do you think it's possible for your extension to

also

...

> consider tags? I am thinking of something like a tagging convention,

e.g.

...

"RELEASE v1.20". ExtensionStatus could then "parse" the tag and send it back to the user.

terribly

...

inconvenienced during its transmission! _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Aarti K. Dwivedi

12:49 p.m.

Hi, The idea is obviously good and useful. In OPW round 5( http://www.mediawiki.org/wiki/Outreach_Program_for_Women/Round_5 ) there was a project for pulling files from a git repository. A part of the project dealt with updating the files. The approach( checking for last commit id or modification date ) could be similar. Just telling you that similar work has been done on a smaller scale before. Cheers, Rtdwivedi On Mon, May 13, 2013 at 1:52 PM, Brian Wolff <bawolff(a)gmail.com> wrote:

...

On 2013-05-13 5:16 AM, "Moriel Schottlender" <moriel(a)gmail.com> wrote:

On Mon, May 13, 2013 at 4:06 AM, Markus Glaser <glaser(a)hallowelt.biz>

wrote:

> I like that idea very much. In the use case I have in mind, though, I

> have actual releases. Do you think it's possible for your extension to

also

> consider tags? I am thinking of something like a tagging convention,

e.g.

"RELEASE v1.20". ExtensionStatus could then "parse" the tag and send it back to the user.

Hi Markus, Absolutely, I wish it was already a convention. I created the 'read the remote git' to go around that problem. I could, however, set the system

first check a release tag and then fall back to testing dates/commits

it does now if the release tag is unavailable. The problem with tags, though, is that we will need to have some common location that keeps the newest release on record so the extension can

then

compare the local tag against a remote update. I believe this is what's done in systems like Wordpress and Drupal, but their extension database system is completely different, too, and I don't think it fits MW at all. For that matter, their extensions are more 'individual-based' rather than collaborative to the community, that won't work here. It will also require extension updaters/developers to update those tags. I think it's fairly easy to add a local vs remote tag comparison, the question is how it can be implemented in terms of convention so all extensions end up following it. Is it realistic? -- No trees were harmed in the creation of this post. But billions of electrons, photons, and electromagnetic waves were

terribly

We actually do autocreate tags (REL1_XX) whenever we do a release that corresponds to the version of extension included in the installer (if it is included) and for use by special:extensiondistributor. How much people update the tags varries by extension, with many not really being updated but some are. -bawolff _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- Aarti K. Dwivedi

Mark A. Hershberger

4:58 p.m.

On 05/13/2013 12:26 AM, Moriel Schottlender wrote:

...

I'd like to get your opinions and critique on my very first MediaWiki extension, which, I hope, will be helpful to other developers.

I like this idea. I wonder if you could work with the WikiApiary site (http://wikiapiary.com/) as you adapt this to track releases rather than just updates in Gerrit. I've CC'd Jamie Thingelstad of WikiApiary in case he has any insights into this. Maybe an API is available that you could use. Finally, have you thought of making it possible to update the extension in-place like WordPress does? -- http://hexmode.com/ Imagination does not breed insanity. Exactly what does breed insanity is reason. Poets do not go mad; but chess-players do. -- G.K. Chesterson

Moriel Schottlender

7:12 p.m.

Guys - thank you so much for the comments, I really appreciate it! The future goal for this could very well be something that helps people upgrade their extensions (as similar as possible to something like wordpress, which is very newbie-friendly) and download the files directly with or without git available. I think the biggest challenge is the target audience here. I wanted to try and make sure this extension works well for newbies who need upgrade but *also* to experienced users that might need to pull from the repositories. Also, I'm a windows user (I do all the gerrit stuff from a VM) so I aimed towards compliance there too. Aiming towards both crowds is tricky, but I think it's possible with your feedback :) I'm going to sit and write a "to do" list and try to prioritize it. Now that I know the extension is worthwhile, I might as well open a page for it in MW and put it there, and let people contribute their thoughts here or in its talk page. (Quick disclaimer -- my finals are this week, and I do this in my 'break' time, so please bear with me if I'm a tad slow on answering or submitting improvements! Sadly, exams don't study themselves -- though that *could* have been an awesome extension ;) Please keep the comments coming! This is really helpful :) Thanks, Moriel On Mon, May 13, 2013 at 12:58 PM, Mark A. Hershberger <mah(a)everybody.org>wrote;wrote:

...

On 05/13/2013 12:26 AM, Moriel Schottlender wrote:

I'd like to get your opinions and critique on my very first MediaWiki extension, which, I hope, will be helpful to other developers.

-- No trees were harmed in the creation of this post. But billions of electrons, photons, and electromagnetic waves were terribly inconvenienced during its transmission!

Thomas Gries

7:24 p.m.

Am 13.05.2013 21:12, schrieb Moriel Schottlender:

...

Guys - thank you so much for the comments, I really appreciate it!

Hi, I just wanted to _/mention/_: 1. This was merged into MediaWiki core on 16.04.2013: https://gerrit.wikimedia.org/r/#/c/54986/ "Add git HEAD date to Special:Version for core and extensions" 2. The following is pending, but perhaps better be solved by your and DaSch's extension: https://gerrit.wikimedia.org/r/#/c/59373/ "(bug 47264 <https://bugzilla.wikimedia.org/47264>) Special:Version: add last local update timestamp for core and extensions"

Ryan Lane

14 May 14 May

3:33 a.m.

On Sun, May 12, 2013 at 11:26 PM, Moriel Schottlender <moriel(a)gmail.com>wrote;wrote:

...

Moriel Schottlender

5:57 a.m.

I can change this to the github repos, yes, all I need to know is the "schema" of the url. Also, Reedy made the excellent suggestion of Caching results -- which I am working on -- that will also reduce both load time and heavy traffic time. But actually, working in front of github will be somewhat easier, too, since github has a better REST API. Are all (or most) extensions in Github under https://github.com/wikimedia/ with a "mediawiki-extensions-" prefix? Can I use that as a general rule of thumb? On Mon, May 13, 2013 at 11:33 PM, Ryan Lane <rlane32(a)gmail.com> wrote:

...

On Sun, May 12, 2013 at 11:26 PM, Moriel Schottlender <moriel(a)gmail.com

wrote:

specifically).

It can be annoying when encountering problems or bugs, and then

discovering

that one of our extensions (probably the one we least expected) actually has an update that fixed this bug. So, I thought to try and solve this issue with my extension. Since MediaWiki's changes are submitted through gerrit, I thought I'd take advantage of that and perform a remote check to see if there are any new commits that appeared in any of the extensions since they were installed.

I like the idea of this, but if this is used widely it's going to kill our gerrit server. It hits gitweb directly. Gitweb calls are uncached and are fairly expensive to run against our server. We replicate all repositories to github, and they allow this kind of thing. Is there any way you can change this to use the github replicas? - Ryan _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- No trees were harmed in the creation of this post. But billions of electrons, photons, and electromagnetic waves were terribly inconvenienced during its transmission!

Tyler Romeo

5:59 a.m.

On Tue, May 14, 2013 at 1:57 AM, Moriel Schottlender <moriel(a)gmail.com>wrote;wrote:

...

Are all (or most) extensions in Github under https://github.com/wikimedia/with a "mediawiki-extensions-" prefix? Can I use that as a general rule of thumb?

Yes. They're mirrored automatically. Also, you're probably thinking this already, but just in case, make sure not to remove Gerrit checking when you remove GitHub checking. Always good to have that as a backup on the chance we ever move away from GitHub. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo(a)gmail.com

Matthew Flaschen

6:43 a.m.

On 05/14/2013 01:59 AM, Tyler Romeo wrote:

...

On Tue, May 14, 2013 at 1:57 AM, Moriel Schottlender <moriel(a)gmail.com>wrote;wrote:

Are all (or most) extensions in Github under https://github.com/wikimedia/with a "mediawiki-extensions-" prefix? Can I use that as a general rule of thumb?

Or set up some caching on Gitweb, so it's usable for this kind of thing. Matt Flaschen

K. Peachey

6:59 a.m.

On Tue, May 14, 2013 at 4:43 PM, Matthew Flaschen <mflaschen(a)wikimedia.org> wrote:

...

Or set up some caching on Gitweb, so it's usable for this kind of thing.

I believe Chad is planning on sending Gitweb to /dev/null/, in-turn for a better replacement (if it does caching better is another question).

Chad

11:14 a.m.

On Tue, May 14, 2013 at 2:59 AM, K. Peachey <p858snake(a)gmail.com> wrote:

...

On Tue, May 14, 2013 at 4:43 PM, Matthew Flaschen <mflaschen(a)wikimedia.org> wrote:

Or set up some caching on Gitweb, so it's usable for this kind of thing.

I believe Chad is planning on sending Gitweb to /dev/null/, in-turn for a better replacement (if it does caching better is another question).

I'm planning to have this done by the end of the week. -Chad

Moriel Schottlender

17 May 17 May

1:15 a.m.

Hi everyone, Again, thank you to for all the comments, advice and criticism! I just wanted to send an update on the status of the extension -- I created a page for this extension on mw - http://www.mediawiki.org/w/index.php/Extension:ExtensionStatus where I also added a future/todo list, a screenshot of the current version and a mockup for what I think could be good to have in the future versions. We can continue discussions about features or anything else in the talk page, as well, if it's more convenient. If you do start a discussion there, please be patient with me, I'm still rather new to talk pages (and they can be a bit confusing) The new code is available on GitHub (for the moment) - https://github.com/mooeypoo/MediaWiki-ExtensionStatus You can see a screenshot of the current working version here: http://www.mediawiki.org/wiki/File:Extstatus_screenshot.png I'll be transferring the extension to the new Gerrit repository (thanks again for the help, James_F!) -- please bear with me as I'm in the last weeks of my semester, so I'm working on all of this in-between finals. The next immediate stages for the extension will be a working cache to lessen the load time *and* the load request on gerritweb -- I will then be able to look for alternatives such as reading the extension details from the GitHub mirrors and/or allowing for other external repository urls without having to "strip" gerrit's web page. Reading extension stats and details from wikiapiary is also planned (thanks for those suggestions!) Trying to build the features so they please both experienced users and newbies alike is a bit of a challenge, but I think this can happen with community feedback -- so keep it coming! Thanks! Moriel On Tue, May 14, 2013 at 7:14 AM, Chad <innocentkiller(a)gmail.com> wrote:

...

On Tue, May 14, 2013 at 2:59 AM, K. Peachey <p858snake(a)gmail.com> wrote:

On Tue, May 14, 2013 at 4:43 PM, Matthew Flaschen <mflaschen(a)wikimedia.org> wrote:

Or set up some caching on Gitweb, so it's usable for this kind of thing.

I believe Chad is planning on sending Gitweb to /dev/null/, in-turn for a better replacement (if it does caching better is another question).

I'm planning to have this done by the end of the week. -Chad _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- No trees were harmed in the creation of this post. But billions of electrons, photons, and electromagnetic waves were terribly inconvenienced during its transmission!