Now, instead of "if your changed paragraphs are larger than 10Kb, you're
screwed":
* Instead of relying on overall length, estimate complexity after splitting to words
and taking any equal head and tail out of equation.
* Estimate based on words changed, which better reflects the actual complexity
of generating a diff.
* New limit is determined scientifically, i.e. "above that number XDebug starts
complaining about recursion limits reached in Vagrant".
Caveat: if new limits are hit, the consequences are more widespread as all adjacent
changed paragraphs are displayed without word level diffs, as opposed to only the
paragraph that's too long being affected. However, the new limit is much higher and
in wikitext you're supposed to put empty lines between paragraphs anyway, negating
this problem.
Bug: T128697
Change-Id: I4e91c7c40f5afdd116b847a859b8517522302489
This patch introduces a way for SearchEngine implementations to expose
specific search profiles useful to fine-tune the various behaviors related to
search.
A SearchEngine can expose a list of profiles by overriding
SearchEngine::getProfiles( $profileType ), profileType stands for the type of
profile being customized. Two types are added in this patch:
- completion: exposed by ApiQueryPrefixSearch and ApiOpenSearch to control
the behavior of the algorithm behind "search as you type" suggestions.
- fulltext query independent profiles: exposed by ApiQuerySearch to customize
query indpendent ranking profiles (e.g. boost by templates/incoming
links/popularity/...)
This patch allows api consumers that might have been confused by fuzzy
suggestions to switch to stricter profiles and to officialize the behavior
behind the hidden param cirrusUseCompletionSuggester. Or to control the
fulltext ranking behaviors like cirrusBoostLinks=(yes|no).
The list of profiles can be discovered by using ApiSandbox/ApiHelp and is totally
controlled by search engine implementations.
Bug: T132477
Change-Id: I66be724d8975976c98c91badbf421f237e014f89
This is with T92459 in mind to simplify the process of splitting
the 'user' module for the styles-only queue.
Consequences:
* Cached HTML isn't relevant in practice since there is no caching for logged-in
users and this module is only for logged-in users. Even then, cached HTML will
work and may happen as browsers re-use HTML responses when revisiting a
privately cached page (after 304 Not Modified).
Note that OutputPage (via isKnownEmpty) only actually tries to load 'user.groups'
if the wiki has 'MediaWiki:Group-*.{js,css}' pages for the current user's groups.
- Old style queue request will continue to ask for user.groups which is now a
FileModule with no styles (simply concats the empty string to the bundle)
- Old load() request will resolve with an empty function.
* The are no known dependants of 'user.groups'. If there are, they will work
by proxy of it now being an empty module that just ensures 'user' is loaded.
* The security origin of 'user.groups' was USER_SITEWIDE. The origin of 'user'
is lower (USER_INDIVIDUAL). Pages that are restricted to USER_SITEWIDE
previously received user.groups, but won't anymore. This should be fine as
OutputPage::reduceAllowedModules() is mainly used to either allow everything
or restrict all the way down to CORE. The only exception is disallowUserJs()
if $wgAllowSiteCSSOnRestrictedPages is enabled (T73621) but that edge case was
made for Common.css, not Group-*.css.
Change-Id: I74cd2368ebd2989c5e1c22bea491a80beb0319dc
This is a rewrite of Linker::link() to a non-static, LinkTarget-based
interface. Users of plain Linker::link() with no options can use the
LinkRenderer instance provided by MediaWikiServices. Others that
have specific options should create and configure their own instance,
which can be used to create as many links as necessary.
The main entrypoints for making links are:
* ->makeLink( $target, $text, $attribs, $query );
* ->makeKnownLink( $target, $text, $attribs, $query );
* ->makeBrokenLink( $target, $text, $attribs, $query );
The order of the parameters are the same as Linker::link(), except
$options are now part of the LinkRenderer instance, and
known/broken status requires calling the function explicitly.
Additionally, instead of passing in raw $html for the link text, the
$text parameter will automatically be escaped unless it is specially
marked as safe HTML using the MediaWiki\Linker\HtmlArmor class.
The LinkBegin and LinkEnd hooks are now deprecated, but still function
for backwards-compatability. Clients should migrate to the nearly-
equivalent LinkRendererBegin and LinkRendererEnd hooks.
The main differences between the hooks are:
* Passing HtmlPageLinkRenderer object instead of deprecated DummyLinker
* Using LinkTarget instead of Title
* Begin hook can no longer change known/broken status of link. Use the
TitleIsAlwaysKnown hook for that.
* $options are no longer passed, they can be read (but shouldn't be
modified!) from the LinkRenderer object.
Bug: T469
Change-Id: I057cc86ae6404a080aa3c8e0e956ecbb10a897d5
Ideally this would be an option in ErrorPageError (perhaps even the default),
but its constructor isn't very suitable for that.
After this lands, uses of ErrorPageError should be audited to see if it makes
sense to emit a 400 status code.
Change-Id: I4beb6a4f256446b98b66d5e4bcdbab8f247441a8
NOTE: This also changes the semantics of MediaWikiServices::resetGlobalInstance
to only reset services instances, not service wiring. The wiring will be copied
from the old global MediaWikiServices instance to the new one.
Bug: T132707
Change-Id: Ie2ca3ff99aa74fffa9eb6c8faccab857dc0874f7
This keeps the existing app logic for looking up interwiki information
intact in ClassicInterwikiLookup. The idea is to seamlessly switch to a new
implementation when it becomes available, while also allowing us to
switch back in case of problems.
Change-Id: I7d7424345d0ce3ce90ba284006ee9615e3d99baa
This fixes three issues with the installer:
1) Make sure LocalizationCache can find the installer's i18n files.
2) Make sure we don't try to use an SqlBagOStuff for caching before we have
a functioning database.
3) Don't try to output HTML when redirecting (this is unrelated to
MediaWikiServices, but came up during testing)
Bug: T135169
Change-Id: I7caa932024cd771d6fa226a3ac6001c3148ecc9c
This aims to solve all the problems and fulfill all the use cases.
It allows the dialog to be configured for Wikimedia Commons without
hardcoding anything, and it should be flexible enough for third-party
use. The default configuration should be sane for any wiki.
The file upload dialog can be configured using $wgUploadDialog.
See DefaultSettings.php for documentation. Example configuration for
Wikimedia Commons: Id56370e2334c8fe34e88180356232b48c244b7c4.
Configuration is loaded using ResourceLoaderUploadDialogModule for
local uploads or using ApiQuerySiteinfo (action=query&meta=siteinfo)
for uploads to a foreign wiki. Custom localisation messages may be
loaded using action=query&meta=allmessages.
Renamed messages:
upload-form-label-own-work-message-local -> upload-form-label-own-work-message-generic-local
upload-form-label-not-own-work-message-local -> upload-form-label-not-own-work-message-generic-local
upload-form-label-not-own-work-local-local -> upload-form-label-not-own-work-local-generic-local
upload-form-label-own-work-message-default -> upload-form-label-own-work-message-generic-foreign
upload-form-label-not-own-work-message-default -> upload-form-label-not-own-work-message-generic-foreign
upload-form-label-not-own-work-local-default -> upload-form-label-not-own-work-local-generic-foreign
Deleted messages, moved to WikimediaMessages in Id2977e19330aeaf854157d4355cd17e5dc72f16a:
upload-form-label-own-work-message-shared
upload-form-label-not-own-work-message-shared
upload-form-label-not-own-work-local-shared
Bug: T118097
Bug: T120998
Bug: T121632
Bug: T121633
Bug: T127895
Change-Id: I3017b8f09c27625deb7a92d6f667895b71cc0637
Changes here are:
* action=login is deprecated for use other than bot passwords
* list=users will indicate if a missing user name is creatable.
* Added action=query&meta=authmanagerinfo
* Added action=clientlogin is to be used to log into the main account
* action=createaccount is changed in a non-BC manner
* Added action=linkaccount
* Added action=unlinkaccount
* Added action=changeauthenticationdata
* Added action=removeauthenticationdata
* Added action=resetpassword
Bug: T110276
Bug: T110747
Bug: T110751
Bug: T32788
Bug: T67857
Bug: T28597
Bug: T76103
Change-Id: I244fa9b1e0623247d6d9fa30990411c6df94a496
Rewrite authentication-related special pages to use AuthManager.
All the changes mentioned below only take effect when
$wgDisableAuthManager is false.
LoginForm is rewritten to use HTMLForm and split into UserLogin
and CreateAccount; ChangePassword and PasswordReset are rewritten;
ChangeEmail and Preferences are updated. Four new special pages
are added to handle the new capabilities of AuthManager (linked
accounts, secondary authentication providers): LinkAccounts,
UnlinkAccounts, ChangeCredentials, RemoveCredentials.
The old form-based hooks (ChangePasswordForm, UserCreateForm,
UserLoginForm) are deprecated. A new, more generic hook is
available to alter the forms (AuthChangeFormFields);
form changes that involve new fields should be done via
$wgAuthManagerConfig.
UserLoginComplete is limited to web-based login; for more
generic functionality UserLoggedIn can be used instead.
Hooks that assume password-based login (PrefsPasswordAudit,
AbortChangePassword) are removed; the first functionality
is replaced by ChangeAuthenticationDataAudit, the second is
handled by AuthManager. LoginPasswordResetMessage is removed,
the functionality can be recreated via authentication providers.
There are several smaller backwards incompatible changes:
* Adding fields to the login/signup forms by manipulating the
template via the extraInput/extrafields parameters is not
supported anymore. Depending on the authn configuration the
login/signup process might be multistep and it would be
complicated to ensure that extensions can access the data
at the right moment. Instead, you can create an
AuthenticationProvider which can define its own fields and
process them when the authentication is over.
(There is B/C support for a transitional period that works with
the default login form, but might break with configurations that
require multiple steps or redirects.)
* Removed cookie redirect check. This was added in 2003 in 9ead07fe9
for the benefit of bots, but with MediaWiki having an API these days
there is little reason to keep it. Same for the wpSkipCookieCheck
flag (added in 2008 in 29c73e8265).
* Instead of embedding a password field on sensitive special pages
such as ChangeEmail, such pages rely on AuthManager for elevated
security (which typically involves requiring the user to log in again
unless their last login was more than a few minutes ago).
Accordingly, wgRequirePasswordforEmailChange is removed.
* Special:ChangePassword requires login now.
* Special:ResetPassword now sends a separate email to each user when called
with a shared email address.
* the Reason field had a message with 'prefsectiontip' class
which was sorta broken but used in extensions for formatting.
HTMLForm does not support that, so this commit turns it into a help message
which will break formatting. See https://gerrit.wikimedia.org/r/#/c/231884
Bug: T110277
Change-Id: I8b52ec8ddf494f23941807638f149f15b5e46b0c
Depends-On: If4e0dfb6ee6674f0dace80a01850e2d0cbbdb47a
This implements the AuthManager class and its needed interfaces and
subclasses, and integrates them into the backend portion of MediaWiki.
Integration with frontend portions of MediaWiki (e.g. ApiLogin,
Special:Login) is left for a followup.
Bug: T91699
Bug: T71589
Bug: T111299
Co-Authored-By: Gergő Tisza <gtisza@wikimedia.org>
Change-Id: If89d24838e326fe25fe867d02181eebcfbb0e196
The motivation for this patch came from trying to use xhprof to profile the
unit tests. I was able to profile specific test suites, but if I tried to
profile a complete PHPUnit run, I ended up with empty profiling data. My
initial suspicion was that this was due to some Xhprof buffer getting
exhausted. The actual reason ended up being much simpler: the XhprofTest suite
indirectly called xhprof_enable() / xhprof_disable(), which stopped xhprof and
cleared out the data, so that when I was calling xhprof_disable() at the end of
the run, there was no profiling data to return, because xhprof was not running.
For the most part the XhprofTest was already doing the right thing by trying to
avoid having side-effects or relying on xhprof. Wherever possible, test fixture
profiling data was used in lieu of actually running xhprof. But this was not
totally successful because the Xhprof class coupled the collection of data to
the processing of data. Xhprof::__construct() called xhprof_enable(), so there
was no real way around that.
I think that the right way to fix that is to decouple profiling from profiling
data analysis. Thus I renamed 'Xhprof' to 'XhprofData', and modified the class
so that it expects to be fed profiling data rather than going out and
collecting it on its own. As a result, it is now possible to profile a full
phpunit run with xhprof, and the work that went into writing fixtures for the
Xhprof unit tests pays off: the class and the tests no longer have a hard
dependency on the xhprof extension, and the tests do not have to be skipped
when it is not installed. And the tests are really testing the system under
test, rather than the xhprof extension.
Finally, I added a new Xhprof class, which really is just an extremely thin
wrapper around xhprof_enable() / xhprof_disable(). The only extra functionality
it provides is the ability to check whether xhprof is running, via
Xhprof::isEnabled(). Calling Xhprof::enable() when it is already enabled will
cause an exception to be thrown. This should help us avoid running into
situations where two components contend for control of the profiler without
realizing it. A unit test tests this behavior.
The only part of this change that is not covered by tests is the change to
ProfilerXhprof. I tested it manually and it works.
Change-Id: Ica96beded68f04083abaf48ef1ae8c726eb60fa6
It's independent of the rest of the Parser, but quite intrusive, with
its own instance variables and several private functions. It's also
pretty big (500 lines).
I removed a few functions from Parser here which were always marked
@private in the doc comment, but were inappropriately marked
"public" in the function declaration after migration to PHP 5. I grepped
core and deployed extensions and found no callers.
The helper functions are now all private, and the constructor is
private, with just a single public static entry point, reflecting
the self-contained nature of the module and its lack of hooks.
Change-Id: I1693ed48a9194719611b4afd9d989d44f0610f8d
(This is part of I6ec374ac9 wich was a re-submit of Ie98bf5af5
which got reverted by Ide7ab563)
This change provides a mechanism to reset global service instances
in an orderly manner. There are three use cases for this:
* the installation process
* integration tests (which most of the existing phpunit tests are)
In contrast to I6ec374ac9, this change does not cause singeltons
of legacy services to be reset. It is assumed that legacy services
use global state to access services and configuration, so any
change in confuguration would affect them immediately.
NOTE: the original I6ec374ac9 would cause session information to
get lost if the user session was creatsed before initialization
was complete. This was apparently triggered by the MobileFrontend
extension under some circumstances. Check with Addshore and Catrope.
Change-Id: Ie06782ffb96e675c0aa55dc26fb8f22037e8517d
This change provides a mechanism to reset global service instances
in an orderly manner. There are three use cases for this:
* the installation process
* forking processes
* integration tests (which must of the existing phpunit tests are)
Depends-On: I5d638ad415fc3840186a0beaa09ac02ea688539b
Change-Id: Ie98bf5af59208f186dba59a9e971c72ea0b63e69
* Removed fallback code from Language, the associated data file
(Utf8Case.ser), and the code to generate that data file.
* Removed comment in LanguageFi that "mb_substr has a compatibility
function in GlobalFunctions.php".
* Removed check for mbstring in bench_utf8_title_check.php.
* In the tests for StringUtils::isUtf8():
* Removed separate test for the non-mbstring code path.
* Removed mentions of mbstring from function names and assertion
messages, since mb_check_encoding() is now always used.
* Also updated the comment in StringUtils::isUtf8() referring to
PHP 5.3, which is no longer supported in MediaWiki, to indicate
that the same issue also exists in old versions of HHVM. (If
we don't have to support 3.4 or older, then the function could
be deprecated and removed if desired.)
Follows-up 943563062f.
Change-Id: I55e5cd534b849c6ea06a7fadacbbf34a12d87ebe
In the age when we require PHP 5.5, pretending that mbstring emulation
is not slow and silly is silly.
Bug: T129435
Change-Id: Ic8235c9da9a926df63ec7388900c44eab454eebe
The AutoloadGenerator class is instantiated in the script
maintenance/generateLocalAutoload.php and its equivalents in
several extensions, none of which use MediaWiki's AutoLoader,
so you get a "Fatal error: Class 'ClassCollector' not found".
This reverts commit a379bebd03.
Change-Id: Ia6a7a1cb8a593ac86ecffdb690064e0b8ad68b47
