I've branch-merged the new preferences system that I've spent the last few weeks developing.
On the outside, you probably won't notice any difference except a few bugfixes, but the internals have undergone a complete rewrite.
All of the actual preference definitions and utility functions have been separated out into Preferences.php, which holds all business logic for the new system. The UI and submission logic for the system is done in SpecialPreferences.php, which, now only a hundred lines long, wraps a generic class I've written to encourage separation of business and UI logic called 'HTMLForm'.
The advantage of this clear separation is that writing an API module is very simple, and it can be called internally, too!
Extensions must now hook GetPreferences instead of the existing hooks (which were too low-level to maintain compatibility with), I've updated all extensions used on Wikimedia. This new hook allows you to put preferences wherever you want, and a new preference can be added in less than ten lines of code, rather than the hundred-line nightmare that was required in the previous iteration.
I'd like to look towards trimming some of the existing preferences that are no longer relevant, and adding new preferences as common sense dictates.
Feedback, praise and criticism regarding the changes is certainly welcome!
On Fri, Apr 24, 2009 at 05:59, Andrew Garrett agarrett@wikimedia.org wrote:
I'd like to look towards trimming some of the existing preferences that are no longer relevant, and adding new preferences as common sense dictates.
Can I suggest adding a "preferred editor" preference? Ideally, it should be a dropdown box (given the variety of existing visual editors http://usability.wikimedia.org/wiki/Environment_Survey/MediaWiki_Extensions/Nomination#Editing, an admin might wish to install more than one), but a simple "disable the visual editor" checkbox is probably enough for most setups (and simpler to maintain).
Thanks, bye -- Jacopo Corbetta j.corbetta@sssup.it jacopo.corbetta@gmail.com
WYMeditor MediaWiki integration: http://www.mediawiki.org/wiki/Extension:MeanEditor
While from a user's perspective the various editors seen on the page you linked to appear to be drop-in replacements for the current plain text solution, I can assure you that there are many other reasons for not yet deploying them on Wikipedia that go far beyond our ability to provide users with a preference to turn them off. Almost all of those visual editors require the use of not-yet-stable reverse parsing, and many cause articles to change in ways the user did not intend, such as adding white-space places the user did not touch, or stripping out HTML comments from the code. There are other downsides as well, which are represented in an article closely related to the one you linked to, which is the results of the extensions chosen for evaluation from the list of nominated ones.
http://usability.wikimedia.org/wiki/Environment_Survey/MediaWiki_Extensions/...
An existing example of us providing users with such an option however can be seen in the ability to turn various editing-related gadgets such as wikiEd. I think this shows that should a more visual editing interface become able to be deployed, we certainly would make it optional.
- Trevor Parscal
On 4/24/09 5:30 AM, Jacopo Corbetta wrote:
On Fri, Apr 24, 2009 at 05:59, Andrew Garrettagarrett@wikimedia.org wrote:
I'd like to look towards trimming some of the existing preferences that are no longer relevant, and adding new preferences as common sense dictates.
Can I suggest adding a "preferred editor" preference? Ideally, it should be a dropdown box (given the variety of existing visual editorshttp://usability.wikimedia.org/wiki/Environment_Survey/MediaWiki_Extensions/Nomination#Editing, an admin might wish to install more than one), but a simple "disable the visual editor" checkbox is probably enough for most setups (and simpler to maintain).
Thanks, bye
Jacopo Corbetta j.corbetta@sssup.it jacopo.corbetta@gmail.com
WYMeditor MediaWiki integration: http://www.mediawiki.org/wiki/Extension:MeanEditor
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, Apr 24, 2009 at 19:04, Trevor Parscal tparscal@wikimedia.org wrote:
While from a user's perspective the various editors seen on the page you linked to appear to be drop-in replacements for the current plain text solution, I can assure you that there are many other reasons for not yet deploying them on Wikipedia that go far beyond our ability to provide users with a preference to turn them off.
Many wikis use MediaWiki beside Wikipedia.
An existing example of us providing users with such an option however can be seen in the ability to turn various editing-related gadgets such as wikiEd. I think this shows that should a more visual editing interface become able to be deployed, we certainly would make it optional.
Exactly. Each editor has its own incompatible setting which allows it to be turned on or off. Basically, each extension assumes it is going to be the one and only one editor for the wiki. If you install more than one, things will break. A unified preference might have been useful. Anyway, no big deal.
Bye, -- Jacopo Corbetta j.corbetta@sssup.it jacopo.corbetta@gmail.com
WYMeditor MediaWiki integration: http://www.mediawiki.org/wiki/Extension:MeanEditor
2009/4/24 Jacopo Corbetta jacopo.corbetta@gmail.com:
An existing example of us providing users with such an option however can be seen in the ability to turn various editing-related gadgets such as wikiEd. I think this shows that should a more visual editing interface become able to be deployed, we certainly would make it optional.
Exactly. Each editor has its own incompatible setting which allows it to be turned on or off. Basically, each extension assumes it is going to be the one and only one editor for the wiki. If you install more than one, things will break. A unified preference might have been useful. Anyway, no big deal.
I don't believe any WYSIWYG (or close to) editor that exists for MediaWiki is good enough that you can completely avoid editing the wikitext directly (in order to do complicated stuff), that means you can't use one and only one editor unless that editor is the default wikitext editor.
Jacopo Corbetta wrote:
On Fri, Apr 24, 2009 at 19:04, Trevor Parscal tparscal@wikimedia.org wrote:
While from a user's perspective the various editors seen on the page you linked to appear to be drop-in replacements for the current plain text solution, I can assure you that there are many other reasons for not yet deploying them on Wikipedia that go far beyond our ability to provide users with a preference to turn them off.
Many wikis use MediaWiki beside Wikipedia.
An existing example of us providing users with such an option however can be seen in the ability to turn various editing-related gadgets such as wikiEd. I think this shows that should a more visual editing interface become able to be deployed, we certainly would make it optional.
Exactly. Each editor has its own incompatible setting which allows it to be turned on or off. Basically, each extension assumes it is going to be the one and only one editor for the wiki. If you install more than one, things will break. A unified preference might have been useful. Anyway, no big deal.
Extensions can add their own preferences more easily now. Adding a default preference to turn off a feature that doesn't yet exist in MediaWiki core doesn't make much sense.
Alex wrote:
Extensions can add their own preferences more easily now. Adding a default preference to turn off a feature that doesn't yet exist in MediaWiki core doesn't make much sense.
A preference name could be reserved to be consistently used by all alternate editors. Anyway, IMHO any alternate editor should offer an option to disable it directly on the edit page, regardless of a preference which would define "don't appear by default".
What does this have to do with not horribly breaking many extensions at the same time? The WMF has cultivated an extension ecosystem and it makes sense to protect it.
On Fri, Apr 24, 2009 at 2:23 PM, Soxred93 soxred93@gmail.com wrote:
Keep in mind that when MediaWiki is developed, the best interests of Wikimedia are in mind. Wikimedia takes priority on MW development.
X!
On Apr 24, 2009, at 4:02 PM [Apr 24, 2009 ], Jacopo Corbetta wrote:
Many wikis use MediaWiki beside Wikipedia.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, Apr 24, 2009 at 4:23 PM, Soxred93 soxred93@gmail.com wrote:
Keep in mind that when MediaWiki is developed, the best interests of Wikimedia are in mind. Wikimedia takes priority on MW development.
Not as a general rule. If we really didn't care about third-party users, we'd require the very latest version of PHP (since Wikimedia uses it), write large chunks of the software in other languages (Wikipedia has Python installed), and so on. The suggestion to allow embedded Lua in templates seems not to be happening primarily because it would make Wikipedia content unusable by third parties on shared hosting.
Although development of MediaWiki tends to focus primarily on Wikimedia's needs, it does *not* do so if that would significantly hurt MediaWiki's utility to third parties. Part of Wikimedia's goals is to make its content as useful as possible to third parties. That applies to MediaWiki insofar as it's a Wikimedia project, and doubly so insofar as it's needed to effectively use content from Wikimedia's other projects like Wikipedia.
On Fri, Apr 24, 2009 at 4:25 PM, Brian Brian.Mingus@colorado.edu wrote:
What does this have to do with not horribly breaking many extensions at the same time? The WMF has cultivated an extension ecosystem and it makes sense to protect it.
Do you have evidence that many extensions are, in fact, horribly broken? And if so, that they can't be easily fixed?
I am just hoping to prevent a repeat of ParserPP.
On Fri, Apr 24, 2009 at 2:56 PM, Aryeh Gregor <Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com
wrote:
On Fri, Apr 24, 2009 at 4:23 PM, Soxred93 soxred93@gmail.com wrote:
Keep in mind that when MediaWiki is developed, the best interests of Wikimedia are in mind. Wikimedia takes priority on MW development.
Not as a general rule. If we really didn't care about third-party users, we'd require the very latest version of PHP (since Wikimedia uses it), write large chunks of the software in other languages (Wikipedia has Python installed), and so on. The suggestion to allow embedded Lua in templates seems not to be happening primarily because it would make Wikipedia content unusable by third parties on shared hosting.
Although development of MediaWiki tends to focus primarily on Wikimedia's needs, it does *not* do so if that would significantly hurt MediaWiki's utility to third parties. Part of Wikimedia's goals is to make its content as useful as possible to third parties. That applies to MediaWiki insofar as it's a Wikimedia project, and doubly so insofar as it's needed to effectively use content from Wikimedia's other projects like Wikipedia.
On Fri, Apr 24, 2009 at 4:25 PM, Brian Brian.Mingus@colorado.edu wrote:
What does this have to do with not horribly breaking many extensions at
the
same time? The WMF has cultivated an extension ecosystem and it makes
sense
to protect it.
Do you have evidence that many extensions are, in fact, horribly broken? And if so, that they can't be easily fixed?
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, Apr 24, 2009 at 4:59 PM, Brian Brian.Mingus@colorado.edu wrote:
I am just hoping to prevent a repeat of ParserPP.
A *lot* more extensions use parser-related stuff than preferences. In any event, the upheaval of ParserPP was probably necessary given what it sought to achieve. That sort of thing happens from time to time -- it's not feasible for extensions with access to so many hooks and methods to just work forever.
Whatever happened to object-oriented programming and abstraction? Why can't you define and provide a consistent API?
On Fri, Apr 24, 2009 at 3:06 PM, Aryeh Gregor <Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com
wrote:
On Fri, Apr 24, 2009 at 4:59 PM, Brian Brian.Mingus@colorado.edu wrote:
I am just hoping to prevent a repeat of ParserPP.
A *lot* more extensions use parser-related stuff than preferences. In any event, the upheaval of ParserPP was probably necessary given what it sought to achieve. That sort of thing happens from time to time -- it's not feasible for extensions with access to so many hooks and methods to just work forever.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
APIs change in incompatible ways sometimes. When it's avoidable, that's great. Andrew seems to indicate that in this case, it wasn't possible to keep the hooks identical to how they were. That's why its best to keep extensions in svn so developers can easily spot and fix issues like this when they arise.
-Chad
On Fri, Apr 24, 2009 at 6:50 PM, Brian Brian.Mingus@colorado.edu wrote:
Whatever happened to object-oriented programming and abstraction? Why can't you define and provide a consistent API?
On Fri, Apr 24, 2009 at 3:06 PM, Aryeh Gregor <Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com
wrote:
On Fri, Apr 24, 2009 at 4:59 PM, Brian Brian.Mingus@colorado.edu wrote:
I am just hoping to prevent a repeat of ParserPP.
A *lot* more extensions use parser-related stuff than preferences. In any event, the upheaval of ParserPP was probably necessary given what it sought to achieve. That sort of thing happens from time to time -- it's not feasible for extensions with access to so many hooks and methods to just work forever.
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
Brian wrote:
Whatever happened to object-oriented programming and abstraction? Why can't you define and provide a consistent API?
The old preferences system didn't use anything like that, which is why it needed to be totally rewritten. The old system was basically a hardcoded form and extensions had to add preferences by appending to the HTML.
While backwards compatibility is nice, if it stands in the way of improving something that needs improvement, the improvement should take priority.
On 4/24/09 4:38 PM, Alex wrote:
While backwards compatibility is nice, if it stands in the way of improving something that needs improvement, the improvement should take priority
Indeed - even Microsoft eventually abandoned Windows 3.1 compatibility... And more recently compatibility with all software in existence.
- Trevor
On Fri, Apr 24, 2009 at 6:50 PM, Brian Brian.Mingus@colorado.edu wrote:
Whatever happened to object-oriented programming and abstraction? Why can't you define and provide a consistent API?
Object-oriented programming and abstraction do not magically avoid the problem of requirements and functionality changing over time. It's possible to provide a very stable API, but it takes a lot of work. It's necessary for, say, an operating system (and even they often mess up), but it's just not worth it in most other cases. Firefox extensions also sometimes break on upgrade, for instance. The same is true for extension mechanisms in the large majority of software.
You have to weigh the costs against the benefits in all cases. Since no actual significant costs have yet been presented here, this whole line of discussion seems like a tempest in a teapot.
On Fri, Apr 24, 2009 at 5:59 AM, Andrew Garrett agarrett@wikimedia.orgwrote:
I've branch-merged the new preferences system that I've spent the last few weeks developing.
On the outside, you probably won't notice any difference except a few bugfixes, but the internals have undergone a complete rewrite.
All of the actual preference definitions and utility functions have been separated out into Preferences.php, which holds all business logic for the new system. The UI and submission logic for the system is done in SpecialPreferences.php, which, now only a hundred lines long, wraps a generic class I've written to encourage separation of business and UI logic called 'HTMLForm'.
The advantage of this clear separation is that writing an API module is very simple, and it can be called internally, too!
Extensions must now hook GetPreferences instead of the existing hooks (which were too low-level to maintain compatibility with), I've updated all extensions used on Wikimedia. This new hook allows you to put preferences wherever you want, and a new preference can be added in less than ten lines of code, rather than the hundred-line nightmare that was required in the previous iteration.
I'd like to look towards trimming some of the existing preferences that are no longer relevant, and adding new preferences as common sense dictates.
Feedback, praise and criticism regarding the changes is certainly welcome!
-- Andrew Garrett Sent from Sydney, Nsw, Australia
You are so useful.
Hi!
On Thu, Apr 23, 2009 at 8:59 PM, Andrew Garrett agarrett@wikimedia.org wrote:
The advantage of this clear separation is that writing an API module is very simple, and it can be called internally, too!
I think will be good idea to use API internally (not only have possibility to call), as result code will have more testing and coverage.
Eugene.
thanks, I take this as the first step in creating global preferences?
On Fri, Apr 24, 2009 at 9:36 AM, Eugene Zelenko eugene.zelenko@gmail.comwrote:
Hi!
On Thu, Apr 23, 2009 at 8:59 PM, Andrew Garrett agarrett@wikimedia.org wrote:
The advantage of this clear separation is that writing an API module is very simple, and it can be called internally, too!
I think will be good idea to use API internally (not only have possibility to call), as result code will have more testing and coverage.
Eugene.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Le 24 avr. 09 à 16:15, John Doe a écrit :
thanks, I take this as the first step in creating global preferences?
Global preferences were added with this rewrite. There is just a checkbox saying "use these preferences on all projects" at the bottom of Special:Preferences.
Alexandre Emsenhuber (ialex)
On 4/24/09 6:36 AM, Eugene Zelenko wrote:
Hi!
On Thu, Apr 23, 2009 at 8:59 PM, Andrew Garrettagarrett@wikimedia.org wrote:
The advantage of this clear separation is that writing an API module is very simple, and it can be called internally, too!
I think will be good idea to use API internally (not only have possibility to call), as result code will have more testing and coverage.
My general inclination is to structure code into a couple layers:
Backend/internal interface: * Wraps over direct database, processing, etc
User interface: * Web UI * API module
Client-side JavaScript UI code can use the API to reach the backend, but I don't see much benefit to trying to use the API on the PHP UI end; it'll generally just be awkward.
API code should rarely have to do any serious DB or processing work itself; it should be calling the backend model/controller-level interface.
-- brion
On Sat, Apr 25, 2009 at 3:08 AM, Brion Vibber brion@wikimedia.org wrote:
On 4/24/09 6:36 AM, Eugene Zelenko wrote:
On Thu, Apr 23, 2009 at 8:59 PM, Andrew Garrettagarrett@wikimedia.org wrote:
The advantage of this clear separation is that writing an API module is very simple, and it can be called internally, too!
I think will be good idea to use API internally (not only have possibility to call), as result code will have more testing and coverage.
Client-side JavaScript UI code can use the API to reach the backend, but I don't see much benefit to trying to use the API on the PHP UI end; it'll generally just be awkward.
API code should rarely have to do any serious DB or processing work itself; it should be calling the backend model/controller-level interface.
I mean, of course, that the back-end business logic interface can be called internally, not that the API can be called internally.
How many non-WMF extensions will this break?
On Thu, Apr 23, 2009 at 9:59 PM, Andrew Garrett agarrett@wikimedia.orgwrote:
I've branch-merged the new preferences system that I've spent the last few weeks developing.
On the outside, you probably won't notice any difference except a few bugfixes, but the internals have undergone a complete rewrite.
All of the actual preference definitions and utility functions have been separated out into Preferences.php, which holds all business logic for the new system. The UI and submission logic for the system is done in SpecialPreferences.php, which, now only a hundred lines long, wraps a generic class I've written to encourage separation of business and UI logic called 'HTMLForm'.
The advantage of this clear separation is that writing an API module is very simple, and it can be called internally, too!
Extensions must now hook GetPreferences instead of the existing hooks (which were too low-level to maintain compatibility with), I've updated all extensions used on Wikimedia. This new hook allows you to put preferences wherever you want, and a new preference can be added in less than ten lines of code, rather than the hundred-line nightmare that was required in the previous iteration.
I'd like to look towards trimming some of the existing preferences that are no longer relevant, and adding new preferences as common sense dictates.
Feedback, praise and criticism regarding the changes is certainly welcome!
-- Andrew Garrett Sent from Sydney, Nsw, Australia
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hoi, How much work do you think it will be to repair an extension that needs repair ? For someone who knows the code and for someone who just has to repair his one extension ?? Thanks, GerardM
2009/4/24 Brian Brian.Mingus@colorado.edu
How many non-WMF extensions will this break?
On Thu, Apr 23, 2009 at 9:59 PM, Andrew Garrett <agarrett@wikimedia.org
wrote:
I've branch-merged the new preferences system that I've spent the last few weeks developing.
On the outside, you probably won't notice any difference except a few bugfixes, but the internals have undergone a complete rewrite.
All of the actual preference definitions and utility functions have been separated out into Preferences.php, which holds all business logic for the new system. The UI and submission logic for the system is done in SpecialPreferences.php, which, now only a hundred lines long, wraps a generic class I've written to encourage separation of business and UI logic called 'HTMLForm'.
The advantage of this clear separation is that writing an API module is very simple, and it can be called internally, too!
Extensions must now hook GetPreferences instead of the existing hooks (which were too low-level to maintain compatibility with), I've updated all extensions used on Wikimedia. This new hook allows you to put preferences wherever you want, and a new preference can be added in less than ten lines of code, rather than the hundred-line nightmare that was required in the previous iteration.
I'd like to look towards trimming some of the existing preferences that are no longer relevant, and adding new preferences as common sense dictates.
Feedback, praise and criticism regarding the changes is certainly
welcome!
-- Andrew Garrett Sent from Sydney, Nsw, Australia
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
On Sat, Apr 25, 2009 at 1:46 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, How much work do you think it will be to repair an extension that needs repair ? For someone who knows the code and for someone who just has to repair his one extension ??
It's a reasonably simple fix. Here's an example: [1]
Essentially, all you need to do is remove your existing preferences code, hook GetPreferences, and add your preference to the array. I'll be posting documentation as to the format of preference entries tomorrow, but for now you can look at the examples in includes/Preferences.php.
[1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/49690
Is an autoconverter feasible? There are many, many extensions guys!
On Fri, Apr 24, 2009 at 9:53 AM, Andrew Garrett agarrett@wikimedia.orgwrote:
On Sat, Apr 25, 2009 at 1:46 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, How much work do you think it will be to repair an extension that needs repair ? For someone who knows the code and for someone who just has to repair his one extension ??
It's a reasonably simple fix. Here's an example: [1]
Essentially, all you need to do is remove your existing preferences code, hook GetPreferences, and add your preference to the array. I'll be posting documentation as to the format of preference entries tomorrow, but for now you can look at the examples in includes/Preferences.php.
[1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/49690
-- Andrew Garrett Sent from Sydney, Nsw, Australia
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
And the vast vast majority don't use preferences. I don't think it'll be a huge issue. The extensions that are broken and people use will quickly be found and fixed.
-Chad
On Fri, Apr 24, 2009 at 12:43 PM, Brian Brian.Mingus@colorado.edu wrote:
Is an autoconverter feasible? There are many, many extensions guys!
On Fri, Apr 24, 2009 at 9:53 AM, Andrew Garrett agarrett@wikimedia.orgwrote:
On Sat, Apr 25, 2009 at 1:46 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, How much work do you think it will be to repair an extension that needs repair ? For someone who knows the code and for someone who just has to repair his one extension ??
It's a reasonably simple fix. Here's an example: [1]
Essentially, all you need to do is remove your existing preferences code, hook GetPreferences, and add your preference to the array. I'll be posting documentation as to the format of preference entries tomorrow, but for now you can look at the examples in includes/Preferences.php.
[1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/49690
-- Andrew Garrett Sent from Sydney, Nsw, Australia
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
2009/4/24 Chad innocentkiller@gmail.com:
And the vast vast majority don't use preferences. I don't think it'll be a huge issue. The extensions that are broken and people use will quickly be found and fixed.
How gracefully will old extensions fail?
On Fri, Apr 24, 2009 at 12:59 PM, Thomas Dalton thomas.dalton@gmail.com wrote:
2009/4/24 Chad innocentkiller@gmail.com:
And the vast vast majority don't use preferences. I don't think it'll be a huge issue. The extensions that are broken and people use will quickly be found and fixed.
How gracefully will old extensions fail?
I'd assume fatally, but extensions sometimes break when core code updates. That's a fact of life. One way to avoid this is to ask to get it checked into Wikimedia SVN, so a grep can show that there are users and they can be fixed by whoever makes the breaking change.
On 4/24/09 10:34 AM, Aryeh Gregor wrote:
On Fri, Apr 24, 2009 at 12:59 PM, Thomas Daltonthomas.dalton@gmail.com wrote:
2009/4/24 Chadinnocentkiller@gmail.com:
And the vast vast majority don't use preferences. I don't think it'll be a huge issue. The extensions that are broken and people use will quickly be found and fixed.
How gracefully will old extensions fail?
I'd assume fatally, but extensions sometimes break when core code updates. That's a fact of life. One way to avoid this is to ask to get it checked into Wikimedia SVN, so a grep can show that there are users and they can be fixed by whoever makes the breaking change.
I believe they'll just not have their extended preferences displayed until they've updated to work with the non-crappy, actually sanely extensible, preferences interface.
Nothing else would be affected.
-- brion
wikitech-l@lists.wikimedia.org