Dmitriy Sintsov (2011-07-21 09:48):
Brion Vibber<brion(a)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