As it actually defaults to either null or (string)$default, not $default.
So therefore getVal( 'key', false ) will never return false, even if 'key' is
not set.
Change-Id: Ibe6beae9d2c4a19ff59d1035564f17373298529d
* Fix errors and warnings from phpcs.
* Add commas at end of lines for arrays in PHP.
* Add space between // and comment.
* Add space between ) and {.
* Use tabs instead of spaces for indenting.
* Break lines in PHP with more than 100 characters.
* Remove double spaces and spaces at end of line.
* Remove spaces before comma.
* Fix some typos.
Change-Id: I9c014bdfa9832fa6a20d0190fe2fc668983d0fb9
Otherwise it will fail to validate for anonymous users (getEditCount returns null)
as it is a required field
Change-Id: I3d438cfde172b2598955773c4c22fc2d4a502f16
This patch replaces the manually operated test module for ext.wikiEditor.toolbar
with one based on QUnit. The new test suite uncovered a bug with the removeFromToolbar
API function in jquery.wikiEditor.toolbar, which prevented the removal of select buttons
from the toolbar. This issue has also been fixed in this commit. .jshintrc was updated
to ignore the new QUnit global.
Bug: T39485
Change-Id: Icef3debcffa484a8d78628bcd9da0892b750bb40
Together with solving bug 29908, this makes the presence of the
toolbar consistent. It is added to pages handling wikitext.
Note that we provide the CodeEditor on all JS/CSS/Lua pages.
Bug: 24713
Bug: 24041
Change-Id: Iaa6b9a6c511380ed1669d8b95cba4a3ddc6f9ab6
Add a new styles module. This module makes sure that the textarea is
already properly styled (jumping lineheight bug) before we start the
JS. Also hide the toolbar before it's styles have finished loading, so
you don't see it being constructed on the fly. Move inline styling for
the old toolbar into this stylesheet as well.
Bug: 47708
Change-Id: I40bec0a24dbd295db301e7faefb93d8991981acb
The WikiEditor is the default since a long time now. It does not
make much sense to still call it "Beta". This depends on my other
change to the core preferences because of the new word that needs
to be translated.
Depends on I429c8125b8db789d2756d61249f6cf1fa7f2f51c.
Change-Id: Id8b9a47a9d83dc1acdec46cb6e993deac33cc066
ClickTracking is deprecated; the config var gating this behavior is set
to false; the data is going to /dev/null; no one is interested in
analyzing it. I think it's dead, Jim.
Change-Id: I71ea8c174e5e38b28f128ccd380ed2a25ad50606
Fix for bug 24172, by extending the wikieditor with a file
dialog (like the table and link dialog) for adding files with exended
syntax.
The added syntax is localised. This also fixes bug 24114, and the redirect
button now adds localised magic word.
Change-Id: I5950b530ab8c55aeba4b579cc80ce863f228d373
Instead of wiping the old toolbar out on the server side we now just wrap the old toolbar in a div that has an inline style that prevents it from being displayed. This is only done when the toolbar is enabled. When the toolbar code runs on the client, if the toolbar ends up being incompatible, the old toolbar's wrapping div is shown. This avoids the side-effect of the old toolbar showing up momentarily while the new toolbar loads. It's a dirty hack, but we explored this extensively and it's the least evil way we could come up with that worked consistently.
Change-Id: I6fefadea4dbd01b96a0b95c50bc9ef526144dc3c
This is still broken in production right now: the preference message is
missing and disabling the preference doesn't disable the toolbar.
Reverting this because it just doesn't work right now.
This reverts the following commits:
4234c5ddc7 "Fix syntax error in I1adc6b99fa3e1980d4ce3c565b5f193bcbceb526"
00eee72543 "modified as per bug 35879"
00eee72543 "(bug 30796) Dropping preferences for toolbar"
Change-Id: I882a6e0c0cc70f9afecb49746f3db01eab8808dc
Re-added the preference for toolbar I had removed by mistake in change 4339
made global=false and user=true for toolbar,as it was before my changes
for dialogs global=true and user=false is retained as now the user cannot
control dialogs in preferences and it is always on
Patchset 3 (Roan): enable WikiEditor preference by default
Change-Id: I1adc6b99fa3e1980d4ce3c565b5f193bcbceb526
* I left MwEmbed alone since it was scary.
* I left the half-completed commented-out ResourceLoader code in Maps as it was
* PrefSwitch was apparently broken, with a typo in remoteBasePath.
* ClickTracking and ProofreadPage now demostrate two different styles of multi-module registration. Choose which one you prefer.
* SemanticMediaWiki/SMW.hooks.php became empty and was deleted.
* Tested using a special script that includes extension setup files and checks $wgResourceModules for correctness.
What actually happens here
* Add $localBasePath, $remoteBasePath params to the FileModule constructor, defaulting to $IP and $wgScriptPath respectively
* Add getLocalPath() and getRemotePath(), which use this information to build a proper FS or URL path for a file
* Make readScriptFiles() non-static so it can use these functions
* Run every single file path we use through either getLocalPath() or getRemotePath() as appropriate
** Except file dependencies, these are already prefixed. Our inability to give them special treatment caused bugs earlier
* Kill prefixFilePathList() and resolveFilePath(), no longer needed
* Abstracted the requirements concept being used to hack in the iframe as a context extension requirement
* Removed some hardcoding for iframe stuff
* Moved about 60k of JavaScript code out of the main wikiEditor script, and into an iframe only context extension.
