[Wikitech-l] new extension PageProperties
hello, I have published recently the extension PageProperties https://www.mediawiki.org/wiki/Extension:PageProperties it is mainly a page properties aggregator where users can set display title, language and content model of a page, in one place, plus defining SEO meta data and Semantic Mediawiki properties (provided that SMW is installed) without annotating them manually on the page. It partly develops the concept of "Enterprise Mediawiki" mentioned here https://phabricator.wikimedia.org/T149612 (together with other extensions which are either in beta status, or not yet published that I plan to publish progressively.) Technically, it uses the _javascript_ tabs used by PreferencesFormOOUI, plus other pieces taken from the DisplayTitle extension (mentioned within the code) and from the special pages SpecialPageLanguage and SpecialChangeContentModel, and of course original code. Kind regards (Thomas) ___ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
Re: [Wikitech-l] new extension
For the record: this issue has been discussed yesterday on #wikimedia-dev. Logs are available here http://bots.wmflabs.org/%7Ewm-bot/logs/%23wikimedia-dev/20150417.txt (starting at 22:48:15). Il 26/02/2015 10:40, Ricordisamoa ha scritto: I was supposing that the Wikimedia Foundation would be willing to run the W3C Validator on their servers. Now I ask: is it feasible? Il 17/12/2014 17:57, Ricordisamoa ha scritto: I've written a simple MediaWiki extension that uses an instance of the W3C Validator service (via the Services_W3C_HTMLValidator http://pear.php.net/package/Services_W3C_HTMLValidator PEAR package) to validate SVG images hosted on a wiki. It is meant to replace the current system on Commons, that relies on individual contributors adding templates (e.g. InvalidSVG https://commons.wikimedia.org/wiki/Template:InvalidSVG) by hand to file description pages. It exposes a simple API (and a Scribunto module as well) to get the validation status of existing SVG files, can emit warnings when trying to upload invalid ones, and is well integrated with MediaWiki's native ObjectCache mechanism. I'm in the process of publishing the code, but have some questions I think the community could help me answer. * Given that the W3C Validator can also parse HTML files, would it be useful to validate wiki pages as well? Even if sometimes the validation errors appear to be caused by MediaWiki itself, they can also depend on malformed templates. * Does storing the validation status of old revisions of images (and/or articles) make sense? * Do you think the extension should use the extmetadata property of ApiQueryImageInfo instead of a its own module? * Is it advisable to store validation data permanently in the database? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] new extension
I was supposing that the Wikimedia Foundation would be willing to run the W3C Validator on their servers. Now I ask: is it feasible? Il 17/12/2014 17:57, Ricordisamoa ha scritto: I've written a simple MediaWiki extension that uses an instance of the W3C Validator service (via the Services_W3C_HTMLValidator http://pear.php.net/package/Services_W3C_HTMLValidator PEAR package) to validate SVG images hosted on a wiki. It is meant to replace the current system on Commons, that relies on individual contributors adding templates (e.g. InvalidSVG https://commons.wikimedia.org/wiki/Template:InvalidSVG) by hand to file description pages. It exposes a simple API (and a Scribunto module as well) to get the validation status of existing SVG files, can emit warnings when trying to upload invalid ones, and is well integrated with MediaWiki's native ObjectCache mechanism. I'm in the process of publishing the code, but have some questions I think the community could help me answer. * Given that the W3C Validator can also parse HTML files, would it be useful to validate wiki pages as well? Even if sometimes the validation errors appear to be caused by MediaWiki itself, they can also depend on malformed templates. * Does storing the validation status of old revisions of images (and/or articles) make sense? * Do you think the extension should use the extmetadata property of ApiQueryImageInfo instead of a its own module? * Is it advisable to store validation data permanently in the database? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] new extension
Il 21/01/2015 05:27, Gergo Tisza ha scritto: On Mon, Jan 19, 2015 at 10:00 AM, Tyler Romeo tylerro...@gmail.com wrote: * Do you think the extension should use the extmetadata property of ApiQueryImageInfo instead of a its own module? * Is it advisable to store validation data permanently in the database? I have no idea about this, but it does seem that the metadata is propagated to the oldimage table when a new one is uploaded, so it would fulfill your above question about storing old revisions' validation status. metadata is data generated from the file. It has built-in storage and invalidation mechanisms that are based on file upload / purge. extmetadata is assumed to come from some other source, and providers need to handle invalidation (and permanent storage, if desirable) manually. Thus, metadata would be a better fit in theory, but I don't think it offers any mechanism currently for extensions to hook into it. So I don't think you are any worse off by writing a self-contained extension. There is the GetExtendedMetadata hook https://www.mediawiki.org/wiki/Manual:Hooks/GetExtendedMetadata but, according to the documentation https://www.mediawiki.org/wiki/API:Properties#imageinfo_.2F_ii, the data should be in HTML format. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] new extension
On Mon, Jan 19, 2015 at 10:00 AM, Tyler Romeo tylerro...@gmail.com wrote: * Do you think the extension should use the extmetadata property of ApiQueryImageInfo instead of a its own module? * Is it advisable to store validation data permanently in the database? I have no idea about this, but it does seem that the metadata is propagated to the oldimage table when a new one is uploaded, so it would fulfill your above question about storing old revisions' validation status. metadata is data generated from the file. It has built-in storage and invalidation mechanisms that are based on file upload / purge. extmetadata is assumed to come from some other source, and providers need to handle invalidation (and permanent storage, if desirable) manually. Thus, metadata would be a better fit in theory, but I don't think it offers any mechanism currently for extensions to hook into it. So I don't think you are any worse off by writing a self-contained extension. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] new extension
Il 19/01/2015 19:00, Tyler Romeo ha scritto: On Wed, Dec 17, 2014 at 11:57 AM, Ricordisamoa ricordisa...@openmailbox.org wrote: * Given that the W3C Validator can also parse HTML files, would it be useful to validate wiki pages as well? Even if sometimes the validation errors appear to be caused by MediaWiki itself, they can also depend on malformed templates. Meh not sure how useful this would be. Maybe as a developer tool, but not something you would want running on your site. The SVG validation tool makes sense because you're validating user input. * Does storing the validation status of old revisions of images (and/or articles) make sense? I don't think there's any harm in it. Better to have extraneous information then to wait until users complain about not having it down the line. * Do you think the extension should use the extmetadata property of ApiQueryImageInfo instead of a its own module? * Is it advisable to store validation data permanently in the database? I have no idea about this, but it does seem that the metadata is propagated to the oldimage table when a new one is uploaded, so it would fulfill your above question about storing old revisions' validation status. Exactly what information is being stored? Is it just a flag that says valid or not valid? Is it a list of errors and warnings? If so what format is it all in? They're instances of Services_W3C_HTMLValidator_Response, as returned by Services_W3C_HTMLValidator https://github.com/pear/Services_W3C_HTMLValidator, containing the boolean validity, the lists of errors and warnings with machine-readable information, etc., stored in the object cache. When requested via the API, they are converted to plain arrays. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] new extension
On Wed, Dec 17, 2014 at 11:57 AM, Ricordisamoa ricordisa...@openmailbox.org wrote: * Given that the W3C Validator can also parse HTML files, would it be useful to validate wiki pages as well? Even if sometimes the validation errors appear to be caused by MediaWiki itself, they can also depend on malformed templates. Meh not sure how useful this would be. Maybe as a developer tool, but not something you would want running on your site. The SVG validation tool makes sense because you're validating user input. * Does storing the validation status of old revisions of images (and/or articles) make sense? I don't think there's any harm in it. Better to have extraneous information then to wait until users complain about not having it down the line. * Do you think the extension should use the extmetadata property of ApiQueryImageInfo instead of a its own module? * Is it advisable to store validation data permanently in the database? I have no idea about this, but it does seem that the metadata is propagated to the oldimage table when a new one is uploaded, so it would fulfill your above question about storing old revisions' validation status. Exactly what information is being stored? Is it just a flag that says valid or not valid? Is it a list of errors and warnings? If so what format is it all in? *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] new extension
Anybody interested? Il 30/12/2014 10:11, Ricordisamoa ha scritto: Il 17/12/2014 17:57, Ricordisamoa ha scritto: I've written a simple MediaWiki extension that uses an instance of the W3C Validator service (via the Services_W3C_HTMLValidator http://pear.php.net/package/Services_W3C_HTMLValidator PEAR package) to validate SVG images hosted on a wiki. It is meant to replace the current system on Commons, that relies on individual contributors adding templates (e.g. InvalidSVG https://commons.wikimedia.org/wiki/Template:InvalidSVG) by hand to file description pages. It exposes a simple API (and a Scribunto module as well) to get the validation status of existing SVG files, can emit warnings when trying to upload invalid ones, and is well integrated with MediaWiki's native ObjectCache mechanism. I'm in the process of publishing the code, but have some questions I think the community could help me answer. * Given that the W3C Validator can also parse HTML files, would it be useful to validate wiki pages as well? Even if sometimes the validation errors appear to be caused by MediaWiki itself, they can also depend on malformed templates. * Does storing the validation status of old revisions of images (and/or articles) make sense? * Do you think the extension should use the extmetadata property of ApiQueryImageInfo instead of a its own module? * Is it advisable to store validation data permanently in the database? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Also, could validation results be exposed from the 'file' key of the mw.title table instead of a custom module? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] new extension
Il 17/12/2014 17:57, Ricordisamoa ha scritto: I've written a simple MediaWiki extension that uses an instance of the W3C Validator service (via the Services_W3C_HTMLValidator http://pear.php.net/package/Services_W3C_HTMLValidator PEAR package) to validate SVG images hosted on a wiki. It is meant to replace the current system on Commons, that relies on individual contributors adding templates (e.g. InvalidSVG https://commons.wikimedia.org/wiki/Template:InvalidSVG) by hand to file description pages. It exposes a simple API (and a Scribunto module as well) to get the validation status of existing SVG files, can emit warnings when trying to upload invalid ones, and is well integrated with MediaWiki's native ObjectCache mechanism. I'm in the process of publishing the code, but have some questions I think the community could help me answer. * Given that the W3C Validator can also parse HTML files, would it be useful to validate wiki pages as well? Even if sometimes the validation errors appear to be caused by MediaWiki itself, they can also depend on malformed templates. * Does storing the validation status of old revisions of images (and/or articles) make sense? * Do you think the extension should use the extmetadata property of ApiQueryImageInfo instead of a its own module? * Is it advisable to store validation data permanently in the database? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Also, could validation results be exposed from the 'file' key of the mw.title table instead of a custom module? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] new extension
I've written a simple MediaWiki extension that uses an instance of the W3C Validator service (via the Services_W3C_HTMLValidator http://pear.php.net/package/Services_W3C_HTMLValidator PEAR package) to validate SVG images hosted on a wiki. It is meant to replace the current system on Commons, that relies on individual contributors adding templates (e.g. InvalidSVG https://commons.wikimedia.org/wiki/Template:InvalidSVG) by hand to file description pages. It exposes a simple API (and a Scribunto module as well) to get the validation status of existing SVG files, can emit warnings when trying to upload invalid ones, and is well integrated with MediaWiki's native ObjectCache mechanism. I'm in the process of publishing the code, but have some questions I think the community could help me answer. * Given that the W3C Validator can also parse HTML files, would it be useful to validate wiki pages as well? Even if sometimes the validation errors appear to be caused by MediaWiki itself, they can also depend on malformed templates. * Does storing the validation status of old revisions of images (and/or articles) make sense? * Do you think the extension should use the extmetadata property of ApiQueryImageInfo instead of a its own module? * Is it advisable to store validation data permanently in the database? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: OnlyRecentRecentChanges
The extension [1] changes the RC view so that any changed article is only listed *once*. Are you aware that Preferences has an option to do something similar? Group changes by page in recent changes and watchlist (requires JavaScript) DanB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: OnlyRecentRecentChanges
Am 12.08.2013 16:18, schrieb Daniel Barrett: The extension [1] changes the RC view so that any changed article is only listed *once*. Are you aware that Preferences has an option to do something similar? Group changes by page in recent changes and watchlist (requires JavaScript) D Yes, I do know this. I have the discussion since 2004 when I joined the MediaWiki developer team This Javascript thing you mean does it differently: - all RC versions are sent from the server to the client, which costs the full bandwidth. - and, worse, changed pages are listed at least still once per day when a change happened. My extension shows only one entry per changed pages, and sends really only the last change to the client. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] New extension: OnlyRecentRecentChanges
The extension [1] changes the RC view so that any changed article is only listed *once*. A new *option* on the preferences Recent changes tab is added which allows users to have - each change (default) or - only the most recent change per changed page shown in the RC list. Code on GitHub, see [1] (request for MW extension repo is filed on https://www.mediawiki.org/wiki/Git/New_repositories/Requests ) [1] https://www.mediawiki.org/wiki/Extension:OnlyRecentRecentChanges ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Special:ExtensionStatus (opinions?)
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 innocentkil...@gmail.com wrote: On Tue, May 14, 2013 at 2:59 AM, K. Peachey p858sn...@gmail.com wrote: On Tue, May 14, 2013 at 4:43 PM, Matthew Flaschen mflasc...@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@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! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Special:ExtensionStatus (opinions?)
On Fri, May 17, 2013 at 11:15 AM, Moriel Schottlender mor...@gmail.com wrote: You can see a screenshot of the current working version here: http://www.mediawiki.org/wiki/File:Extstatus_screenshot.png Please license your uploads to the wiki correctly (or more preferably update to commons!). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Special:ExtensionStatus (opinions?)
On 05/14/2013 01:59 AM, Tyler Romeo wrote: On Tue, May 14, 2013 at 1:57 AM, Moriel Schottlender mor...@gmail.comwrote: 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. Or set up some caching on Gitweb, so it's usable for this kind of thing. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Special:ExtensionStatus (opinions?)
On Tue, May 14, 2013 at 4:43 PM, Matthew Flaschen mflasc...@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). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Special:ExtensionStatus (opinions?)
Am 14.05.2013 08:43, schrieb Matthew Flaschen: Or set up some caching ... +1 for _/*caching */_(like for RSS feeds) See Extension:RSS, for example. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Special:ExtensionStatus (opinions?)
On Tue, May 14, 2013 at 2:59 AM, K. Peachey p858sn...@gmail.com wrote: On Tue, May 14, 2013 at 4:43 PM, Matthew Flaschen mflasc...@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Special:ExtensionStatus (opinions?)
On Sun, 12 May 2013 21:26:42 -0700, Moriel Schottlender mor...@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/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Special:ExtensionStatus (opinions?)
On Mon, May 13, 2013 at 2:21 AM, Daniel Friesen dan...@nadir-seen-fire.comwrote: * 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. 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! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Special:ExtensionStatus (opinions?)
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 mor...@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. 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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Special:ExtensionStatus (opinions?)
On Sun, 12 May 2013 23:35:12 -0700, Moriel Schottlender mor...@gmail.com wrote: On Mon, May 13, 2013 at 2:21 AM, Daniel Friesen dan...@nadir-seen-fire.comwrote: 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/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Special:ExtensionStatus (opinions?)
On Mon, May 13, 2013 at 2:44 AM, Yury Katkov katkov.ju...@gmail.com wrote: 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. 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! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Special:ExtensionStatus (opinions?)
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-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Moriel Schottlender Gesendet: Montag, 13. Mai 2013 06:27 An: wikitech-l@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Special:ExtensionStatus (opinions?)
On Mon, May 13, 2013 at 4:06 AM, Markus Glaser gla...@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! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Special:ExtensionStatus (opinions?)
On 2013-05-13 5:16 AM, Moriel Schottlender mor...@gmail.com wrote: On Mon, May 13, 2013 at 4:06 AM, Markus Glaser gla...@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! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l 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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Special:ExtensionStatus (opinions?)
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 bawo...@gmail.com wrote: On 2013-05-13 5:16 AM, Moriel Schottlender mor...@gmail.com wrote: On Mon, May 13, 2013 at 4:06 AM, Markus Glaser gla...@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! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l 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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Aarti K. Dwivedi ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Special:ExtensionStatus (opinions?)
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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Special:ExtensionStatus (opinions?)
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 m...@everybody.orgwrote: 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 -- 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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Special:ExtensionStatus (opinions?)
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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Special:ExtensionStatus (opinions?)
On Sun, May 12, 2013 at 11:26 PM, Moriel Schottlender mor...@gmail.comwrote: 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. 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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Special:ExtensionStatus (opinions?)
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 rlan...@gmail.com wrote: On Sun, May 12, 2013 at 11:26 PM, Moriel Schottlender mor...@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. 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. 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@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! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Special:ExtensionStatus (opinions?)
On Tue, May 14, 2013 at 1:57 AM, Moriel Schottlender mor...@gmail.comwrote: 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 | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Diff
2012/9/26 Tim Starling tstarl...@wikimedia.org: On 26/09/12 03:54, Tyler Romeo wrote: This looks pretty interesting. Is there a reason we don't just put this in the core? It has about 50 lines of useful code wrapped in 1600 lines of abstraction. I don't think it is the sort of style we want in the core. I am sorry, but I find this comment a bit harsh, and just wanted to deliver some data on that. Maybe it was meant as a hyperbole, in which case I apologize for not treating it as such. The extension has, altogether 2846 total lines of code in 24 files, of which 332 lines are blank, 1328 lines are comments, and 1186 are physical lines of code. Of the latter 1186, 641 are tests. I find that commendable. (That leaves us with 1663 total lines of code, which are probably the 1600 from the original comment) Another 148 physical lines go to initializing the extension and internationalization. Remain 402 physical lines of code. Now, one might discuss the suitability of using interfaces in PHP, but we have that in core: IDBAccessObject, ICacheHelper, IDeviceDetector, and a few others. Not many, but they exist. Anyway, the two interface classes account for only 18 physical lines of code anyway. The only 18 lines a user of the extension needs to care about. One might discuss the suitability of using a class hierarchy to represent different DiffOps. But then again, that is the same class design as in the DairikiDiff engine, included in core as well. There sure are other design choices that can be discussed. But the picture painted above was exaggerated, and I merely wanted to add some data to it. Cheers, Denny P.S.: terminology: total lines of code - lines in all code files, physical lines of code every line that has at least one non-comment or non-whitespace character. All numbers according to cloc. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Diff
Hey, Is there a reason we don't just put this in the core? One of the reasons is that from my experience the MediaWiki core dev community is not very open to such things. I think Tim is illustrating the point pretty well, by implying what I did is total nonsense. Having tried to get this into core would have lead to more insults getting thrown at my head. Of course this is nonsense, as I'm sure some core developer will point out in a reply. Another reason is that although this is a rather generic diff utility, the number of extensions that could make use of this seems rather limited. And I don't think we want to just put any generic component into core without good reason. It has about 50 lines of useful code wrapped in 1600 lines of abstraction. I don't think it is the sort of style we want in the core. Unsurprisingly I'm going to Agree with Denny that this is rather harsh. This kind of attitude is not very welcoming to other developers, especially if you make such comments where they are not applicable. And yes, I'm going to maintain it's not applicable. Being the genius that you are, I challenge you to put your money where your mount is to write a 50 line extension that offers the same functionality as this extension. One might discuss the suitability of using a class hierarchy to represent different DiffOps. But then again, that is the same class design as in the DairikiDiff engine, included in core as well. Although you find small things to nitpick over, I'm confident the overall design is sound. The Diff and DiffOps are following the composite pattern, which seems very much like the right choice to me. I would not mind being proven wrong or having other constructive discussion though. This is crap is not constructive. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Diff
On Sep 25, 2012, at 7:54 PM, Tyler Romeo tylerro...@gmail.com wrote: Is there a reason we don't just put this in the core? Many points have been made already in a short amount of time, which emphasizes how touchy this subject can be. Anyway, a different view that I haven't heard as much is the following. Being in core is not a stamp of approval. This picture never existed and if it did, it needs to go away. We're going towards a flexible modular system, which means components have dependencies and build on each other - as opposed to just being there. So unless other existing core functionality would need it, it doesn't make sense to include it. Instead, extensions should prove themselves. If an extension provides functionality that other extensions need, those other extensions will simply add Make sure X and Y is installed first to their instructions and use it that way. This gives a few advantages: * Fair competition. Extensions can decide that they want to use, make it also easy for developers to fork a utility and improve it (like extensions do). * Flexibility. Once it is in core, we have to support it, which is especially awkward if it isn't in use, because that means we have an untracked dependency on something we don't even use, and can't be easily replaced either because some extension might use it, somehow. It goes at the cost of not having a standard, but I'm not sure a blanket standard now, must use this is what we want here, at least not until it has proven itself by being used over a long period of time by other extensions. I mean, things don't have to be in core to be usable. Let it be an extension, let it grow. Extensions can perfectly depend on other extensions, there is no need to have it be in core, make your own decisions. -- Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Diff
So unless other existing core functionality would need it, it doesn't make sense to include it. This makes sense. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Wed, Sep 26, 2012 at 1:54 PM, Krinkle krinklem...@gmail.com wrote: So unless other existing core functionality would need it, it doesn't make sense to include it. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] New extension: Diff
Hey, I'm happy to announce the first release of a new little extension I wrote called Diff. https://www.mediawiki.org/wiki/Extension:Diff It's a small utility library which might be of use to anyone creating a new extension :) Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Diff
This looks pretty interesting. Is there a reason we don't just put this in the core? *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Tue, Sep 25, 2012 at 6:50 AM, Jeroen De Dauw jeroended...@gmail.comwrote: Hey, I'm happy to announce the first release of a new little extension I wrote called Diff. https://www.mediawiki.org/wiki/Extension:Diff It's a small utility library which might be of use to anyone creating a new extension :) Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Diff
On 26/09/12 03:54, Tyler Romeo wrote: This looks pretty interesting. Is there a reason we don't just put this in the core? It has about 50 lines of useful code wrapped in 1600 lines of abstraction. I don't think it is the sort of style we want in the core. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New Extension in SVN: Suhosin (for the Hardenend-PHP versions with Suhosin extension)
Regarding my extension for dynamic adaption of $wgResourceLoaderMaxQueryLength in accordance to current suhosin parameter in php.ini it is correct to assume such a format http://example.com/?name1=value1name2=value2name3=value3 i.e. $wgResourceLoaderMaxQueryLength = the max. total length of query stream = ( (max. length of names) + (max. length of values) + 2 ) * ( max. number of name/value pairs ) Rusty wrote $wgResourceLoaderMaxQueryLength limits the *total* length of *all* names and values. Can you confirm ? signature.asc Description: OpenPGP digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New Extension in SVN: Suhosin (for the Hardenend-PHP versions with Suhosin extension)
On Sat, Feb 18, 2012 at 10:12 AM, Thomas Gries m...@tgries.de wrote: Can you confirm ? I think the real problem is that $wgResourceLoaderMaxQueryLength is insufficient for the configuration you desire. It only loosely correlates with the problem it seems intended to resolve. Assuming both the number of key/value pairs and the length of each key resource loader uses is bounded and small, a new configuration variable to control the maximum value length would be useful for your purposes. ~Rusty ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] New Extension in SVN: Suhosin (for the Hardenend-PHP versions with Suhosin extension)
For the Hardenend-PHP versions with Suhosin extension, I wrote a tiny extension https://www.mediawiki.org/wiki/Extension:Suhosin which is easier to link into LocalSettings for those who need it. Basically, after some checks, it sets $wgResourceLoaderMaxQueryLength=min($wgResourceLoaderMaxQueryLength,ini_get(suhosin.get.max_name_length)); Please check that version for unintended side-effects, I hope there are none. Tom [1] https://www.mediawiki.org/wiki/Extension:Suhosin [2] https://www.mediawiki.org/wiki/Manual:Suhosin_%28Hardened-PHP_Project_patch_and_extension%29 signature.asc Description: OpenPGP digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New Extension in SVN: Suhosin (for the Hardenend-PHP versions with Suhosin extension)
On Thu, Feb 16, 2012 at 3:54 PM, Thomas Gries m...@tgries.de wrote: Basically, after some checks, it sets $wgResourceLoaderMaxQueryLength=min($wgResourceLoaderMaxQueryLength,ini_get(suhosin.get.max_name_length)); That doesn't look right. http://www.hardened-php.net/suhosin/configuration.html#suhosin.get.max_name_length suhosin.get.max_name_length defaults to 64 because that is only testing the length of a single key in the URL. There doesn't appear to be a straightforward mapping between Suhosin config and $wgResourceLoaderMaxQueryLength. For example, this calculation appears to produce the maximum query string length (including the ?). suhosin.get.max_vars * (suhosin.get.max_totalname_length + suhosin.get.max_value_length + 1) + suhosin.get.max_vars However, all likely occurrences of query strings at that length will fail the Suhosin filters (because there will be many more, smaller keys/values). In any case, 64 as a limit for $wgResourceLoaderMaxQueryLength seems much to small. ~Rusty ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New Extension in SVN: Suhosin (for the Hardenend-PHP versions with Suhosin extension)
Am 17.02.2012 01:38, schrieb Rusty Burchfield: On Thu, Feb 16, 2012 at 3:54 PM, Thomas Gries m...@tgries.de wrote: Basically, after some checks, it sets $wgResourceLoaderMaxQueryLength=min($wgResourceLoaderMaxQueryLength,ini_get(suhosin.get.max_name_length)); I corrected that already, it must be suhosin.get.max_value_length . signature.asc Description: OpenPGP digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New Extension in SVN: Suhosin (for the Hardenend-PHP versions with Suhosin extension)
On Thu, Feb 16, 2012 at 4:41 PM, Thomas Gries m...@tgries.de wrote: Am 17.02.2012 01:38, schrieb Rusty Burchfield: On Thu, Feb 16, 2012 at 3:54 PM, Thomas Gries m...@tgries.de wrote: Basically, after some checks, it sets $wgResourceLoaderMaxQueryLength=min($wgResourceLoaderMaxQueryLength,ini_get(suhosin.get.max_name_length)); I corrected that already, it must be suhosin.get.max_value_length . I don't believe that is correct either. This is what name and value represent to Suhosin. http://example.com/?name1=value1name2=value2 In this example, both values are 6 characters long, and the entire query string is 26 characters. ResourceLoader uses many names and values in each URL. As long as individual names and values are under the configured limits, the URL is OK. However, $wgResourceLoaderMaxQueryLength limits the *total* length of *all* names and values. ~Rusty ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New Extension in SVN: Suhosin (for the Hardenend-PHP versions with Suhosin extension)
Hello, the extension has been also published with the intention that those who feel competent improve it. signature.asc Description: OpenPGP digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] new extension in SVN: EtherpadLite
awesome! On Sun, Feb 12, 2012 at 3:08 AM, Thomas Gries m...@tgries.de wrote: https://www.mediawiki.org/wiki/Extension:EtherpadLite ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] new extension in SVN: EtherpadLite
https://www.mediawiki.org/wiki/Extension:EtherpadLite signature.asc Description: OpenPGP digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] New extension: Validator
Hey, I'd like to introduce everyone to an extension called Validator [0] that I wrote over the past few months and aims to facilitate parameter handling for other extensions. I developed it for usage in the Maps and Semantic Maps extensions, as I thought it would be nice to have a less messy way of creating parser hooks. It's now at a point where it can be used by other extensions, without having to worry about compatibility to much. For a more detailed explanation of what Validator does, check out the functionality overview section [1] on the extension page. I encourage all extension authors to have a look at it, especially if you are considering creating a new extension where you have to deal with user-provided parameters, to see if this can help you. Feedback is welcome :) [0] http://www.mediawiki.org/wiki/Extension:Validator [1] http://www.mediawiki.org/wiki/Extension:Validator#Functionality_overview Cheers -- Jeroen De Dauw * http://blog.bn2vs.com * http://wiki.bn2vs.com Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65! -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Validator
* Jeroen De Dauw jeroended...@gmail.com [Fri, 15 Oct 2010 23:08:21 +0200]: Hey, I'd like to introduce everyone to an extension called Validator [0] that I wrote over the past few months and aims to facilitate parameter handling for other extensions. I developed it for usage in the Maps and Semantic Maps extensions, as I thought it would be nice to have a less messy way of creating parser hooks. It's now at a point where it can be used by other extensions, without having to worry about compatibility to much. For a more detailed explanation of what Validator does, check out the functionality overview section [1] on the extension page. That explanation is way too short, certainly not detailed enough. Some samples of usage can be presented, for example. I encourage all extension authors to have a look at it, especially if you are considering creating a new extension where you have to deal with user-provided parameters, to see if this can help you. Feedback is welcome :) [0] http://www.mediawiki.org/wiki/Extension:Validator [1] http://www.mediawiki.org/wiki/Extension:Validator#Functionality_overview API also has a nice parameters definition / validation / description features. I wonder whether these can be used outside of API, though. I wonder whether that should be a part of core. Especially integrated into WebRequest / FauxRequest, it can be more powerful and routing-like. Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] New extension: CategoryMultisort
Hi, I created a new extension (a part of a set of extensions), which is intended for improving categorization in complex languages such as Chinese by supporting sorting pages in a category in more than way, and is expected to be installed on Chinese Wikipedia. This extension is a common part of all languages. Chinese-specific part will be done in another extension, with the hook, CategoryMultisortSortkeys, specified in this extension. Please have a look at it. Repo on Gitorious: http://gitorious.org/mediawiki-categorymultisort Extension page on MediaWiki.org: http://www.mediawiki.org/wiki/Extension:CategoryMultisort --Liangent ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] new extension for embedded music scores
On Tue, May 26, 2009 at 11:49 PM, Birgitte SB birgitte...@yahoo.com wrote: That wouldn't be very useful for Wikisource purposes. We need something editable. I was assuming the user would include the LilyPond source along with the image. As I did here, for example: http://en.wikipedia.org/wiki/File:Chopin_theme_op_28.png Is there an official way to do this? I wasn't sure whether Commons or Wikisource was the right place? (I ended up at en as I wasn't sure about the copyright status...in the end I think almost all Chopin is PD). Steve ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] new extension for embedded music scores
On Sun, Nov 9, 2008 at 5:25 AM, River Tarnell ri...@loreley.flyingparchment.org.uk wrote: http://abc.sourceforge.net/ You know what would be useful? A website that lets you input ABC (or LilyPond, for that matter) text, and produces an image as output. Hence avoiding the need to download and install it. Does such a thing exist? Steve ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] new extension for embedded music scores
On Sun, May 24, 2009 at 11:29 PM, Steve Bennett stevag...@gmail.com wrote: You know what would be useful? A website that lets you input ABC (or LilyPond, for that matter) text, and produces an image as output. Hence avoiding the need to download and install it. Does such a thing exist? http://www.concertina.net/tunes_convert.html does a low-res JPEG version; http://www.abc-notation.com/abcapp/list.html?phrase=system=Onlinefunction=all lists others. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] new extension for embedded music scores
2008/10/28 River Tarnell ri...@loreley.flyingparchment.org.uk: i have written a new extension to embed music scores in MediaWiki pages: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Extension:ABC i would be interested to hear peoples' thoughts on enabling this extension on Wikimedia. Is there any progress with this extension? There are some interested users in Hungarian Wikisource. D. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] new extension for embedded music scores
On Fri, May 22, 2009 at 8:50 AM, Tar Dániel bdane...@gmail.com wrote: Is there any progress with this extension? There are some interested users in Hungarian Wikisource. Tim has said he might enable it after the 1.15 release and the next scap. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
