This was an unfinished module to enable the CodeEditor to do inline
editing of <syntaxhighlight> blocks. It was never finished and I think
that with the VE and WE 2017 work, it likely will never be finished
either. For that reason, it is better to remove it altogether.
Change-Id: I83714188a53d2ca6bb7bf0dc6d0c89b7fb45a47a
Most of the time people want to trigger on content model, or content
format. This allows triggering correctly even if you are viewing an
old revision with a different content model, or are using a content
format that is different than the default for the current model.
Also remove back compat code for pre 1.23
Change-Id: I9706eaae0983e2b7b99f83c9564ea04c5ec252ac
Instead of running the jshint test through jenkins, Run it through npm
instead.
Also add composer.json for running php code sniffer and phplint instead of
running phplint through jenkins.
Also update grunt-jsonlint to 1.0.6
Change-Id: Icd9aa1b1c7213d056aa5294a804341053141b0bd
This style module hides the old toolbar while loading and
avoids horizontal resize of the textarea with disabled syntax highlight.
Bug: T102738
Bug: T102739
Change-Id: I41f16f1a5034eeebf7b80a68ebded8a4442df8fa
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.
