On Thu, May 8, 2008 at 11:27 AM, Sergey Chernyshev wikitech-l@antispam.sergeychernyshev.com wrote:

I was hesitant to add my extensions to MW repository for it's lack of tagging and branching (obviously it's limited because it's one big repo for all code).

We have tags and branches.

On Thu, May 8, 2008 at 12:22 PM, Sergey Chernyshev wikitech-l@antispam.sergeychernyshev.com wrote:

But not for extensions themselves, just for the main code right?

Committers are free to create whatever tags or branches they like. In practice, nobody does, but there's no reason that has to be the case.

On Thu, May 8, 2008 at 12:41 PM, Siebrand Mazeland s.mazeland@xs4all.nl wrote:

Exception to the rule was the branch Evan created for the rewrite of the OpenID extension recently. So it *is* actually being done...

LuceneSearch-ajax is a branch used by an extension. Evan is tagging his releases, you're right, although no one else is at present:

http://svn.wikimedia.org/viewvc/mediawiki/tags/extensions/OpenID/

Sergey Chernyshev schreef:

I really prefer to have my extensions in MW repository - so the next question then is what are the guidelines for SVN usage for Extension developers (especially tagging so developers of code-rich extensions like Semantic Forms and Semantic MediaWiki can use it),

The idea is that you put your extension in /mediawiki/trunk/extensions/ExtensionName/ . How you organize that directory is more or less up to you, although there is a convention to call the setup file (the one that's included in LocalSettings.php) ExtensionName.setup.php or ExtensionName.php , the file with the interface messages and their translations ExtensionName.i18n.php and the file with the actual code ExtensionName.body.php . Larger extensions will probably want to put classes in their own files, and put the 'main' code flow in the .body.php file.

and how does one get commit access to the repository ;)

Ask Brion Vibber. To quote him, commit access is granted to everyone who asks for it and has shown they're not a baboon. In practice, that means either having submitted a few patches to BugZilla or maintaining an extension.

Also, can you guys import a project from another repository, e.g. Google code hosting (first two in line will be "Header Tabs" and "Widgets" extensions)?

Importing the files in their current state is pretty easy. Importing the files with history is probably gonna be tricky.

Roan Kattouw (Catrope)

Sergey Chernyshev schreef:

I think it's not a big deal for my extensions to be moved over without history because there is not much history there - just a few releases.

In that case checking in your extension is simple. After you've been given commit access, check out the extensions/ directory, create a new directory inside it and copy your code there. Then add your directory ('svn add' on the command line or right-click->Add in TortoiseSVN) and commit your changes. You could of course tag your previous releases.

My main question is about release tags - do I just tag the like http://svn.wikimedia.org/viewvc/mediawiki/tags/extensions/Widgets/REL_0_5/

Well, yeah. SVN doesn't support tags as natively as some other version control systems do. The idea is that you just create a directory and copy your files there. The nice thing here is that SVN makes shallow copies: i.e. it doesn't actually copy the files, it just registers that the tagged file's content is identical to a previous version of another file, saving disk space. The "don't touch release tags - ever" thing means that you shouldn't ever touch an existing tag, unless you have very good reasons to (those reasons usually include being the one who created the tag in the first place).

Roan Kattouw (Catrope)

Dan, thanks for this long overview, is there a wiki page on MediaWiki.org that describes all this? If not, I'll just refactor your email to a page if you don't mind.

It probably also makes sense to maintain some boilerplate code as well so new developers can have an easy start.

Sergey

On Fri, May 9, 2008 at 11:49 AM, DanTMan dan_the_man@telus.net wrote:

Magic Words also normally go in a: ExtensionName.i18n.magic.php

And for special pages: Special/SpecialPageName/.php and the class name should be the exact same as the filename without the .php

For the i18n files you also use $messages and $words for the magic word ones.

There are also some semi-enforced conventions in coding... What I kind of refer to as 'Standards' when I offer to help fix up an extension.

For the most part those are things like:

• Use $wgSpecialPages, not SpecialPage::addPage because the former is

less weight and the latter is depreciated.

• Use wfLoadMessage and a i18n file rather than using the

ExtensionFunction to load all the messages in. This improves performance as well.

• The standard of ExtensionName(.setup).php, and such is mildly enforced

to... I've seen Tim take a number of old extensions and change them to reflect the standard among extensions.

• Comment your files with a license or add a LICENSE or COPYING file.

Only Free-License stuff goes into SVN so it should be marked as such.

• It's not written or really enforced or anything, but it's common and

good to see people using @author, @license, etc... to mark files.

• Add your extension into $wgExtensionCredits to mark that it's

installed. And it's good to give it a url linking to a page where it's documented.

• Check if the 'MEDIAWIKI' is not defined! It's a security issue if

that's not there and you're running php code, so it's bad to see files without that. I developed the habit of putting the line into i18n files to, though don't know if other people do.

• Use $wgAutoloadClasses rather than loading php files directly.
• Use dirname(__FILE__) to determine the path to use for including

files. Don't rely on the include path, it can be a potential security issue, but mainly, it adds more stat calls. One of Wikia's techs was complaining that MediaWiki makes around 3000 stat calls trying to find php files on each load and it slows things down.

• This is a new one, but if you have maintenance scripts in your

extension, they should make use of the MW_INCLUDE_PATH environment variable if set when including things in the maintenance directory, and dirname(__FILE__) when including other files inside the extension. See CheckUser < http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/CheckUser/install...

...

.

• Don't do what SMW did with it's setup script

< http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/SemanticMediaWiki...

...

,

making the user specify database user and password instead of using AdminSettings.php is a major security flaw which is completely avoidable. And the same goes for implying that the wiki's database user should have administrative permissions like CREATE, DROP, and ALTER.

• Another one I drilled SMW on was temporary tables. When you are using

temporary tables, never use 'DROP' alone, you always use 'DROP TEMPORARY', not only is it a safety to ensure you don't remove a real table, if you don't use TEMPORARY then the wiki's database user is required to have DROP permissions which is not secure. And there isn't even any backwards compatibility issues. MySQL 4.0 ignores the TEMPORARY so you won't break it.

Just a few off ones which are good to follow:

• If your ParserFunctions do conditional things, use the dom frames in

the new parser. Take a look at ParserFunctions < http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/ParserFunctions/P...

...

to see how to.

The tricky thing about the conventions/standards is that they evolve, so you don't always know if part of your own convention is being outdated by something new in core.

There is one nice handy feature of core that I really wish extension would actually make use of. I see SMW, CheckUser, and piles of other extensions which require new SQL and some setup. Some give you a SQL file to run raw (Actually, they say to run it raw... But MediaWiki has a patchSql.php maintenance script which you should actually run because it handles your variables and such on it's own), and some others make an installation script for the extension to handle SQL. However, there is a very nice hook inside of MediaWiki I wish people would use more.

For quite some time updaters.inc has had a LoadExtensionSchemaUpdates hook. And the globals $wgExtNewTables, $wgExtNewFields, $wgExtPGNewFields, and $wgExtNewIndexes all for extensions. And while I don't know if it's something which is discouraged or not, but $wgMysqlUpdates could be appended to if you need a function called back to do schema stuff. Though, I expect that it's best if we tweaked updaters.inc to support a $wgExtMysqlUpdates and $wgExtPGUpdates for those. I honestly don't see people using them. But they would be great things to use. They're hooks and they're included into the updaters.inc file. All you'd have to do is hook into it and populate a few fields, and magically anyone wanting to install your extension would only need to include it into LocalSettings.php then run update.php.

~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)

Roan Kattouw wrote:

...

Sergey Chernyshev schreef:

...

I really prefer to have my extensions in MW repository - so the next question then is what are the guidelines for SVN usage for Extension developers (especially tagging so developers of code-rich extensions

like

...

...

Semantic Forms and Semantic MediaWiki can use it),

The idea is that you put your extension in /mediawiki/trunk/extensions/ExtensionName/ . How you organize that directory is more or less up to you, although there is a convention to call the setup file (the one that's included in LocalSettings.php) ExtensionName.setup.php or ExtensionName.php , the file with the interface messages and their translations ExtensionName.i18n.php and the file with the actual code ExtensionName.body.php . Larger extensions will probably want to put classes in their own files, and put the 'main' code flow in the .body.php file.

...

and how does one get commit access to the repository ;)

Ask Brion Vibber. To quote him, commit access is granted to everyone who asks for it and has shown they're not a baboon. In practice, that means either having submitted a few patches to BugZilla or maintaining an extension.

...

Also, can you guys import a project from another repository, e.g. Google code hosting (first two in line will be "Header Tabs" and "Widgets" extensions)?

Importing the files in their current state is pretty easy. Importing the files with history is probably gonna be tricky.

Roan Kattouw (Catrope)

https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Dan,

I think it's perfectly fine to create this documentation within MediaWiki.org - there is no need for special features on the site, just documentation, right? It seems to be a natural place to search for such information.

As for code generator, I think it's an overkill to start with such complex thing - getting just boilerplates is a good short first step which will benefit generator once code stabilizes. Moreover, code can be included right into wiki pages instead of SVN to minimize learning curve because people who use SVN are already less prone to coding mistakes then people who just copy/paste and those are the most important people to target.

I also created Widgets extension partially to help eliminate those extensions that just print out some HTML based on the input without employing much of the logic - they all can be replaced with templateing language instead (Widgets uses Smarty). I already converted my SlideShare extension to SlideShare widget to start with.

I'll be happy to be a user of such documentation and best practices documents and help "debug" them ;)

Sergey

On Fri, May 9, 2008 at 3:15 PM, DanTMan dan_the_man@telus.net wrote:

Unfortunately there really isn't good documentation on creating extensions for MediaWiki. And a lot of the existing documentation is badly out of date. (This is kind of the reason why we still see a lot of use of the SpecialPage::addPage method when it has been depreciated).

Actually, JaeSharp once poked me to help start on creating a good source of help. I've got SMW and a good setup, cept I need to get God to watch PHP to keep it alive. I could create a developer help wiki for MediaWiki.

^_^ As for the boilerplate code... Honestly, JaeSharp was planning on creating a kind of generator code... Like how rails has generators to create scaffolding (models, views, and controllers which already work out of the box). That way extension developers could simply run a script with the name of their extension, and a bit of input on what kind of things they are using... Do they want it to not output i18n files, any special pages to create, any parserfunctions that need a i18n.magic, or extension class. And create relevant files from that.

~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)

Sergey Chernyshev wrote:

...

Dan, thanks for this long overview, is there a wiki page on MediaWiki.org that describes all this? If not, I'll just refactor your email to a page

if

...

you don't mind.

It probably also makes sense to maintain some boilerplate code as well so new developers can have an easy start.

     Sergey

Yeh, I was actually surprised that there were no abstract classes to base extensions on, but this might actually be good if flexibility is needed - we don't know what people would want to extend and at some level using abstract class might reduce possibilities, although it this class is not mandatory, then it's a good help for new developers.

I think starting with some code that people can reuse might be a good first step to identifying the right structure of classes, although I have quite little experience in extension development and there might be a good approach that'll cover most of the cases.

With widgets (which I probably should announce with separate email with thorough description) the idea was to separate the task of backend development and front-end development since vast majority of widgets are just some chunk of HTML and JS. There are still several tasks that backend needs to do, but they all standardized and Smarty is doing most of the work (I had very little idea about various templating frameworks and it was the only one with some authority).

Sergey

On Sun, May 11, 2008 at 5:57 AM, DanTMan dan_the_man@telus.net wrote:

Your idea on widgets is actually a bit similar to something I was thinking about earlier on today.

There are a lot of extensions which do similar things. And a lot of things which have a lot of variance to them. Then there is a fair bit of variance to how certain things are done and handled with extensions. Honestly, some of this makes the idea of a 'Extension Installer' that people propose to be a little tough.

For example, variables are used allot in extension files. However, most of the time none of these are globalized. As a result of this, it is impossible to delegate the inclusion of an extension to a special function made to simplify the task. So, instead we make the one installing the wiki use a cryptic require_once statement. And delegate everything being done to the extension itself forcing it to handle everything. I did entertain the idea in my own time of using: include extension('CheckUser'); ^_^ Of course, that's a little bit of a visual hack I came up with. 'extension' would be an actual function. Designed with the task of outputting a string for inclusion of an extension. Nonexistant extensions and such would be handled by a die statement inside of it... Or even better, I could let a configuration option make the function silently pass nonexistant extensions over by passing the name of an empty but existing file and write out to the debug logs that the extension could not be loaded. ;) If you get the thought, it would mean that accidentally removing the files for an extension wouldn't crash your site, it would just silently work without the extension.

But, that's just a little tangent thought. And it's extremely limited, like how it is limited to only a file, and is required to output that file even if it can't fine one.

My thought was a refactoring on how extensions are actually done. Rather than making extensions a tangent thought where we give them a bunch of hooks they can subscribe to, and beyond that do extremely little to interact with them and simplify how much the extensions actually need to do on their own.

I thought of actually integrating the notion of an 'extension' into core a lot more. One of the ideas was an Extension class.

• An extension subclasses the Extension class with it's own class to

identify itself.

• Because classes are outside of the scope limitations, we can delegate

inclusion of files to anywhere, including functions which are easier for users to understand.

• We can have the extension store it's configuration options inside of

it's own object. -- This makes sure nothing can ever collide with other extension variables or core variables. -- The Extension's class can pass itself into any class that it creates. And as a result let them access the configuration options to use.

• The core Extension class would be preloaded with a number of useful

methods for extensions to use.

While we're at it, there was something that I discussed with TimStarling. Rather than using wfLoadExtensionMessages, and being forced to load every single one of them when we need to find a single message for a MediaWiki: page. There is another potential way to get messages which does not require us to load everything and reduce performance. A lot of extensions use prefixes. And that is a real fair bit of them. Nearly every one in SVN has it's own unique way to start the names of it's own messages unless it's using a basic word. There is potential for an extension to register a message prefix with the system. And then, when MediaWiki needs to find a message, instead of loading all the messages for every extension it would check the name of the message for a registered prefix, and load the messages for the extension if needed. Tim even tells me of some sort of text tree I think it was, which would suit this better than iterating over and entire array to search for a prefix.

As for identification of the extension itself. We could put that kind of data into a method in the extension's class, and instead of using a global set every load, and unreliable if extensions don't identify themselves. We could even list on Special:Version "X unidentified extensions installed."

And, we can even reduce how much is loaded. A lot of extensions repeat functionality of certain things. One type of thing for example is pure Parser Function extensions. Ones made purely to create a new ParserFunction. We could do a number of things with this kind of extension. Firstly, we could subclass the Extension class and preload important types of configuration which these extensions would normally do on their own. Meaning that the actual work needed for extensions this simple would be reduced. And there's something even better. When do we even need parser functions? We need them in the Parser, we need them in the parser, we list them on Special:Version... But honestly, we don't need to load them every page view. And that's what a lot of extensions using the body file tactic do. In fact... We go and register ParserFunctions by making a call to $wgParser for each and every one of them. What if all the things on the page which needed to be parsed were actually already in the cache? We'd have to go and unstub the Parser class just to register a number of parser functions which aren't going to be used. And honestly, while there are still a few messages which are parsed for each page load, it would be quite possible to cache those with the page title and make it so that at some times when viewing MediaWiki you don't need the parser to ever be unstubed. This could be said for a fair number of different things. Why load everything, when only one of those things is needed? So we could potentially group out different things that extensions may add and have the extension setup callbacks of things to load. And so we'll only load various parts of the extension if they are actually needed.

~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)

Sergey Chernyshev wrote:

...

Dan,

I think it's perfectly fine to create this documentation within MediaWiki.org - there is no need for special features on the site, just documentation, right? It seems to be a natural place to search for such information.

As for code generator, I think it's an overkill to start with such

complex

...

thing - getting just boilerplates is a good short first step which will benefit generator once code stabilizes. Moreover, code can be included

right

...

into wiki pages instead of SVN to minimize learning curve because people

who

...

use SVN are already less prone to coding mistakes then people who just copy/paste and those are the most important people to target.

I also created Widgets extension partially to help eliminate those extensions that just print out some HTML based on the input without employing much of the logic - they all can be replaced with templateing language instead (Widgets uses Smarty). I already converted my

SlideShare

...

extension to SlideShare widget to start with.

I'll be happy to be a user of such documentation and best practices documents and help "debug" them ;)

   Sergey

On Fri, May 9, 2008 at 3:15 PM, DanTMan dan_the_man@telus.net wrote:

...

Unfortunately there really isn't good documentation on creating extensions for MediaWiki. And a lot of the existing documentation is badly out of date. (This is kind of the reason why we still see a lot

of

...

...

use of the SpecialPage::addPage method when it has been depreciated).

Actually, JaeSharp once poked me to help start on creating a good

source

...

...

of help. I've got SMW and a good setup, cept I need to get God to watch PHP to keep it alive. I could create a developer help wiki for

MediaWiki.

...

...

^_^ As for the boilerplate code... Honestly, JaeSharp was planning on creating a kind of generator code... Like how rails has generators to create scaffolding (models, views, and controllers which already work out of the box). That way extension developers could simply run a script with the name

of

...

...

their extension, and a bit of input on what kind of things they are using... Do they want it to not output i18n files, any special pages to create, any parserfunctions that need a i18n.magic, or extension class. And create relevant files from that.

~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)

Sergey Chernyshev wrote:

...

Dan, thanks for this long overview, is there a wiki page on

MediaWiki.org

...

...

...

that describes all this? If not, I'll just refactor your email to a

page

...

...

...

if

...

you don't mind.

It probably also makes sense to maintain some boilerplate code as well

so

...

...

...

new developers can have an easy start.

     Sergey

---

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

^_^ The brilliance of an abstract class in this method, is that if it really is to limiting... You can simply cast it off and use the older lower level methods of doing everything.

But the idea here is to use it as a form of Identity, and cut off anything that limits our ability to delegate handling of extensions to internal functions and code which have scope issues.

Another part I forgot to mention, was how you'd be setting up extensions in LocalSettings.php. Obviously with this new method all these long ugly require_once type things is something we don't want.

So, in comes something else. I originally thought of using a function like include_extension, however there are issues with when things are loaded. ^_^ So in comes another global... (:/ Really, we use globals to much... Why not go real OOP put it all inside of a configuration instance and pass that around... Theoretically like that you could even run two instances of MediaWiki during the same request... ;) Can anyone get the hint on how that could be used to pass data from one wiki to another easier; heh, but thats a tangent) something like $wgUseExtensions and to complement it $wgExtensionPaths.

Quite simply the idea was, and you'll see why I say was in a second... that you would add extensions like this: $wgUseExtensions[] = 'CheckUser';

Then the internal code would search for CheckUser/CheckUser.php or CheckUser/CheckUser.setup.php or whatever naming convention we chose for these objects. (Probably best to come up with a different name so that things don't break by loading an old extension in a bad way). Where does it search for them? In the $wgExtensionPaths which defaults to array( "$IP/extensions" ); and because it's an array rather than something singular we still support loading extensions from alternate locations on the system.

^_^ Now for that "was"... Remember that $wgUseExtensions, and how we need to set configuration. The configuration is part of the object, to be specific it's part of an instance. Why not simplify configuration of an extension like this: $wgUseExtensions['WikiVid'] = array( 'ServiceTags' => true ); Which for my WikiVid extension would be the same as the old method of: require_once( "$IP/extensions/wiki-tools/WikiVid/WikiVid.php" ); $wgWikiVidServiceTags = true;

And also, if you later don't want something: $wgUseExtensions['WikiVid'] = false; To remove the extension from the list (before it actually gets loaded though, otherwise that's pointless).

Or if there is no configuration for it: $wgUseExtensions['ParserFunctions'] = true;

Hmmm, so you're using Smarty in MediaWiki? How far did you compare template engines? The Skin system was something we discussed in #mediawiki as something which could use some rewriting. Quite simply Skins aren't meant to be made in PHP. All this performance is nice, but there are issues when your Web Designers need to know how to write PHP to be able to create a skin in HTML. Additionally the actual inclusion of the various styles and scripts could probably use some simplification in order to make updates to what we include more portable.

~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)

Sergey Chernyshev wrote:

Yeh, I was actually surprised that there were no abstract classes to base extensions on, but this might actually be good if flexibility is needed - we don't know what people would want to extend and at some level using abstract class might reduce possibilities, although it this class is not mandatory, then it's a good help for new developers.

I think starting with some code that people can reuse might be a good first step to identifying the right structure of classes, although I have quite little experience in extension development and there might be a good approach that'll cover most of the cases.

With widgets (which I probably should announce with separate email with thorough description) the idea was to separate the task of backend development and front-end development since vast majority of widgets are just some chunk of HTML and JS. There are still several tasks that backend needs to do, but they all standardized and Smarty is doing most of the work (I had very little idea about various templating frameworks and it was the only one with some authority).

     Sergey

On Sun, May 11, 2008 at 5:57 AM, DanTMan dan_the_man@telus.net wrote:

...

Your idea on widgets is actually a bit similar to something I was thinking about earlier on today.

There are a lot of extensions which do similar things. And a lot of things which have a lot of variance to them. Then there is a fair bit of variance to how certain things are done and handled with extensions. Honestly, some of this makes the idea of a 'Extension Installer' that people propose to be a little tough.

For example, variables are used allot in extension files. However, most of the time none of these are globalized. As a result of this, it is impossible to delegate the inclusion of an extension to a special function made to simplify the task. So, instead we make the one installing the wiki use a cryptic require_once statement. And delegate everything being done to the extension itself forcing it to handle everything. I did entertain the idea in my own time of using: include extension('CheckUser'); ^_^ Of course, that's a little bit of a visual hack I came up with. 'extension' would be an actual function. Designed with the task of outputting a string for inclusion of an extension. Nonexistant extensions and such would be handled by a die statement inside of it... Or even better, I could let a configuration option make the function silently pass nonexistant extensions over by passing the name of an empty but existing file and write out to the debug logs that the extension could not be loaded. ;) If you get the thought, it would mean that accidentally removing the files for an extension wouldn't crash your site, it would just silently work without the extension.

But, that's just a little tangent thought. And it's extremely limited, like how it is limited to only a file, and is required to output that file even if it can't fine one.

My thought was a refactoring on how extensions are actually done. Rather than making extensions a tangent thought where we give them a bunch of hooks they can subscribe to, and beyond that do extremely little to interact with them and simplify how much the extensions actually need to do on their own.

I thought of actually integrating the notion of an 'extension' into core a lot more. One of the ideas was an Extension class.

• An extension subclasses the Extension class with it's own class to

identify itself.

• Because classes are outside of the scope limitations, we can delegate

inclusion of files to anywhere, including functions which are easier for users to understand.

• We can have the extension store it's configuration options inside of

it's own object. -- This makes sure nothing can ever collide with other extension variables or core variables. -- The Extension's class can pass itself into any class that it creates. And as a result let them access the configuration options to use.

• The core Extension class would be preloaded with a number of useful

methods for extensions to use.

While we're at it, there was something that I discussed with TimStarling. Rather than using wfLoadExtensionMessages, and being forced to load every single one of them when we need to find a single message for a MediaWiki: page. There is another potential way to get messages which does not require us to load everything and reduce performance. A lot of extensions use prefixes. And that is a real fair bit of them. Nearly every one in SVN has it's own unique way to start the names of it's own messages unless it's using a basic word. There is potential for an extension to register a message prefix with the system. And then, when MediaWiki needs to find a message, instead of loading all the messages for every extension it would check the name of the message for a registered prefix, and load the messages for the extension if needed. Tim even tells me of some sort of text tree I think it was, which would suit this better than iterating over and entire array to search for a prefix.

As for identification of the extension itself. We could put that kind of data into a method in the extension's class, and instead of using a global set every load, and unreliable if extensions don't identify themselves. We could even list on Special:Version "X unidentified extensions installed."

And, we can even reduce how much is loaded. A lot of extensions repeat functionality of certain things. One type of thing for example is pure Parser Function extensions. Ones made purely to create a new ParserFunction. We could do a number of things with this kind of extension. Firstly, we could subclass the Extension class and preload important types of configuration which these extensions would normally do on their own. Meaning that the actual work needed for extensions this simple would be reduced. And there's something even better. When do we even need parser functions? We need them in the Parser, we need them in the parser, we list them on Special:Version... But honestly, we don't need to load them every page view. And that's what a lot of extensions using the body file tactic do. In fact... We go and register ParserFunctions by making a call to $wgParser for each and every one of them. What if all the things on the page which needed to be parsed were actually already in the cache? We'd have to go and unstub the Parser class just to register a number of parser functions which aren't going to be used. And honestly, while there are still a few messages which are parsed for each page load, it would be quite possible to cache those with the page title and make it so that at some times when viewing MediaWiki you don't need the parser to ever be unstubed. This could be said for a fair number of different things. Why load everything, when only one of those things is needed? So we could potentially group out different things that extensions may add and have the extension setup callbacks of things to load. And so we'll only load various parts of the extension if they are actually needed.

~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)

Sergey Chernyshev wrote:

...

Dan,

I think it's perfectly fine to create this documentation within MediaWiki.org - there is no need for special features on the site, just documentation, right? It seems to be a natural place to search for such information.

As for code generator, I think it's an overkill to start with such

complex

...

thing - getting just boilerplates is a good short first step which will benefit generator once code stabilizes. Moreover, code can be included

right

...

into wiki pages instead of SVN to minimize learning curve because people

who

...

use SVN are already less prone to coding mistakes then people who just copy/paste and those are the most important people to target.

I also created Widgets extension partially to help eliminate those extensions that just print out some HTML based on the input without employing much of the logic - they all can be replaced with templateing language instead (Widgets uses Smarty). I already converted my

SlideShare

...

extension to SlideShare widget to start with.

I'll be happy to be a user of such documentation and best practices documents and help "debug" them ;)

   Sergey

On Fri, May 9, 2008 at 3:15 PM, DanTMan dan_the_man@telus.net wrote:

...

Unfortunately there really isn't good documentation on creating extensions for MediaWiki. And a lot of the existing documentation is badly out of date. (This is kind of the reason why we still see a lot

of

...

...

use of the SpecialPage::addPage method when it has been depreciated).

Actually, JaeSharp once poked me to help start on creating a good

source

...

...

of help. I've got SMW and a good setup, cept I need to get God to watch PHP to keep it alive. I could create a developer help wiki for

MediaWiki.

...

...

^_^ As for the boilerplate code... Honestly, JaeSharp was planning on creating a kind of generator code... Like how rails has generators to create scaffolding (models, views, and controllers which already work out of the box). That way extension developers could simply run a script with the name

of

...

...

their extension, and a bit of input on what kind of things they are using... Do they want it to not output i18n files, any special pages to create, any parserfunctions that need a i18n.magic, or extension class. And create relevant files from that.

~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)

Sergey Chernyshev wrote:

...

Dan, thanks for this long overview, is there a wiki page on

MediaWiki.org

...

...

...

that describes all this? If not, I'll just refactor your email to a

page

...

...

if

...

you don't mind.

It probably also makes sense to maintain some boilerplate code as well

so

...

...

...

new developers can have an easy start.

     Sergey

---

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

DanTMan schreef:

Hmmm, so you're using Smarty in MediaWiki? How far did you compare template engines? The Skin system was something we discussed in #mediawiki as something which could use some rewriting. Quite simply Skins aren't meant to be made in PHP. All this performance is nice, but there are issues when your Web Designers need to know how to write PHP to be able to create a skin in HTML. Additionally the actual inclusion of the various styles and scripts could probably use some simplification in order to make updates to what we include more portable.

The DynamicSkin extension does something similar to what you're suggesting.

Roan Kattouw (Catrope)

On Mon, May 12, 2008 at 12:50 PM, Sergey Chernyshev wikitech-l@antispam.sergeychernyshev.com wrote:

Yeh, I was actually surprised that there were no abstract classes to base extensions on, but this might actually be good if flexibility is needed - we don't know what people would want to extend and at some level using abstract class might reduce possibilities, although it this class is not mandatory, then it's a good help for new developers.

We have such an abstract class for authentication. Also, of course, for special pages of various kinds. Many if not most extensions fit more neatly into a procedural hook model than an OO model, as far as I can see.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

DanTMan wrote:

Also remember MinuteElectron was working on an extension manager or such.

Note that this is on hold semi-permanently at the moment, I've got a lot of exams coming up so don't really have the free time to mess about with it.

MinuteElectron.

Simetrical schreef:

Well, no, it really means don't touch them *ever*. They're meant to be particular snapshots. If you release a new version or something, you create a new tag, you don't touch the existing ones. Otherwise it defeats the point; you should just use a branch instead.

What I meant is that the only real reason to touch an existing tag is when you messed up when creating it (forgot files, too many files, whatever).

Roan Kattouw (Catrope)

Sergey Chernyshev schrieb:

I agree completely - it's hard to manage code and commit patches to extensions like this - version control is very powerful thing.

I was hesitant to add my extensions to MW repository for it's lack of tagging and branching (obviously it's limited because it's one big repo for all code). That's why I just created Google Code Hosting account and creating repos for each of my extensions there.

I think it's reasonable to expect this and many developers do use Source Forge or Google Code Hosting - I think overall extension management policy / best practices should keep this in mind.

Why doesn't Wikimedia switch to git for version control? It's way more powerful than svn... I think about something like the linux-wireless devs do: They base on linux tree, and add their code to their own repo; but if something gets changed in Linux kernel repo, it gets into linux-wireless automatically => you can check out a full kernel from linux wireless. So why don't we make one git repo for the main code, and for every extension/project/whatever another one, which bases on the MW repo?

Marco

Marco Schuster wrote:

Why doesn't Wikimedia switch to git for version control?

Why it should?

It's way more powerful than svn...

That is *very* questionable.

Subversion uses a client-server model, while Git uses a distributed model. That alone doesn't make Git any more powerful than Subversion, just different.

It is very common these days people who think that Git is the best VCS in the world, just because it was created by The Almighty Omnipotent Supreme Being Linus Torvalds, and then they try to persuade every single project using other VCSes to switch to a "superior" system. They ignore the technical aspects of each VCS, and force the same trousers to fit on everyone.

Git has many deficiencies compared to Subversion, that Git proponents usually ignore either because they never used anything else, or because they hold very strong emotions towards anything that Torvalds says.

I have used lots of different VCSes, from CVS to half all those distributed VCSes that popped up the last two years, and in my not-so-humble opinion, Subversion is still a very good match against most of them.

MediaWiki is using Subversion for some time now, and it is serving their developers fine. Converting everything to Git just because "it's way more powerful" is just stupid. Not only it would require a lot of additional manpower to convert the repository (because neither git-svnimport nor git-svn do a good job at converting, without very good babysitting), it would require all developers to learn to use a new different tool.

I think about something like the linux-wireless devs do: They base on linux tree, and add their code to their own repo; but if something gets changed in Linux kernel repo, it gets into linux-wireless automatically => you can check out a full kernel from linux wireless.

Git was designed to serve the kernel developers, so it makes a lot of sense to use Git for the linux-wireless project. But MediaWiki is not Linux. Each project has its own needs.

So why don't we make one git repo for the main code, and for every extension/project/whatever another one, which bases on the MW repo?

No, that wouldn't fit nice on MediaWiki.

In MediaWiki repository, since 1.10, branches and tags carry both MediaWiki core (phase3) and extensions directories, so you go into, e.g. REL1_11 branch, you have both core and extensions that are supposed to be compatible with each other.

In Git, you would be either forced to use a single repository for each extension, what would kill this single branch convenience; or have a huge repository for everything, being forced to download the entire repository even if the only thing you need is the core, since Git doesn't allow partial checkouts.

If you really want to use Git, nothing prevents you from using git-svn on your computer to access MediaWiki repository. Or better yet, use SVK, that plugs really nice to the Subversion repository, is distributed, and properly supports Subversion features.

And the following articles make a very good read: http://blog.red-bean.com/sussman/?p=20 http://blog.red-bean.com/sussman/?p=79 http://svn.haxx.se/dev/archive-2007-06/0780.shtml

Sounds like a great idea :) -> for now though, should we head to the wiki-tools page? (url please.. ) DanTMan wrote:

Hmmm... wherever you feel... Don't know what is the best place. If you want, I can setup a mini page on Wiki-Tools. ^_^ Actually, one of these days I want to create a Bounty site... In other words... Basically a site where people can post up extensions and features they want, people can pitch in if they're willing to pay for such a feature to be built, and someone can come, develop the feature and claim the bounty. Kinda like CoFundOS... But I had real issues with some of how they work.

Actually... When I get my bugtracker up and running, I can add a project into it for people to use the tracker to note extensions they want committed.

~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)

Ben wrote:

...

DanTMan wrote:

...

I'd just like to let the many a non-committer extension developer here know that I am open for committing any sane extension (Yes, DPL does count as sane in this category ;) heh...) into Subversion.

Nothing beats revision management. Even if it's not Wikimedia's SVN. I even have my own repo for Wiki-Tools which I commit my variety of extensions into. Once I look over SSH keys and a bit more on security I'd even be willing to give other people commit access for those who can't take the long wait to being able to get commit access to Wikimedia's SVN. But wherever it's managed, there is nothing like being able to svn-update to grab all the new changes to extensions and keep yourself running with good code. I personally get a very bad taste in my mouth when I see an extension on MediaWiki.org which I am forced to use some manual method of grabbing the data just to install it. I tend to avoid installing those if possible. But not only does it ruin the taste of the extension, it also means there aren't as many people poking in the code and making sure it works right, and it's up to usable standards. Plus Wikimedia's SVN has Betawiki's support.

So, I'm here basically saying... "If you have a sane extension up on MediaWiki.org, I'd be happy to help commit it to Subversion so that myself and other people can poke at it, translate it, and keep it nicely working with MediaWiki. And also make it easier for people to get ahold of the code. And I'll even be happy to apply any patches you have to update your extension with new features you've made". Of course, I'm not going to commit something completely stupid, but there is a small bit of room for extensions which need a bit of standards tweaking after being committed. And yes, I'll probably periodically poke various developers as I find extensions I personally would like to install, and ask them if they would let me commit the extension to SVN, even just to make sure that I can use a reliable extension rather than something left on the wiki.

So, where do we bug you with extensions we want to svn-commit? :)

-Wiredtape

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

If you're using mw: an interwiki, might I suggest links to Wikimedia's bugzilla and SVN repo as well?

-Chad

On Thu, May 8, 2008 at 11:46 PM, DanTMan dan_the_man@telus.net wrote:

Ok for now you can use this page: http://wiki-tools.com/wiki/Wiki-Tools:Wikimedia_SVN_-_Extension_Commits

I've got mw and MediaWiki as interwiki listed. Full list at: http://commons.nadir-point.com/wiki/Special:Interwiki Tell me if you need any, I'm using shared interwiki... ^_^ Why do you think I rewrote tableName and built a patch for 1.12 http://wiki-tools.com/wiki/Shared_Tables_in_1.12, heh...

Oh... If you ever run into a 502 - Bad Gateway... My PHP FastCGI instance dies sometime. Just tell me and I'll start it back up. Don't worry about the future, I'm planning on configuring God http://god.rubyforge.org after I get SHID (The SSO system going to be used on my sites) built.

~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)

Ben wrote:

...

Sounds like a great idea :) -> for now though, should we head to the wiki-tools page? (url please.. ) DanTMan wrote:

...

Hmmm... wherever you feel... Don't know what is the best place. If you want, I can setup a mini page on Wiki-Tools. ^_^ Actually, one of these days I want to create a Bounty site... In other words... Basically a site where people can post up extensions and features they want, people can pitch in if they're willing to pay for such a feature to be built, and someone can come, develop the feature and claim the bounty. Kinda like CoFundOS... But I had real issues with some of how they work.

Actually... When I get my bugtracker up and running, I can add a project into it for people to use the tracker to note extensions they want committed.

~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)

Ben wrote:

...

DanTMan wrote:

...

I'd just like to let the many a non-committer extension developer here know that I am open for committing any sane extension (Yes, DPL does count as sane in this category ;) heh...) into Subversion.

Nothing beats revision management. Even if it's not Wikimedia's SVN. I even have my own repo for Wiki-Tools which I commit my variety of extensions into. Once I look over SSH keys and a bit more on security I'd even be willing to give other people commit access for those who can't take the long wait to being able to get commit access to Wikimedia's SVN. But wherever it's managed, there is nothing like being able to svn-update to grab all the new changes to extensions and keep yourself running with good code. I personally get a very bad taste in my mouth when I see an extension on MediaWiki.org which I am forced to use some manual method of grabbing the data just to install it. I tend to avoid installing those if possible. But not only does it ruin the taste of the extension, it also means there aren't as many people poking in the code and making sure it works right, and it's up to usable standards. Plus Wikimedia's SVN has Betawiki's support.

So, I'm here basically saying... "If you have a sane extension up on MediaWiki.org, I'd be happy to help commit it to Subversion so that myself and other people can poke at it, translate it, and keep it nicely working with MediaWiki. And also make it easier for people to get ahold of the code. And I'll even be happy to apply any patches you have to update your extension with new features you've made". Of course, I'm not going to commit something completely stupid, but there is a small bit of room for extensions which need a bit of standards tweaking after being committed. And yes, I'll probably periodically poke various developers as I find extensions I personally would like to install, and ask them if they would let me commit the extension to SVN, even just to make sure that I can use a reliable extension rather than something left on the wiki.

So, where do we bug you with extensions we want to svn-commit? :)

-Wiredtape

---

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