The current API for Database::encodeBlob/Database::addQuotes requires
the code that is outputting binary data to have a database handle, so
that it may call Database::encodeBlob to get either a plain string or
a Blob object back. All database implementations other than MySQL
return a Blob object from Database::encodeBlob.
This is a rather inconvenient API, it tightly couples the creation of
binary data with the Database object unnecessarily. If all database
objects accept a Blob via Database::addQuotes then code can simply
wrap its arguments in Blob and know that any database it ends up at
will be properly handled.
This patch changes the default implementation of Database::addQuotes
to recognize a Blob object was passed in, and use Blob::fetch to turn
it back into a string. Database implementations other than MySQL all
handle this Blob object already. The postgresql implementation had
to be adjusted slightly. Now when it sees a Blob object that it did
not create it will encode that appropriately.
Bug: 72367
Change-Id: I12fb4bd339be19137fffba2e47a70741382f6a8c
MWLogger was renamed MWLoggerFactory and reduced to a static utility
class in Ie474676. Reintroduce an MWLogger that proxies the public
static methods of MWLoggerFactory to ease the transition of users who
have implemented $wgMWLoggerDefaultSpi configurations that reference
MWLogger.
As noted in the class, this is a temporary bandaid that should be ripped
off before 1.25 becomes an official release.
Change-Id: Iaccb78a510c60aab2ff20a9aa7c0869699657388
Time wounds all heels. During the code review for the PSR-3 logging
introduction, several people asked me why we needed a wrapper
for Psr\Log\LoggerInterface if the point was to use the standard. At the
time I was convinced that it would be better to introduce the dependency
via a wrapper class so that we could use the wrapper to patch over any
deficiencies that we might find in the PSR-3 API. After going on to work
on a project to disentangle other MediaWiki components from internal
project dependencies I have suddenly and clearly seen the error of my
ways.
We still need a logger factory as PSR-3 does not specify
a standard mechanism for creating Psr\Log\LoggerInterface instances. My
solution is to convert MWLogger into MWLoggerFactory to retain a static
factory interface for creating PSR-3 loggers but remove the MWLogger
wrapper class itself in favor of direct exposure of
Psr\Log\LoggerInterface to the MediaWiki consumer classes.
Change-Id: Ie47467657dcf341991ada00827dca5e8eff95438
* Also added a selectFieldValues helper method to the DB classes
since this use case keeps coming up.
Change-Id: I62cdbb497dc2c8fe4758e756d13688b85165e869
…and in general, work with the existing HTMLForm design for defining
display formats, rather than against it.
Breaking changes:
* HTMLForm::isVForm() is now deprecated.
* You can no longer do this:
$form = new HTMLForm( … );
$form->setDisplayFormat( 'vform' ); // throws exception
Instead, do this:
$form = HTMLForm::factory( 'vform', … );
When using FormSpecialPage, override the new getDisplayFormat() method
instead of calling $form->setDisplayFormat() in the alterForm() method.
(Other display formats are not affected, only 'vform'.)
Bug fixes:
* Correctly suppress empty labels for VForm fields
* Correctly disable <fieldset/> wrappers for VForms
Other benefits:
* Reduce code duplication related to $getFieldHtmlMethod
* Introduce HTMLForm::factory() method for constructing HTMLForms
Related cleanup:
* Correctly style 'reset' buttons in MediaWiki UI mode
* Label $wgHTMLFormAllowTableFormat as a mobile-specific hack
* Display checkboxes normally in MediaWiki UI mode (removed weird
override that only broke things). Also, always render checkboxes
in VForms as .mw-ui-checkbox.
* self:: → static::
Bug: T85285
Change-Id: I086a84f1c8cc6a16710709b7806c7f5f96462b32
Language::commaList() gets called even though in 99% of cases it's not
description that's needed but other parameter information, resulting in
0.6% of overall cluster CPU time being wasted per
https://performance.wikimedia.org/xenon/svgs/daily/2015-01-02.svgz
Change-Id: Ic77e4a03d1bbd1aa5f86dc250d9f903d7eb25618
Introduces wfLoadExtension()/wfLoadSkin() which should be used in
LocalSettings.php rather than require-ing a PHP entry point.
Extensions and skins would add "extension.json" or "skin.json" files
in their root, which contains all the information typically
present in PHP entry point files (classes to autoload, special pages,
API modules, etc.) A full schema can be found at
docs/extension.schema.json, and a script to validate these to the
schema is provided. An additional script is provided to convert
typical PHP entry point files into their JSON equivalents.
The basic flow of loading an extension goes like:
* Get the ExtensionRegistry singleton instance
* ExtensionRegistry takes a filename, reads the file or tries
to get the parsed JSON from APC if possible.
* The JSON is run through a Processor instance,
which registers things with the appropriate
global settings.
* The output of the processor is cached in APC if possible.
* The extension/skin is marked as loaded in the
ExtensionRegistry and a callback function is executed
if one was specified.
For ideal performance, a batch loading method is also provided:
* The absolute path name to the JSON file is queued
in the ExtensionRegistry instance.
* When loadFromQueue() is called, it constructs a hash
unique to the members of the current queue, and sees
if the queue has been cached in APC. If not, it processes
each file individually, and combines the result of each
Processor into one giant array, which is cached in APC.
* The giant array then sets various global settings,
defines constants, and calls callbacks.
To invalidate the cached processed info, by default the mtime
of each JSON file is checked. However that can be slow if you
have a large number of extensions, so you can set $wgExtensionInfoMTime
to the mtime of one file, and `touch` it whenever you update
your extensions.
Change-Id: I7074b65d07c5c7d4e3f1fb0755d74a0b07ed4596
So that code to deal with Parsoid can be shared across different extensions.
Relies on I1d57ff24
Bug: T1218
Change-Id: Id658d925b722b885fd425c27f7c4fd2cd02ad0b4
Checks whether your composer.lock file is up to date
with the current composer.json file.
Bug: T77388
Change-Id: I528d63172c238cf1ea9bc02e8eb39b93225865de
There are cases where the list of values for a 'prop' parameter may be
manipulated by a subclass or by a hook function of some sort. Rather
than requiring the subclass/hook to completely replace a monolithic i18n
message, let's add the possibility of separate messages for each value
in the list.
Bug: T77930
Change-Id: I0bb061c62ebeef125062460e26306c88390f7b31
Introduce the MWLoggerMonologSamplingHandler which can
be used to probabilistically sample the log event stream.
Bug: T85067
Change-Id: Icd14fc8c44ca9eef0f3f5cc4f1d1d8b68d517f07
Code moved from MWLoggerLegacyLogger::emit(), which was formerly
in wfErrorLog().
Bug: T74572
Bug: T78599
Change-Id: I9e0e63d41bed6ccb468f3a9f1d52f156acc355a8
Added a TransformTooBigImageAreaError to allow setting an extra message.
Added also size-*pixel messages to show the value of $wgMaxImageArea
with some formatting.
This error is still throwing for all files, to fix bug T34387 this needs
a follow up with a proper check. I am not sure, if a File::isLocal() is
okay, because files from a DBForeignRepo maybe transformed on the same
server, so the check needs to be done also for this. For APIForeignRepo
the check is done on the foreign server.
Change-Id: Ieba12e424c8bddb1961a30d3f9ea5c8ff241abb5
Up until now, the import backend has tried to resolve titles in the XML
data using the regular Title class. This is a disastrous idea, as local
namespace names often do not match foreign namespace titles.
There is enough metadata present in XML dumps generated by modern MW
versions for the target namespace ID and name to be reliably determined.
This metadata is contained in the <siteinfo> and <ns> tags, which
(unbelievably enough) was totally ignored by WikiImporter until now.
Fallbacks are provided for older XML dump versions which may be missing
some or all of this metadata.
The ForeignTitle class is introduced. This is intended specifically for
the resolution of titles on foreign wikis. In the future, an
InterwikiTitle class could be added, which would inherit ForeignTitle
and add members for the interwiki prefix and fragment.
Factory classes to generate ForeignTitle objects from string data, and
Title objects from ForeignTitle objects, are also added.
The 'AfterImportPage' hook has been modified so the second argument is a
ForeignTitle object instead of a Title (the documentation was wrong,
it was never a string). LiquidThreads, SMW and FacetedSearch all use this
hook but none of them use the $origTitle parameter.
Bug: T32723
Bug: T42192
Change-Id: Iaa58e1b9fd7287cdf999cef6a6f3bb63cd2a4778
ResourceLoaderImageModule needs a set of SVG files and some data in
the module definition, and produces styles for a set of CSS classes,
one for each image, optionally with differently colored variants,
generated in SVG and PNG, data-URI-embedded if possible, compatible
with all browsers, and generally slick.
The intended usage is to ship icon libraries with MediaWiki that can
be used throughout the pages with no additional code.
* ResourceLoaderImageModule implements all of the logic for data
parsing and CSS generation.
* ResourceLoaderImage implements the logic for SVG image colorization
(for variants) and rasterization.
* ResourceLoader and ResourceLoaderContext were extended to serve a
new kind of load.php request that delivers a single image file. This
is used for fallback PNG images served to browsers that don't
understand SVG.
See change Ic6a76bfb for a demo.
Bug: T76473
Co-Authored-By: Trevor Parscal <trevorparscal@gmail.com>
Co-Authored-By: Bartosz Dziewoński <matma.rex@gmail.com>
Change-Id: Idf6ff4eb8e94f45946f15d283d34108b881fae6e
We currently embed the full set of user options in a <script> tag in the HTML
output of every page. This is grossly inefficient, because the full set of
options is usually largely made up of site defaults which the user hasn't
customized.
So instead of doing that, let's emit the default options using one
ResourceLoader module and then apply the user's customizations on top.
This has the effect of slightly increasing the total bytes of JavaScript code
(because options that the user has customized will be emitted twice: once with
their default value in the user.defaults module, and then again with the
customized value in user.options). But this is more than offset by the
fact that the bulk of user options code (~4 kB uncompressed on enwiki) becomes
cacheable across requests.
Bonus round:
* Varnish gets to cache 4 kB fewer per page.
* Changes to the default options don't take 30 days to propagate.
Change-Id: I5a7e258d2d69159381bf5cc363227088b8fd6019
* This lets edits be prepared while users enter edit summaries.
* The edit form will now make use of this API, controlled by
$wgAjaxEditStash.
Change-Id: I4f4057bc0d1d4a66a8f7cfb7cdc26d443a8eb0c4
Provides file-based cache of the SitesStore data,
using a static json file dump of the data from the
SiteSQLStore.
Includes a maintenance script to rebuild the sites cache.
Bug: 56602
Bug: 45532
Change-Id: Iaee4c1f9fb5d54efe01975f733ebd5c339ac106f
Adds leafo/lessphp 0.5.0 as a dependency, and removes the current
copy of lessphp.
Depends on 7b2af65827 in mediawiki/vendor.
Bug: T1337
Change-Id: Ib5ab4c872d5236258df97d49f4ba72a20758a2e9
Having a log formatter for the Monolog stack that mimics the legacy wf*
logging function output will ease the transition for users wishing to
use Monolog who have tooling that expects the legacy log formats.
Bug: T845
Change-Id: I06295ccc4b068c61d7971024213366004b69c03d
The new cdb library is pulled in via composer. Since the
library uses namespaces, a backwards-compatability layer
is provided for the old class names:
* CdbReader
* CdbWriter
* CdbException
The PHP/DBA-specific classes should never have been used directly.
Depends on I98302bdf1 in mediawiki/vendor
Change-Id: I39549ac8540b262cf91f7d1830d36327afb3033d
* Added a standard getFunctionStats() method for Profilers to return
per function data as maps. This is not toolbar specific like getRawData().
* Cleaned up the interface of SectionProfiler::getFunctionStats() a bit.
* Removed unused cpu_sq, real_sq fields from profiler UDP output.
* Moved getTime/getInitialTime to ProfilerStandard.
Co-Authored-By: Aaron Schulz <aschulz@wikimedia.org>
Change-Id: I266ed82031a434465f64896eb327f3872fdf1db1
Adds a comment to the top of the generated autoload.php directing
developers to the command to regenerate the file so they may just
copy and paste the command.
Change-Id: If098a1eb51ed732378677215c0e438c73d506697
Both zend and HHVM run through the autoload file faster when it
is a single array literal rather than individual key assignments.
The __DIR__ string concatenation remains because HHVM and Zend >= 5.5.0
optimize away constant string concatenation.
Change-Id: I75403ace264b09930d5cc545e62b8d7c3f1ad064
Currently all new classes in core need to be registered
with the autoloader. This is acceptable but inconvenient.
This patch adds a script to read the output of php's tokenizer
to determine the names of all the classes within mediawiki core.
Patches with new or removed classes will just need to rerun
the maint script rather than manually adjusting the arrays.
A full conversion to psr-0 + composer would solve this as well,
but this is a very non-intrusive patch that can get us some
portion of the benefit(reduced manual maintenance) today rather
than months down the line once we figure out all the intricacies
of mediawiki + composer.
Change-Id: I8b1bdb84a9699de79f8b9951fa61e5437d083c55
