Talk:Third-party MediaWiki users discussion

Previous page history was archived for backup purposes at Talk:Third-party MediaWiki users discussion/LQT Archive 1 on 2015-07-10.

If you have developed something in-house or found a workaround to a common problem, please share it with the community. This would include advice, fixes, extensions, maintained bundles, scripts, etc.

Why share?

• Others won't have to reinvent the wheel.
• Your suggestion might be integrated in core or as an extension, helping with maintenance and compatibility issues.
• You can get help from the community to improve your improvement.

How to share? You can find resources on sharing your work at the pages below. Also, you can post about your recommendations or improvement here and be directed to the right place to go to.

• How to contribute
• Manual:Developing extensions
• Submit your changes

This post was posted by 78.90.26.139, but signed as Mitevam.

I don't think that this will work this way. You say "Guys, please share your experience and your software" and guys start to share all they have. Our company understand the importance of sharing as much code as we can but we don't do that yet.

Let's think why we should do that:

1. the extension that is available on mw.org will have some documentation. It's useful to have some documentation even for yourself.
2. it's good advertisement and part of the portfolio of the company. "Hey, I know WikiVote! They've developed this cool extension! I think I will recommend them to my friend who want to do a wiki project".
3. if someone use your extension you have free testers that will report you about the bugs
4. if I patch Yaron's extension and Yaron integrate my code into repository then from now he will support and bugfix this code. So we now have free-of-charge part-time developer.
5. During the process of acceptance of my patch Yaron will beat my kidneys out to improve my code (will point on errors and coding style). The quality of code will be better.

Let's think now why we don't do that:

1. There are too many extensions here and there is no rating of them. Very useful and mature extensions are hard to differ from experimental and poor-written. Better categorization, an expertise and competitions of the extensions (like "Extension of the month") can make the situation better.
2. We're not sure that this is a good advertisement for us. The list of companies that Maria have compiled is the only list of companies I'm aware of. What about company profiles here on mw.org and creating the infrastructure/frames/motivation for us to write self-descriptions, success stories, etc?
3. We're too lazy to find time to invest into open-sourcing our extensions because of (1) and (5) of the previous list. This is just wrong and we have to change here.

I agree with Yury above. Open sourcing is often a huge effort for a small structure (true open sourcing, not just putting code somewhere and claiming it open) and there is little to no support coming from the community:

• WM Workers have far too much work on the core to worry about third-party extensions (outside WM scope)
• MW Volunteers have their own job and a full plate when it comes to code their own extensions and maintaining them.
• Third Party developers do their best to help and open, but resources are scarce enough for their own dev.

It is not a blame, but it is clear than third-party development support is not a priority at WM (like it is at FB, or WordPress, or SoundCloud...). Plus WM's philosophy is not very commercial/non-free friendly.

I don't think this could be fixed (if it should be fixed) without creating jobs and positions to sustain a viable opening strategy towards third-parties.

ClementD it does take a lot of time to open source, but is it not an investment? Does it now pay back because of the reasons User:Katkov_Yury listed as well as by saving time when upgrading? Is it the initial development of an extension the hard part or the maintenance?

Also, are there other things third-party users can share with each other ( best practices, scripts, etc.) to help each other or is it just extensions?

The topic of merging contributions is quite recurrent. The WMF focus is indeed in Wikimedia projects and not 3rd parties. However, is there anything stopping 3rd parties getting organized and pushing "their" developers through the code meritocracy until having enough with merge rights?

Many patches are waiting not because of its origin, quality or disagreement in the implementation, but just because there is nobody with enough time to look at them. It is hard for an individual developer of an extension to fill that gap but maybe MediaWiki 3rd parties united could pool efforts? Imagine that such proposal would receive wide support and commitment from a bunch of MediaWiki 3rd party developers. Maybe such group could even get Wikimedia funds to help getting that work done. It is possible to argument that a healthy MediaWiki ecosystem helps a healthy Wikimedia software platform...

Time to consider a MediaWiki Group for 3rd party developers? (or Vendors, or...)

This post was posted by Qgil-WMF, but signed as Qgil.

I'm not sure the current +2 policy really allows it: there might be a sort of catch 22, for instance, in that a dev with a focus on third party wikis may not get +2 on core because of lack of code review experience on core, and committers may not submit commits at all for such devs to look at because they know they'll be ignored; after all, even commits specifically focused on Wikipedia are just left rotting for many months.

And yes, improvements for third parties do get blocked by contrasting WMF needs, although of course in those cases the ideas on what is an improvement are often controversial (see the recent skins saga).

+2 says: "+2 rights on MediaWiki core and extensions are granted to (...) Community members who have contributed high quality patches, exercised +1 rights well, and demonstrated competence." Are there 3rd party sensitive developers in this track, aiming to get +2 rights? 3rd parties could coordinate with them in order to build more +1/-1's, more feedback around those patches and more Gerrit karma.

Again, coordination between 3rd parties would be a key factor of success, if they can agree on the developer to focus, coordinate with, promote, perhaps fund.

This post was posted by Qgil-WMF, but signed as Qgil.

Thank you Yury for listing the pros and cons of sharing.

This is the second time rating of extensions has come out as a suggestion today. Is that something that will be really useful? How hard would it be to implement? Who would judge? What would be the criteria?

Regarding your point about advertisement, I don't know if people have seen this but there was some idea in the past to make a list of people to hire for MediaWiki projects here, but the community decided it was not appropriate to endorse any companies/developers ( see discussion here). However, you can see several external lists of MediaWiki contractors. Add yourself if you haven't done so.

By the way here is the longer version of all the pros on my weblog about MediaWiki: http://www.ykatkov.name/2012/10/06/the-importance-of-participating-the-community/

I have heard a few comments about skin creation being difficult. What are the major issues with that? Documentation? Flexibility? Maintenance?

For me it's in general very hard to find out which CSS files are loaded, even for the default skin. So, a better structure and documentation would be nice. It's also hard to maintain a skin over different MediaWiki versions. So, if a skin becomes incompatible by a new MediaWiki version, admins do not update MediaWiki any more to keep their skin, which is bad.

You might already know, but just for the record: There's a very good skinning tutorial by Daniel Friesen here: Manual:Skinning/Tutorial

But I totally agree with Ralfk. MediaWiki evolves quickly and it's hard to keep up with the changes. They recently started to split the main CSS files into smaller ones (i.e. diff.css) and moved them to dedicated ResourceLoader modules which is good because it improves the sharing of styles between skins.

In my opinion there is still a lot of programming logic in the skin.

So the main issues with skins are confusing structure(and documentation about it) and not enough isolation of skins form the code, which makes it easy for them to become incompatible?

Is there some best practices with skins that would ensure ( or at least make very likely) the compatibility of a skin with future releases ( after ResourceLoader, let's say)? Or is it that rather impossible to achieve?

What can be done to ease these issues? How is it done in other projects like Joomla or Drupal, where User:Katkov_Yury said skins are handled much better?

Skinning is very important. But many wiki maintainer in companies are still interested that their wiki looks similar to Wikipedia. But this is now changing. The most most important discussion for me are the requirements for the different types of skins? Which features have to be included? Which information has to be displayed and for whom? There is for instance a difference in enterprise wikis and public wikis. The first need information about quality and status of an article on top the second are asking for social media integration and features like central notice. Maybe we can share our experiences here?

BTW: We published a few remarks about skinning here to spread the idea :-)

Its not helped at all by an installation system only accessible to super-geeks - navigate through the page to a one-time snapshot link, download that , untar it, tar it back up, and edit LocalSettings. It means that any extension that depends on a skin is itself likely to fail to get installed properly. We are going to have to stick a tar of the skin into our own extension just to make sure we can script its installation as the people installing are going to be non-geeks in remote areas and there is absolutely no way they would be able to negotiate Mediawiki's skin installation process.

A lof of time has passed since this thread was started (~7 years). Things have changed. An extension now can provide different stylings for different skins: skinStyles in ResourceLoader. But still, the skinning system has a lot of issues. Even after all these years, not much progress was made to ease a skin developers life.

As operators of a medium sized wiki farm (http://biowikifarm.net) we are happy with the high quality of mediawiki core version updating. However, testing each and every extension, often filing many extension bug reports (where the extension was working ok with the previous mediawiki core, but now has bugs after updating core) is complicated. I want to open a discussion on what might be improved here.

I see the extensions as falling into three categories:

1. Extensions used on Wikimedia Foundation (WMF) sites. These are generally well maintained. However, the problem here is that often bug fixes are applied only to Head and the WMF versions, but not to the stable and oldstable releases of mediawiki. It may be valuable to lobby WMF to create a policy that its software engineers try to port all fixes to WMF-fixed extension also in the old stable and stable (e.g. REL1_19, REL1_20) branches of the extensions, making sure that when updating to the extension branches corresponding to the core extension, one has a a fair chances of getting the already existing bugfixes (rather than finding the bugs again, as is currently the case).
2. Extensions installed at the vast majority of non-WMF sites, even if not on WMF itself. These could get special attention similar to WMF extensions. Here the problem seems to be that the list of these extensions is difficult to built. The attempts to do statistics of existing wikis (used to be linked in infoboxes) could not be kept current. Is there a chance to build a consensus list among those involved here?
3. Extensions that vary greatly in usage. There is little that can be done for those, but if we had to deal only with these few (in our case that is perhaps 5 extensions out of 90) we would be happy... :-)

In general it might be helpful if someone could write something like a "Best practice to maintain and upgrade your extension zoo" wiki page. For example, we found that it is advisable to use svn/git to better manage the extension updating and bug fixing.

I think that the extensions may be also classified by their quality; it's not necessary that the quality assurance is made by WMF. But it would be very useful to catogorize the extensions to "well-written", "dangerous", etc.

Is there a chance to build a consensus list among those involved here? There is an effort going on currently to make a list of extensions to be integrated in core and in the installer here that I have already suggested everyone should participate in. Is that different from the consensus list you are envisioning?

I am trying to find out if a guide for maintaining your "extension zoo" exists anywhere already to reuse that and maybe build on it. It seems like a common issue and it might be good to have some "best practices".

User:Katkov_Yury, how to you envision the quality assurance? Do you imagine something like a rating system? Who would judge?

An upgrade 'panel' is pretty standard for other CMS. Dokuwiki has an upgrade plugin (and a plugin manager plugin). It makes life much easier for the OPS, even of a dedicated use website like Wikipedia.

The nutshell extension zoo guideline for MW is: download a repo, test each one separately with your current MW installation and keep only those which work currently. Never upgrade anything until you have set up the future MW version and tested every currently used extension and *proven* they work in the future version.

The key there is "never upgrade anything".

The most important thing I need to know about extensions is does it work with MediaWiki version 1.X, for each version of the extension. Any meta data after that is nice, but not required.

Too much questions!! Here is the first answer. > There is an effort going on currently to make a list of extensions to be integrated in core and in the installer here that I have already suggested everyone should participate in. Is that different from the consensus list you are envisioning?

Yes, it's a different list but they can obviously intersect in many points. The RECOMMENDED extension is like the featured article in Wikipedia - it has to be so absolutely needed for many people that it's available to install via installer itself. For example Extension:Cite. But there are also just AWESOME extensions that serve very important purposes and very well-written but maybe don't have to be included with the installer pack. They're just very good extensions and should be more visible.

>User:Katkov_Yury, how to you envision the quality assurance? Do you imagine something like a rating system?

Well the quality assurance is our main job in Wikivote. :-) Technically this can be done within MediaWiki + extensions: there are several extensions for voting, most notably Article feedback. It has been developed by WMF so there is a chance for it to be installed on mw.org ;)

Speaking about voting I can imagine the categories of quality of the extensions with formal criteria like the presence of unit-tests, modularity, extensibility, vulnerability, following the coding standards. Article Feedback can be used for that or we can provide our voting extensions for free.

As a hobbyist MediaWiki sysadmin I would really appreciate ratings / feedback on extensions. Now it's a whole adventure to find the right ones for you.

This post was posted by Qgil-WMF, but signed as Qgil.

> Who would judge? This question is very important indeed. In terms of people I think that the policy here should be similar to the code review policy (who has the exclusive rights to judge there?). Core developers and greatest contributors can make the final judgments, developers of other extensions can vote for or against. Maybe the system of promotion of the extension can be similar to the policy of choosing the featured article. Isn't that a best practice?

All now is in place (honestly I just check how the Summarize feature of Liquid Threads works ;-) )

Hi - why are wikis like those of Intel, Novell etc. listed on this page? Those companies aren't MediaWiki vendors in any sense.

Indeed, it seems more like a mixed list of the companies that use MediaWiki as their own wiki with the companies, that actually provides some services and solutions based on MW platform. I think we should differ those two.

How about this structure for the list:

1. public and private MediaWikis
2. Wiki farms
3. hostings with one-click MediaWiki installations
4. people and companies that provide MediaWiki support and help
5. people and companies that develop MW-based solutions and program extensions/skins
6. (?) researchers with their research topics based on MediaWiki (I know a lot of scientists who make research for SMW)

I feel rather unhappy to be listed as a "vendor" here. A vendor is someone who sells a product. The list contains various maintainers of small or larger mediawiki installations - only a fraction are "vendors". I propose to rename the page to MediaWiki_installations.

I second this — "MediaWiki_installations" is more appropriate for the current information.

That would make it a duplicate of Sites using MediaWiki. A description of what this lists wants to be is probably along the lines of "MediaWiki sysadmins with a diverse experience"; English is lucky, "clients" are not necessarily paying customers, is "vendors" really so negatively connotated? As a non-native speaker I have little clue...

Whether or not "vendors" is negative, it's not accurate. It seems like the best solution is just to get rid of the listings of regular sites, given that there's already a page for them...

I took the liberty to split the table to several pieces without changing the structure and without deletion.

Sorry everyone for the confusion. This "vendor" list was rather meant to help me find users to contact. I made it public so people can help me by adding to it and so that it "outlives" my internship project in case anyone needs it.

"Vendor" was definitely not the right term to hold all of the different users in the list and I should have anticipated the reaction. I apologize that it made some people uncomfortable. I hope "MediaWiki third-party user" is better.

I have moved the page to give it a new name, and restructured it, so that the list does not occupy a central place as it did. The focus should be on conversation and discussion. I hope its role is more clear now.

Thank you User:Katkov_Yury for restructuring the list and thank you everybody for the immediate feedback and for helping me improve my project. Please feel free to comment on the current setup and I will fix it if anything still seems odd.

Don't feel bad! In just few days you got a very interesting list. I think your initial push can be helpful for actual MediaWiki consultants or "vendors" in some way to get better coordinated and advertise their services. The whole MediaWiki community benefits from this.

This post was posted by Qgil-WMF, but signed as Qgil.

I agree. I don't think "Vendor" is negative, I am happy to see our site alongsite with Vendor sites (but not listed as a vendor). Having a neutral heading and a structured list is very good.

What would you like to see next on MediaWiki?

The purpose of this discussion is to identify the most desired features MediaWiki is missing. Please only suggest features that will be really useful to your work.

This post was posted by 78.90.26.139, but signed as Mitevam.

Easy: Proper WYSIWYG support . That's by far the most common complain. I've used FCKeditor, WYSIWYG extension, but none is supported by the upstream trunk, and have limited support. None support templates, though.

1. WYSIWYG
2. Integrated access control: ability to hide some pages from the groups of users
3. Wiki-markup editor for template gurus - with autocompletion, syntax highlight, template parameters suggestions: more like markup IDE.
4. MediaWiki Core API. Not the HTTP-API but the set of PHP classes in the core that are less likely to change in the next version. Mostly I want core developers to think about MediaWiki as framework with programming interfaces for extension developers. All the changes in those interfaces have to be calm, with slow deprecation. A role model for that is Python compiler.

User:Katkov_Yury, do you know about these discussions? API/REST_proposal/Kickoff_meeting_notes

Requests_for_comment/API_Future

Is this closer to what you are talking about - standardization and stability(and calm transition) between versions.

Also, I've seen this extension for access control.Is that not what you are looking for and how?

Interesting page but it's not what I mean. The API team is doing wonderful but it's all client API for guys from the outside. What I mean is the internal PHP-API for extension developers. It's more administrative than technical issue: you just have to say that this set of classes (e.g. Article, User, WebRequest) are not likely to change a lot in the following three MediaWiki versions, so all can rely on them.

1. A visual editor that functions brilliantly and won't break complex wiki pages.
2. An easy way to share wiki content on social media services.

I would like to see:

• built in support for Google Analytics
• built in support for XML Sitemaps without using command line
• built in support for Google Adsense in popular layout positions
• easy way of gracefully retiring old tags (e.g. Google Maps extension is no longer supported, replaced with Maps which has different tags)
• update to the documentation about creating a simple extension that is XSS safe

This post was posted by QuotesUK, but signed as Quotes.

I see that a WYSIWYG editor is the top wish on the list ( I love the idea too). As you might know, VisualEditor is currently being developed and tested. I would encourage you to actively participate in the process with feedback , ideas, and volunteer help. You can test it here. You have the chance to influence its shape at this stage.

You might also be interested to read this blog post about VisualEditor.

Again related to VisualEditor, there will be a Bug Day focused on testing it with non-latin characters on Jan 28 on IRC. Learn more here.

Quoting an email I received from Nicolas Nallet from http://semantiki.fr/ :

What feature I would like to improve or settle is :

• fine grained read access in the wiki.
• mobile version for website that turns with MediaWiki
• More modern skins included in MediaWiki
• The implementation of Semantic MediaWiki on mediawiki.org website in order to manage easily extensions pages

• +1 for skins. Ok, don't make skins yourself but make it possible to create new skins for us, developers in less time. It's so much easier to create skin for Joomla or Drupal, and the result if often looks elegant (from the program code point of view). Skinning is a problem and skinning is an obstacle for MediaWiki community to grow.
• +1 for SMW on MediaWiki.org. I don't know how you guys can manage so much data without SMW.

MW has built Extension:GoogleNewsSitemap, which I believe satisfies the Google Sitemap xml (NewsSiteMap being an extension of SiteMap) as well. It should not be difficult to modify this extension to be more general.

Hi Quotes,

Chris Steipp from WMF has expressed interest to learn more about your wish: "update to the documentation about creating a simple extension that is XSS safe". He is asking for more details like "is this for an extension with a special page vs parser functions"?

Are you on the mediawiki-l mailing list? Maybe you can reply there. Here is the thread.

Suggestion: formalize the recurrent suggestions at Mentorship programs/Possible projects and let's try to find/create a related enhancement request in bugzilla. Even f some (most?) of these projects may be too complex for an internship we can probably find ways to cut them in chunks. In the worst case, having these ideas on that page will make us remember about them every time a new program starts.

This post was posted by Qgil-WMF, but signed as Qgil.

That is a good idea. I will work on that. Thank you User:Qgil.

• What are the main recurring pain points of installation and upgrade?
• What would you like to see in notes for main releases like MediaWiki 1.20, or security releases notes? What have you liked or missed in the past, and what convinces you to upgrade?
• Would you like a notification on your wiki about possible upgrades (as Joomla, Wordpress etc. do in their admin panels) and where?
• Please add/comment on Suggestions for extensions to be integrated the extensions which are most often/always needed.
• What are the configuration settings defaults or default user options which most often/always need to be changed locally nowadays?

Core upgrading works very well. But extension upgrading suffers from complexity issues in our experience. I understand that some things are too difficult to tackle but others I believe could be improved. I will open a new thread "Improving extension updating" for that...

Quoting an email from http://www.softaculous.com/.

MediaWiki upgrades do cause some pain to users because after unzipping the user needs to go as many steps as installing a new version of MediaWiki. It would be great if you could add a silent upgrade script which will upgrade the installation without any user intervention.

At least half a dozen sysadmins wrote me that we should really have an updater as Joomla or Wordpress have.

It would be great to have a mechanism that allows extensions to add "steps" to the install/update wizard. I.e. when installing MW there is a section that lists all bundeled extensions. If the user selects the extensions for automatic install they are automatically included at the end of LocalSettings.php. But there is no way to configure the extensions during the installation process.

Help testing the Extension:Configure is appreciated, I think.

Please consider requesting a slot at QA/Weekly goals.

This post was posted by Qgil-WMF, but signed as Qgil.

Questions:

• Do you dump your wiki(s) to XML?
• If you don't, is it because of some missing feature?
• If you do, how do you use it?
• What would you like to see that's missing?
• Is the possibility to host wiki dumps at the Internet Archive useful?

This discussion thread has been suggested by User:ArielGlenn and Nemo.

This post was posted by 78.90.26.139, but signed as Mitevam.

I believe the xml wikidump is way too incomplete as a backup, too many things essential for restoring a wiki are missing (interwiki table, user information, openID, etc.). Having a wikidump does not allow to restore a wiki to functionality.

I would not expect the dumps to be used in place of a backup; that's what db table dumps and snapshots are for. But I would be interested in knowing whether XML dumps are generated for other purposes (analysis, allowing users to downlowad the content in bulk, bot processing of content, etc).

it's interesting possibility to host dunmps on Internet archive. I also like the idea to use things like this Webcite bot that is walking through all the external links and archive the pages.

So does anyone use XML dumps for anything and what for? Do you back up your wikis and how?

Backup are of course done. Weekly a full DB backup, daily a differential backup. There are many soft doing that, we coded our own (GPL).

Full DB dump and files dump. XML dumps are for the wikis in which we don't have direct access to database (in other words, not OUR wikis)

Same as Katkov Yury, although we have a commons for media files so only one file repo.

From private email: «an easy database export that would also include a backup of the stores images would be nice-- ideally one that can be run from the command line to pull a full database dump (with an option not to include deleted pages)».

Extend support for URL customization options (in the HTML UI or via LocalSettings.php, not with complex configurations in multiple places).

For example:

• Use as wiki.example.com/page-title or examplewiki.com/page-title (opposed to wiki.example.com/wiki/page-title)
• Ability to both support and enforce an "/all-lowercase-all-hyphens-no-underscores" style ("WordPress style") for page URLs
• Limit exposure of ".php" in URLs

Someone asked me today: if talk about is cheap, «what would the action be?» Great question, always worth asking oneself. So here's what I answered about my last 18 months.

As for action within my reach, I improved installation and upgrade docs, I maintain the MediaWiki 1.X pages to make them look interesting, I compiled a list of reasons to upgrade, I scraped the web to find tens of thousands wikis to monitor on wikiapiary, and finally I sent tens of thousands emails to complete strangers to tell them to upgrade, receiving perhaps 150 replies.

I want to bring here a problem for 1.22 release. Some wikis include an advertisement in the sidebar of Vector, in one of the sections, but since 1.22 there seems to be a lack of control about having a sidebar section permanently uncollapsed.

• Thread:Project:Support desk/How i add to Adsense in Page
• Thread:Project:Support desk/SubSidebar does not expand (2) (probably related to advertisements)

And also the lack of support for a google adsense extension that brings the first thread.

Ciencia,

I wasn't paying attention for a while, but this seems like a regression. Could you file a bug? I've had success with the this extension and if maintenance is a problem there, file bugs and let me know about them -- I'll try to fix them.

I don't have this particular problem, I was just reporting what others said, so I'll let someone else that is willing to track this resolution to file the bug himself/herself.

Filed a bug.

Tracked in Bugzilla
Bug 61143

Our biggest difficulty with MediaWiki, particularly in MediaWiki 1.20, is extending the WikiEditor using JavaScript. We have added several menus alongside Special Characters and Help, each with its own icons and dropdowns. They worked fine in MediaWiki 1.17. When 1.18 came, our custom icons started vanishing at random times. Now in 1.20, the icon problems are more frequent and the entire toolbar sometimes vanishes. It's possible that this is a coding error on our part, but we seem to be following the docs. Sometimes clearing the browser file cache helps, sometimes not.

Overall, we are suffering from timing problems with JavaScript modules that have dependencies. The dependencies are specified in ResourceLoader, but somehow, once the JS gets to the browser, the modules seem to interleave as they run. For example, if module A depends on B, we can specify that, but this doesn't seem to guarantee that every line of module B will have run before every line of module A. I'll ask my lead developer to follow up to this comment with more details.

User:Maiden_taiwan please do follow up with more details and I will try to find the right person/team who could maybe help you with the JavaScript issues.

I would suggest to write about problems like that to the wikitech-l mailing list and if you don't find a solution there you could probably file a bug report.

As Maiden taiwan stated above, we've been having some problems with asynchronous behavior in JavaScript files.

Let me first say that the ResourceLoader is a wonderful part of the software. Thanks goes out to everyone who contributed to this project — it's made my life much better. That being said, I don't think that I and my team have figure out how to properly take advantage of it's benefits.

General

We are currently using the ResourceLoader to load modules, some of which contain JavaScript. The dependencies are made explicit in the registering of the ResourceLoader, and they execute in the proper order on the client side. In many of these JavaScript files we wrap our code in a jQuery .ready() callback. Since these JavaScript files have dependencies on one-another (as laid out in the RL,) they need to be executed in the correct order to work properly. We're finding that when using jQuery's .ready() (or similar) function, the callbacks seem to execute in different (unexepected, browser-dependent) order. This causes errors.

WikiEditor extension as a specific example

Customizing the WikiEditor-toolbar is one of the specific cases where we've encountered problems. First, the WikiEditor provides no good events to bind to once the toolbar is loaded. This is not a problem because there is a documented work-around. However, our JavaScript code needs to execute in the proper order, which it is not. We have about four JavaScript files that add custom toolbars, sections, and groups.

My questions

• It recently dawned on me that executing our code within a $(document).ready(); callback might not be necessary as the JavaScript for each ResourceLoader module is executed in its own callback on the client-side. This should provide the necessary scope to avoid clobbering global variables along with getting executed at the proper time. Is this a correct assumption to make?
• Is it a good idea to avoid binding our code to jQuery's ready event?

I'm going to test this theory and post to mediawiki-l/wikitech-l with questions.

As this is a very specific technical questions I was about to copy it to wikitech-l but I see you are planning to do the same. I would suggest asking on the #mediawiki channel on Freenode IRC as well. Let me know if I can somehow help and please continue sharing issues you are having.