Pre-save transform now accepts full width commas, and a parser test is added,
which passes. Originally done by Conrad Irwin, branched out by Tim in r62689
along with a bunch of other stuff, and then it sat in bugzilla for a few months.
Change-Id: I3302e43bab423835cdaee6bdcfc0252a206490fc
This whitespaces causes an extra empty paragraph between text and transcluding a special page.
When a heading precedes a transcluded special page, there is no difference and it's fine with or without this whitespace.
See for example http://incubator.wikimedia.org/w/index.php?title=Incubator:Sandbox&oldid=822299
Change-Id: I6b06006d921368619d3969660c244176344e8aff
rename MWNamespace::isNonincludableNamespace
to MWNamespace::isNonincludable, because "Namespace" is already in the
class name
Change-Id: Ie982835c7dc84cb10c823996e5360cc1b342f704
Method is a wrapper around $wgNonincludableNamespaces,
replaced the one place in parser and
add it as info to api's meta=siteinfo
Change-Id: I501b811137c39f5c2d9ea35c78fef8ae22d21bfe
With 1.20wmf2 we get a tracking category with all the problem pages,
seeing the limit for a page is a helpful information than
Change-Id: I1916e5fa6de06b923a01cf1f0ca9362287a9fd70
The patch adds an optional parameter |link= to the <gallery>
tag. This will allow for images to link to other pages and
externals urls instead of being hardlinked to the image file
that is displayed in the gallery.
Here are a couple of examples.
Link as WikiLink:
<gallery>
File:20120106_001.jpg|link=Main_Page
</gallery>
Link as absolute URI:
<gallery>
File:20120106_001.jpg|my caption|alt=my alt
text|link=http://bugzilla.wikimedia.org
</gallery>
this would cause the link on the thumbnails rendered by the gallery tag to link
to a custom page/url instead of the actual media/image.
a link should be an internal wiki link or an absolute uri as shown in the examples.
Change-Id: I21b276ad5c7a8df13b3a716957d23fd53c37d29e
- MWCryptRand: A new api for generating cryptographic randomness for security tokens. Uses whatever cryptographic source is available and if not falls back to using random state and clock drift.
- wfRandomString - A simple non-cryptographic pesudo-random string generation function to replace wfGenerateToken which was written pretending to be secure when it's really not.
- Core updates to use MWCryptRand in various places:
-- user_token generation (to do this we stop generating user_token implicitly and only generate it when needed to avoid depleting the system's entropy pool by reading random data we'll never use)
-- email confirmation token generation
-- password salt generation
-- temporary password generation
-- Generation of the automatic watchlist token
-- login and create user tokens
-- session ids when php's entropy sources are not set
-- the installer when generating wgSecretKey and the upgrade key
* Introduced Parser::killMarkers() based on the concept from StringFunctions. Used it in cases where markerStripCallback() doesn't make sense semantically, namely grammar, padleft, padright and anchorencode. Used markerStripCallback() in other cases.
* Changed headline unstrip order as suggested by P.Copp on bug 18295
* In CPF::lc() and CPF::uc(), removed the is_callable(). This was a temporary testing hack committed by me in r30109, which allowed me to do differential testing against a copy of the parser from before that revision.
* Add @since, fix indentation.
* Change default from 'all' to 'mw' as it's the most used (so default fetchLanguageNames() is equivalent to default getLanguageNames()).
* Add the include parameter also to fetchLanguageName() as it's needed in Parser: interlanguage links should only take into account mediawiki names. (Doesn't make a difference with how the functions are now, but could have been later.)
Introduce a global variable which causes language conversion to not be disabled in interface messages (as before r94279). Use $wgContLang for conversion (as before r97849) since $wgContLang is set to the base language (e.g. zh) on converter wikis, whereas a typical user language (e.g. zh-tw) only has a FakeConverter.
* The language object used for lc() in Parser::braceSubstitution() must match the one used in setFunctionHook() during firstCallInit(). It can't change depending on what message you are parsing. Use $wgContLang like before r97849.
Fixes the problems with r102179 and r102179, as there are
valid tags which begin the same, which meant they were not removed from
the TOC (the second regex, intended to remove tag parameters, then converted
<img or <blockquote> into <i> / <b>).
The same problem existed in the original regex, but as there are no valid
tags which begin with sup or sub, it never happened).
Added comment explaining the tocline regex, and added a bunch of parser tests.
{{NAMESPACE}} relative to the Title of the currently being parsed page.
Basically wfMsgForContent expands messages with wrong title while doing linksupdate stuff via job queue. For the broken file tracking category (r86534),Wikipedia folk want to sort the page into different categories based on namespace, and for some namespaces not categorize them at all (After all, a broken file link in a talk namespace is often not a bad thing).
Anyhow, explicitly set the title object for the message using wfMessage. There's probably deeper issues here in regards to why wfMsg et al is using wrong title, but this should fix the immediate issue.
So far I've encountered 2 extensions that give fatal errors from calling $wgParser->disableOutput() from hooks that are called at points where parsing is not taking place! Exception with a backtrace is much nicer than "Fatal error: Call to a member function disableCache() on a non-object..."
Just skip the whole replaceInternalLinks2 parser function whenever we hit
js/css pages. Previous patch r103476 only handled Category links which was
not enough.
This patch skip the [[Category:#]] parsing logic when the Title is in
NS_MEDIAWIKI and ends with .js or .css. This way the code is kept as is
and pages are no more categorized.
How to reproduce the issue:
$ echo 'var foo = "[[Category:bug32450]]"' \
| php maintenance/parse.php --title MediaWiki:Foobar.js
<p>var foo = ""
</p>
$
Note how the text got stripped.
After this patch:
$ echo 'var foo = "[[Category:bug32450]]"' \
| php maintenance/parse.php --title MediaWiki:Foobar.js
<p>var foo = "[[Category:bug32450]]"
</p>
$
TEST PLAN:
==========
$ php parserTests.php --quiet
This is MediaWiki version 1.19alpha (r103473).
Reading tests from "tests/parser/parserTests.txt"...
Reading tests from "tests/parser/extraParserTests.txt"...
Passed 654 of 654 tests (100%)... ALL TESTS PASSED!
$
