PageImages is expensively loading and reparsing the lead section during
LinksUpdate because the parser's image link hooks do not give enough
context to tell whether the image is in the lead section.
So, add a hook which allows PageImages to add a marker to image links.
The marker can be associated with the section number in ParserAfterTidy.
Bug: T296895
Bug: T176520
Change-Id: I24528381e8d24ca8d138bceadb9397c83fd31356
Add a collation that gets its data from a remote Shellbox instance. This
is meant as a migration helper to use during an ICU upgrade.
Add a batch method to Collation so that this can be somewhat efficient
when adding multiple categories.
Bug: T263437
Change-Id: I76610d251fb55df90c78acb9f59fd81421f876dd
== Background ==
The `user.options` module is private, and thus has to be embedded in
the page HTML. This data is quite large. For example, on enwiki the
finalized mw.user.options object is about 3KB serialized/compressed
(7KB uncompressed).
The `user.defaults` module is an implementation detail of
`user.options`, and was created to accomplish mainly two things:
* Save significant data transfers by allowing it to be cached
client-side without being part of the article.
* Ensure consistency between articles and allow faster deployment of
changes, by not being part of the cacheable article HTML.
All our pageviews already load `user.defaults`, as a dependency of
the popular `mediawiki.api` and `mediawiki.user` modules. These are
used by `mediawiki.page.ready` (queued on all pages), and on Wikipedia
these are also loaded on all pages by ULS, VisualEditor, EventLogging,
and more.
As such, in practice, bundling "user.defaults" with "mediawiki.base"
will not cause the data to be loaded more often than before.
== What ==
* Add virtual "user.json" package file with the same data that
was previously exported by ResourceLoaderUserDefaultsModule,
and pass it to mw.user.options.set() from base module's entry point.
An alternative way would be to use a "user.js" file, which would
return a generated "mw.user.options.set()" expression. I went
for exporting it as JSON for improved maintainability (reducing
the amount of JS code written in PHP), and because it performs
slightly better. The JS file would implicitly come with a file
closure (tiny bit more bytes), and would then be lazy executed
(tiny bit more time).
The chosen approach allows the browser to compile the JSON
off-the-main-thread ahead of time while the module response downloads.
Then when the module executes, we can reference the JSON object
and use it directly.
* Update internal dependency from `user.options`.
* Remove `user.defaults` module without deprecation. It is an internal
module with no direct use anywhere in Git (Codeseach), and no use
anywhere on-wiki (Global Search).
Change-Id: Id3916f94f75078808951863dea2b3a9c71b0e30c
Otherwise they are using the 'delete' and 'protect' message key,
which are already defined.
Follow-Up: Idf076573c0f429171221660145b616ec83516a2a
Bug: T295611
Change-Id: I797f0e23ca639dac6889f3f363b7a8c72e30f681
Adding Special:Delete and Special:Protect as redirects to the delete and
protect action.
Bug: T295611
Change-Id: Idf076573c0f429171221660145b616ec83516a2a
Since 1.34 setting non-default HTTP engine
has been deprecated. It's time to remove
the old implementations. Only Guzzle is
now available.
Change-Id: I978b75827e69db02cbc027fe0b89a028adfc6820
This is a uniform mechanism to access a number of bespoke boolean
flags in ParserOutput. It allows extensibility in core (by adding new
field names to ParserOutputFlags) without exposing new getter/setter
methods to Parsoid. It replaces the ParserOutput::{get,set}Flag()
interface which (a) doesn't allow access to certain flags, and (b) is
typically called with a string rather than a constant, and (c) has a
very generic name. (Note that Parser::setOutputFlag() already called
these "output flags".)
In the future we might unify the representation so that we store
everything in $mFlags and don't have explicit properties in
ParserOutput, but those representation details should be invisible to
the clients of this API. (We might also use a proper enumeration
for ParserOutputFlags, when PHP supports this.)
There is some overlap with ParserOutput::{get,set}ExtensionData(), but
I've left those methods as-is because (a) they allow for non-boolean
data, unlike the *Flag() methods, and (b) it seems worthwhile to
distingush properties set by extensions from properties used by core.
Code search:
https://codesearch.wmcloud.org/search/?q=%5BOo%5Dut%28put%29%3F%28%5C%28%5C%29%29%3F-%3E%28g%7Cs%29etFlag%5C%28&i=nope&files=&excludeFiles=&repos=
Bug: T292868
Change-Id: I39bc58d207836df6f328c54be9e3330719cebbeb
This hook allows extensions to add additional pages to the list of
pages being exported. For example, if an extension creates supplemental
pages that must be exported along with a content page, this hook will
allow the extension to export the supplemental pages automatically when
the content page is exported.
Bug: T292378
Change-Id: I3b6b466b6ed32b1939674872df9e431bd6941645
With this patch deprecation warnings will be emitted
if $wgUser is accessed or written into. The only pattern
of usage still allowed is
$oldUser = $wgUser;
$wgUser = $newUser;
// Do something
$wgUser = $oldUser;
Once there is no deprecation warnings, we know that nothing
legitimately depends on $wgUser being set, so we can safely
remove the code that's still allowed as well.
Bug: T267861
Change-Id: Ia1c42b3a32acd0e2bb9b0e93f1dc3c82640dcb22
This reverts commit 0d453d915a.
Reason for revert: Trying to find a better approach than an abstract class
Change-Id: I69c0ec25cb920f41cb0eb6b3ad921d7b02290581
Removes deprecated API endpoints and modules for dealing with
CSRF tokens.
Note: i18n messages are removed in a followup for ease of revert.
Bug: T280806
Depends-On: Ic83f44587db119ff2e3e6d5ff33a10894e0695e7
Change-Id: I58aedec6942ac5d3c21574cb0072f00ef365098c
AbstractLocalizedException acts like a shim to ILocalizedException in preperation for refactoring
Bug: T287405
Change-Id: I01e40e82457d49487829d9a435b7a1198369ecf6
Merge the PPD* classes that were used by the DOM preprocessor with the
hash preprocessor classes that extend them. This resolves many issues
with types/phpcs and it removes unused code left over from the DOM
preprocessor.
Bug: T278069
Bug: T204945
Change-Id: I4b160b4610e5c7ba47e9e31db252cc00d2e345df
This patch injects services into WikiExporter. It also adds a
WikiExporterFactory service for creating WikiExporter instances.
Change-Id: Ib1547defea54c309865c116bc83d617c21568843
Use ObjectFactory specs for collation classes
Avoid the language construction in the factory class,
make it a detail of the implementation of each class
Follow-Up of Ifc96f851e6091ce834dbaf0e91695c648a42169c
Bug: T286079
Change-Id: Ib581f64aec8619986fb8dd49ceee0524d59a1b84
This change is for consistency to the file name and to other classes.
The old class name RandomPage is kept as alias for compatibility and is
now deprecated.
Also change the letter case in the class names and file names:
* SpecialRandompage -> SpecialRandomPage
* SpecialRandomredirect -> SpecialRandomRedirect
* SpecialRandomrootpage -> SpecialRandomRootPage
The change of the letter case of file names may cause problems on
Windows operating systems.
Change-Id: If4dd23126e0d032f42a86aff7d09414edcb1ade2
* Move data files to /data
* Add benchmarkCommentFormatter, named for the new class hierarchy.
Bug: T285917
Change-Id: Idf2529894fe63d34087d6d5ce4dd1676c89b1373
* eval() outside the loop so that we're not benchmarking the compiler.
* Inner loop for better testing of short-running code.
* Three ways to specify the code to run.
Change-Id: I5906bcaa8ed2cca9d66a6195d25b0007e476ba75
These are mainly testing PHP rather MW code, so there isn't so much
to iterate or learn from these periodically.
As a general data point for what to pick one would presumably write a
micro bench from scratch for any of the thousands of possible things
one could think of varations for in the space of built-ins and such.
As a general benchmark for changing server or PHP configuration,
these would not be represenative either way, we'd likely use full
HTTP requests or something like the higher-level Parse and Tidy
benchmarks.
Change-Id: I4e98ae394a49c1f4a247b8d1e79a2ae5f7022d05
* Turn normalize data into an autoloadable class and use the class name
as key instead of a partial file name with a base directory.
* This protected function is not aimed at re-use in extensions,
has no other usage known to Codesearch. Mark it internal,
and remove the compat introduced by 31283f34bf.
* Update the now ten-year-old documentation comments that described
this as "Temporary". The functionality and comment were introduced
in 2010 by Tim with r60599 (ad19c032b0).
Ref <https://bash.toolforge.org/search?p=0&q=temporary>.
* Replace the broken wikitech-l archive link with a working one,
and describe the thread for easier future reference.
Bug: T225756
Change-Id: I004da1f25c19e1095d0917349f2ba8461f9f0715
Deprecated in 1.35, removed in 1.37
Existing skins using the hook will not necessarily
break as many of the skins run their own version of the hook.
Extensions using the hook will no longer output links
to the toolbox in the sidebar.
Bug: T256511
Change-Id: I1ba018ced266ac27f3e038ba9102ab54a669df81
Depending on which namespace we want these classes to have after
T166010 they could either stay in includes/languages/ (plural) in
their own MediaWiki\Languages\-namespace dedicated to Language
subclasses, or they could go in into a subdirectory like
`includes/language/languages/` if we want to keep them in the same
top-level namespace as other Language classes and services, but in
a more nested namespace.
For now, I've made the smaller change and kept the Language subclasses
in their own directory directly under includes/, not nested further.
Bug: T225756
Change-Id: I01015424707b442853879fd50c97f00215e5c2fa
Cleanup after the switch of Database::query() to return ResultWrapper
instead of resource.
* Soft-deprecate the IResultWrapper accessors in IDatabase.
* Move relevant DBMS-specific functionality to ResultWrapper subclasses.
The deprecated methods in IResultWrapper become short and simple.
ResultWrapper is now abstract (b/c break).
* Move the implementation of fieldName(), numFields() and one of the
fieldInfo() implementations to the ResultWrapper subclass in order to
avoid ResultWrapper::unwrap() calls.
* Make Database::doQuery() return a ResultWrapper subclass instead of
underlying result data, so that the Database parent class does not
need to be aware of wrapper construction.
* Hard-deprecate ResultWrapper::unwrap(),
DatabaseMysqlBase::fieldType(), DatabasePostgres::fieldType().
* Fix the inefficient seeking method in SQLite.
* Make FakeResultWrapper extend ResultWrapper with an implementation
similar to the SQLite one. This is possible because ResultWrapper does
not depend on IDatabase anymore.
* Resolve fixme in DatabasePostgres: from studying the source,
neither pg_fetch_object() nor pg_num_rows() can set an error
retrievable with pg_last_error(). Removed unnecessary warning
suppression.
* ResultWrapperTest didn't make sense as a unit test anymore, so I
adapted it as an integration test against the current DBMS.
This change also means that ResultWrapper::key() always gives the
correct offset, even if Iterator methods are not being used.
Bug: T286694
Change-Id: I935835316c0bd7d3d061bd8fde9c9ce99ce756ec
Introduce a new schema migration stage in which rev_actor is used
directly and the revision_actor_temp table is no longer needed. This
becomes the new "new" stage whereas the previous situation is now
termed SCHEMA_COMPAT_TEMP.
Introduce migrateRevisionActorTemp which copies data from
revision_actor_temp to rev_actor. The code is similar to
migrateImageCommentTemp.php except that it doesn't delete from the old
table.
Partial revert of c29909e59f. That change removed direct
references to $wgActorTableSchemaMigrationStage and made queries
involving revision_actor_temp be unconditional. Such changes need to be
reverted to make the use of revision_actor_temp be conditional again.
In ActorMigrationTest, I compacted provideGetJoin() and
provideGetWhere(), removing most of the duplication between expected
values. I gave all the stages a short name, and mostly used the name in
providers.
Bug: T275246
Change-Id: I7498107dd6433ab7de5bf2e7b3fe2aa5e10e345d
