(CC'd inez @ wikia)
In the process of getting a better feel for the current state of Wikia, Wikihow, & a few others' rich text editor tools, I'm going through Wikia's CKEditor-based RTE extension and seeing if I can get it working on MediaWiki trunk.
I've got a fork from Wikia's SVN in this gitorious project: http://www.gitorious.org/mediawiki-wikia-rte
The 'master' branch is a straight git-svn clone of the subtree; 'tweaks' branch has some extra doc comments and some initial tweaks to get it loading (if not actually working right yet ;) on stock MediaWiki 1.18-SVN.
Current state: * most stuff won't work yet! * the editor can be loaded if forced with &useeditor=wysiwyg * load/save results in some corruption, probably mostly due to the parser annotations not all being present (need to customize a few bits) * the editor is loaded through ResourceLoader, using a quick stub to work around the lack of removal of certain lines * it's almost certain that the CSS and some JS is broken :D * there are various Wikia-specific PHP-side and JS-side extensions, many of which still need to be switched to the stock MW equivalent or copied over. Note that definitions for such things can usually be found in the modified MediaWiki core in Wikia's SVN tree -- https://svn.wikia-code.com/wikia/trunk/
At a minimum I'd like to end up with something that works on stock MediaWiki 1.18 (and if it can be made to work on stock or lightly-patched 1.17, even better!). It should be a more stable option for 1.17 users than the old FCKEditor extension.
I'm still a bit leery of the internal annotations & edge-case checks for the round-tripping and whether this structure would work for us in the long term, but there's some good stuff in here that's going to be useful to learn from whatever we do, and it's a useful tool for many cases in the short term.
If anybody feels like trying it out / pitching in on the fixes, do feel free to give a shout. I can set a few folks up with commit access on the git repo or take some pulls for now, and will merge it into our SVN extensions when it's a bit more stable.
-- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
On Thu, May 5, 2011 at 5:03 PM, Brion Vibber brion@pobox.com wrote:
(CC'd inez @ wikia)
In the process of getting a better feel for the current state of Wikia, Wikihow, & a few others' rich text editor tools, I'm going through Wikia's CKEditor-based RTE extension and seeing if I can get it working on MediaWiki trunk.
I've got a fork from Wikia's SVN in this gitorious project: http://www.gitorious.org/mediawiki-wikia-rte
The 'master' branch is a straight git-svn clone of the subtree; 'tweaks' branch has some extra doc comments and some initial tweaks to get it loading (if not actually working right yet ;) on stock MediaWiki 1.18-SVN.
I'm having some trouble adapting the RTELinker class, which adds annotation to some link & header structures and removes the table of contents; now that these base Linker functions have moved to static methods on the Linker class (with a back-compatibility magic forward from Skin instance methods) there's no way to replace them by passing in a custom skin with overrides -- Parser and friends call Linker directly so don't see the custom code.
Some of them I can adapt existing hooks for, but I may need to add a couple more hooks.
-- brion
On Fri, May 6, 2011 at 12:11 PM, Brion Vibber brion@pobox.com wrote:
I'm having some trouble adapting the RTELinker class, which adds annotation to some link & header structures and removes the table of contents; now that these base Linker functions have moved to static methods on the Linker class (with a back-compatibility magic forward from Skin instance methods) there's no way to replace them by passing in a custom skin with overrides -- Parser and friends call Linker directly so don't see the custom code.
Some of them I can adapt existing hooks for, but I may need to add a couple more hooks.
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.
-- brion
* Brion Vibber brion@pobox.com [Fri, 6 May 2011 16:34:20 -0700]:
On Fri, May 6, 2011 at 12:11 PM, Brion Vibber brion@pobox.com wrote:
I'm having some trouble adapting the RTELinker class, which adds
annotation
to some link & header structures and removes the table of contents;
now that
these base Linker functions have moved to static methods on the
Linker
class
(with a back-compatibility magic forward from Skin instance methods)
there's
no way to replace them by passing in a custom skin with overrides --
Parser
and friends call Linker directly so don't see the custom code.
Some of them I can adapt existing hooks for, but I may need to add a
couple
more hooks.
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*
Dmitriy
On Thu, Jul 21, 2011 at 12:48 AM, Dmitriy Sintsov questpc@rambler.ruwrote:
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.
It's not going anywhere; as you see there's still a lot of things referencing custom Wikia bits that just aren't available, and the jillions of custom hooks are also missing so it doesn't actually work. My initial modernization effort on it has been abandoned, though it's still a good source of info to look at and learn from.
-- brion
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.
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
I see a pile of bugs on FCK Editor have been resolved "invalid" because upstream have declared MediaWiki unsupported.
So what are the current options for WYSIWYG editing, even non-ideal ones? I believe this leaves none ...
- d.
On Thu, Jul 28, 2011 at 3:41 AM, David Gerard dgerard@gmail.com wrote:
I see a pile of bugs on FCK Editor have been resolved "invalid" because upstream have declared MediaWiki unsupported.
So what are the current options for WYSIWYG editing, even non-ideal ones? I believe this leaves none ...
- d.
I've reverted the extension's removal from SVN. It works fine with 1.17 (I'll see if I can fix it with trunk).
Dmitriy Sintsov wrote:
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
MediaWiki is largely backwards compatible. An extension designed for 1.15 is very likely to still work in trunk version (even though it may not get advantage of ResourceLoader, for instance). There are some core changes that affect extensions, but in such cases we usually update the extensions, too. Just download it from the appropiate branch.
* Platonides Platonides@gmail.com [Thu, 28 Jul 2011 23:14:32 +0200]:
MediaWiki is largely backwards compatible. An extension designed for 1.15 is very likely to still work in trunk version (even though it may not get advantage of ResourceLoader, for instance). There are some core changes that affect extensions, but in such cases
we
usually update the extensions, too. Just download it from the
appropiate
branch.
Speaking of server-side (php interface), yes, MediaWiki is largely backwards compatible (except for static call Linker::link() and few ancient things, like wfLoadExtensionMessages‎() and so on). Speaking of client-side (Javascript), it is not so simple. Since 1.17, I am experiencing weirdness with client-side scripts in non-ResourceLoader ready extensions. For example my own Extension:QPoll had minor glitches until I've ported it to ResourceLoader. I guess that is because the scripts are now loaded at bottom, not at the top, or maybe due to jQuery introducing it's own scopes, while old scripts were assuming to have run in window scope. However, QPoll has very little tiny client-side script, while Extension:CategoryBrowser also have glitches and scripts are much larger - I still don't have the time to port it. In contrary to claims that Extension:FCKeditor works fine in 1.17, I've experienced opposite with my own Vector-based skin, not Monobook skin. Of course, I might try again, however I really disliked the way the extension is coded - with assumption that Monobook skin is being used, unreliable tricks with Parser and so on. Dmitriy
Dmitriy Sintsov (2011-07-29 07:54):
Speaking of server-side (php interface), yes, MediaWiki is largely backwards compatible (except for static call Linker::link() and few ancient things, like wfLoadExtensionMessages‎() and so on). Speaking of client-side (Javascript), it is not so simple. Since 1.17, I am experiencing weirdness with client-side scripts in non-ResourceLoader ready extensions. For example my own Extension:QPoll had minor glitches until I've ported it to ResourceLoader. I guess that is because the scripts are now loaded at bottom, not at the top, or maybe due to jQuery introducing it's own scopes, while old scripts were assuming to have run in window scope. However, QPoll has very little tiny client-side script, while Extension:CategoryBrowser also have glitches and scripts are much larger - I still don't have the time to port it.
I think you shouldn't use mw.whatever stuff just yet (so the code will be backward compatible). Most of the stuff was already available just phrased differently. I think you should use jQuery anyway where you can instead of wikibits functions, though (e.g. $() instead of addOnloadHook()).
As for bottom/top this should probably a problem only for move from 1.16 to 1.17 rather then the other way around. So if you managed to make it work for 1.17 it should work for 1.16.
In contrary to claims that Extension:FCKeditor works fine in 1.17, I've experienced opposite with my own Vector-based skin, not Monobook skin. Of course, I might try again, however I really disliked the way the extension is coded - with assumption that Monobook skin is being used, unreliable tricks with Parser and so on.
From what I've seen the problem is not a Vector skin itself but the new wikieditor (editor toolbar). If you will disable it it should be fine.
Regards, Nux.
wikitech-l@lists.wikimedia.org