The controller should pass through lines of input exactly as
they were provided, only stripping the trailing newline that
delimits items. The trim was making `door` and `door ` equivilant
but for the use case in search the distinction is important.
Additionally check that the line is actually empty, don't throw
away inputs like '0' which are falsy.
Change-Id: Ifac910543fdb46a27da021e831e3e18befefcfc5
apc is the pre-PHP 5.5 extension that was partly merged into PHP itself
(the opcode caching), and partly split into a separate apcu extension for
the userland caching. We want people to install apcu for better performance.
Note that we still need to support apc because of HHVM.
Change-Id: I5830a66bc86ff321bf9141d2b65eedb4802e404f
Things like "Catchable fatal error: Must be X, null given" stop
execution immediately after the error handler callback, and produce
an HTTP 500 Internal Server Error page. They are very fatal.
Per <https://secure.php.net/manual/en/language.errors.php7.php>,
on PHP 7 this results in a TypeError throwable which will
eventually fatal the request and be reported through
set_exception_handler, or be caught by our top-level 'catch'
and artificially forwarded to our set_exception_handler callback.
On HHVM, these fatal error types are PHP5-like in that they
don't have a throwable object to throw yet, instead the error
meta-data is sent directly as parameeters to set_error_handler,
the same as for warnings. We need to intercept them there so
that they are reported correctly.
Sample from PHP 7:
> MediaWiki\Storage\MutableRevisionRecord::newFromParentRevision( null );
> [no req] TypeError from line 50 of .../MutableRevisionRecord.php:
> Argument 1 passed to ...\MutableRevisionRecord::newFromParentRevision()
> must be an instance of MediaWiki\Storage\RevisionRecord, null given,
> called in /var/www/mediawiki/maintenance/eval.php(78) ...
[exit status: error(255)]
Sample from HHVM:
> MediaWiki\Storage\MutableRevisionRecord::newFromParentRevision( null );
> [hphp] set_error_handler called with:
> ... $type = 4096 // E_RECOVERABLE_ERROR
>
> [hphp] [...] Catchable fatal error:
> Argument 1 passed to ...\MutableRevisionRecord::newFromParentRevision()
> must be an instance of MediaWiki\Storage\RevisionRecord, null given
> ...
[exit status: error(255)]
Interestingly, if you forget to return false from set_error_handler
for fatal errors on HHVM, it can actually continue execution.
Bug: T205677
Change-Id: I18dd2ff37fa2c2679d0c598cbeff0c61c2fe0253
Running update.php for new wikis without any revisions yet fails when
update.php attempts to run populateArchiveRevId.php. This problem
does not exist if using the web installer or running
maintenance/install.php, since both of these generate a Main Page
revision. Manually generating a MediaWiki database by sourcing
maintenance/tables.sql does not generate any revisions, and thus is
susceptible to this problem.
Bug: T203982
Change-Id: Ifd78c50fb1e11f82340cd83a10fa903b7c5fc1e7
Localized messages are wikitext and can contain `<div>` or `\n\n` which
would break `<p>` wrappers. Be consistent with the rest of the codebase
and use `<div>` wrappers here.
Bug: T205624
Change-Id: I1e8ff5985f3a7780ad9ba063827c515e997cb508
The template on commons for newimagestext has a <div> wrapper,
and trying to wrap a <p> around a <div> doesn't work: the <p> is
implicitly closed by the start of the <div>. Use a <div> wrapper
to set the content language and directionality instead, which ensures
that it is valid HTML and will be tidied correctly.
In the process, fix an extra argument (and unnecessary optional argument)
passed to OutputPage::addWikiTextTidy in
Ife33ceed39ed01d4e9af18e9108026f341e9b343.
Bug: T205624
Change-Id: I42d198e6d03afd5b976da741f235c175bfe9f767
* Remove the forced line break, which is not necessary for old
preferences page and which makes it worse for the new OOUI
preferences page
* Remove the italic styling, which is not used by any other
preferences
Change-Id: Ie80583c82d8e748e063f7d831ebb3bb20dc2b64a
Follow-up to a89ef9b3b9. I'm guessing
this is supposed to be htmlspecialchars() based on the changes to
other files in that patch (e.g. SpecialAncientpages.php).
Bug: T205469
Change-Id: I52e38a5754b339e1516498e6f0eb73fc8d8df59c
"Internal lookups need to be internal, using ./.
This currently works because it executes as part of mediawiki-core, but
may fail when used from the published package, because there will not
be another "wdio-mediawiki" inside this directory." krinkle
Follow-up to a fixme in Ifc49bc5c06eef71da8aff1b1837c32debc2c45dd
Change-Id: I86f321a42eaf4cf706b4e899e4cd460654840284
This header can be injected into api responses that include
search results to provide a link between the backend logs
and any frontend logging. Associating autocomplete tracking
with backend logs will allow us to determine autocomplete
examination probabilities, and more generally be able to
evaluate autocomplete effectiveness.
Bug: T205348
Change-Id: I1663906e2fd71f7df215e563b09a0b4fb8948ab8
This change parallels the new method added to OutputPage in
Ia58910164baaca608cea3b24333b7d13ed773339 and ensures that the
content added is always tidied. We leave the old alias in
place for now in accordance with our deprecation policy.
Change-Id: I89f3398cffa771afcd5a33cfd11eb8510af3e7f7
The default for OutputPage::addWikiText is $interface=true, which
suppresses language conversion and treats the output as being in
the user interface language.
Change-Id: Ife33ceed39ed01d4e9af18e9108026f341e9b343
There are three methods affected: `OutputPage::addWikiTextTidy()`,
`OutputPage::addWikiTextTitleTidy()`, and
`OutputPage::addWikiTextWithTitle()`.
There's a special case in Parser.php which adds the wrapper class from
ParserOptions to the ParserOutput only if "interface mode" is off; the
affected methods default to adding output in "content language" mode
(not "interface language" mode), but they seem to be used for
"interface messages in the content language" (rare) and so should also
be unwrapped. This would make all the `OutputPage::addWikiText*()`
methods consistent.
The `OutputPage::addWikiTextTidy()` method is only used once in the WMF
repositories, where it is used to insert an interface message in the
content language:
91cd2a928f/SpecialProofreadPages.php (40)
The `OutputPage::addWikiTextWithTitle()` method is used by no one:
https://codesearch.wmflabs.org/search/?q=addWikiTextWithTitle%5C(
The `OutputPage::addWikiTextTitleTidy()` method is used only in core:
3888c001a1/includes/EditPage.php (2669)
It seems clear that the output in this case is intended to be
unwrapped as well (the codepath adds its own explicit wrapper).
Ia58910164baaca608cea3b24333b7d13ed773339 will add additional
documentation to clarify the distinction between the different
OutputPage::addWikiText*() methods, but I felt it safer to make
this particular change first as a standalone patch, just in case
it had unexpected side effects or merited further discussion.
Change-Id: I3e5b598d358819191562b56d40ebf1cb6f3cda41
We are deprecating the non-tidy modes of the parser.
While we're at it, remove the output wrapper by default (in
both tidy and no-tidy modes).
Bug: T198214
Change-Id: Ieb51cb0f3a8a62e272d76c368f29fb63c030c522
`OutputPageTest::testMakeResourceLoaderLink()` and
`OutputPageTest::testBuildExemptModules()` tried to force
`$wgResourceLoaderDebug=false` before running the test, but they
neglected to clear the resource loader debug cache
(`ResourceLoader::clearCache()`) so the user's local setting of
`$wgResourceLoaderDebug` would be used despite it all.
Change-Id: I3e7dec762c8a02683fc66a630c950b72a4840a9b
Tests should not interfere with each other; disabled deprecation
warnings should be disabled for a single test case only.
Bug: T191960
Change-Id: Ic9b892bc83ba6d71c1077df0d93c95dde36988bb
