On 28.07.2011 2:19, Maciej Jaros wrote:
Dmitriy Sintsov (2011-07-21 09:48):
Brion Vibberbrion@pobox.com [Fri, 6 May 2011 16:34:20 -0700]:
This gets a little scarier-looking once it turns out that the core Parser class has a hojillion little patches on it that the extension depends on, which do much of the annotation& placeholder insertion. I should be able to refactor most of those into either hooks or more cleanly-factored Parser methods that can be subclassed more directly in RTEParser; that'll make the extension's integration job a lot easier on a stock 1.18. Whee! Well one thing's for sure -- I'm going to have spent a lot more time looking at the guts of the current parser before this is done. ;) It's also definitely reminding me why I don't like our current parser code. ;) But a lot of it can be made cleaner and more extensible I think without any behavior changes, which gets us a long way in the short term.
I've cloned it from git://gitorious.org/mediawiki-wikia-rte/mediawiki-wikia-rte.git and I am having huge troubles even getting it to run without fatal errors in 1.17. It seems to require Wikia custom classes and extensions (WikiaSuperFactory, SASS, ThemeSettings- and more?) and also it accesses properties of Oasis skin (while I have my own Vector-derived skin with different name). I wonder should I spend some more days with it, or it's not going anywhere. I am having troubles finding stable and wide-browser supporting WYSIWYG editor for 1.17. FCKeditor worked with 1.15 (imperfect, but worked) but I already made quite enough of commits into my customer's 1.17 installation so I don't want to delete everything and start with 1.15 / 1.16 from scratch.. *sigh*
I'm almost sure we have plain 1.16 at work (not sure cause I'm on vacation) with FCKeditor extension. You just need to disable the new editor for it to work, but Vector skin works fine with it. I remember I've made some changes to the extensions CSS and made a bit of i18n/l10n, but don't remember of them being specific to 1.16 or in any way crucial. So I'm guessing you should be able to port everything back to 1.16. Just remember to get rid of mw.config thingies form JavaScript if you've used them already. You will also probably need to turn on jQuery as it was not available on all pages by default in 1.16.
Regards, Nux.
Currently I use mw.loader.load(), which can be replaced with importScriptURI(). However I don't want to go step back then move again to 1.17/1.18. I've managed to "postpone" visual editor thing, now I'll try to adapt few another extensions. I wanted RTE because it handles wikitext better, but I didn't know how large Wikia codebase was. It is work of large organization. While I am just a single "freelancer" with extremly limited time and funds.
Imagine, I've had issues with WMF Extension:TimedMediaHandler because it already was developed for yet unreleased 1.18, while the large part of non-WMF extensions are not even up to 1.16. Such a "lagging" codebase! How many time would it take to update the extensions? Even the major extensions like SocialProfile still do not use ResourceLoader. I am worrying that I bite myself with choosing 1.17 for my new customer's installation. That's why I've asked whether 1.16 can be made LTS (many years of bugfixes and extensions backcompatibility). If that is too much, maybe 1.17 can be such long-supported version? Dmitriy