This makes it so that if you do not have WikiEditor enabled, you also
will not have CodeEditor enabled. In the feedback we have seen so far,
this seems to be desirable for those users (bug 55936).
Also people were not able with the cookie pref for the editor, because
it can easily expire. This introduces a hidden pref, controlled by the
enable/disable CodeEditor button, to preserve this value instead (bug
46779).
It also gives a more reliable way to detect if the editor is enabled or
disabled. mw.user.options.get( 'usebetatoolbar' ) and
mw.user.options.get( 'usecodeeditor' ) combined should be able to convey
this information to something like WikEd (bug 62250).
Bug: 46779
Bug: 62250
Bug: 55936
Change-Id: I4639f68c00a2b9183a6f89b5e00983c07a8592a2
The test for $title->isCssJsSubpage() seems to have gotten lost in
the refactoring in r110794, so enabling CodeEditor for core only
affects the MediaWiki namespace. This restores that test, so user css/js
subpages also get CodeEditor when $wgCodeEditorEnableCore is true.
Change-Id: Id02825f922a1ed0aace7c9ffd940fe8d29bb5d79
Scribunto requires that the CodeEditor extension be installed, but I
haven't reviewed CodeEditor for its primary use case, i.e. CSS and
JS. The automatic brace close feature in JS mode might be annoying for
some. I'm ready to deploy Scribunto but the CodeEditor core
functionality will need to be deployed separately.
Change-Id: I0d423563cc13f9f8ec00590c8e16273d10f1dbce
Not ready for prime-time. :) Doesn't actually save pages (just updates the live view), and seems to have problems when invoked multiple times.
Not all GeSHi languages are supported.
Colors of course are different.
Set $wgCodeEditorGeshiIntegration = true to enable; adds a 'section edit link' on source bits.
Simply using the existing gadget version modified to load Ace from the extension directory for now, will integrate better into WikiEditor and use ResourceLoader to load Ace itself in upcoming commits.
