Part of program to remove underscores from class names. Checked core and 675
extensions for occurrences. All uses are in core in core are updated in this
patch. There are no uses in Gerrit extensions.
Change-Id: Id3ff16710a11ce1909a83b58505b250736a073e8
* Merged the "collate at end" and "running collate" logic
into the base class to make it more unified and consistent.
* Pulled out DB code into ProfilerSimpleDB class.
* Removed the ProfilerSimple class and updated child classes.
* Made ProfilerSimpleTrace set the debug information too.
* Work around "ended by close()" bug from 99aef03f. Since the
getRawData() method gets called while some wfProfileOut() calls
have not yet happened, make it use the matched call data and let
the final logData() method work on the full data as normal.
* Let ProfilerSimple classes use getFunctionReport() for the profiler
debug log if it is setup instead of making it just return "".
* Made getRawData() work as best as possible with ProfilerMwprof.
* Removed $wgProfileToDatabase since it is now useless.
* Improved DB profile performance with sqlite.
* Updated visibility of various methods.
Change-Id: I1260bab2b5ba12dccbba701bcae4a637cb85c6e8
It's pretty much like action=opensearch but can be used as a generator
which can be handy when you need to retrieve both the list of pages and
some information about them.
Change-Id: Iaffe30a0f7402e1316c4885a805692a34bbe1a6a
Special page to implement list of Tracking Categories. Global
$wgTrackingCategories added containing list of tracking categories
Bug: 60333
Change-Id: I7d4bb90622a6bae60845942ef93cfe64f229d2d2
TitleValue is intended to be a light weight alternative to the Title
class. Any operations on TitleValue are implemented in separate
service classes, like TitleFormatter and PageLinkRenderer. See
<https://www.mediawiki.org/wiki/Requests_for_comment/TitleValue>
for more information.
This change updates SpecialCategories and SpecialLinkSearch to use
TitleValue instead of Title, to demonstrate how TitleValue would be
used, and how the necessary services can be injected and applied.
The intention is to improve testability and reusability; these
advantages will however only become apparent with further refactoring
of the respective special pages. This will be done in follow-up
changes.
More work will be needed to migrate essential functionality from
Title and Linker classes into the respective service classes,
MediaWikiTitleCodec and MediaWikiPageLinkRenderer.
Change-Id: I8eef5a165de4ffcacfbc4911fdacdb15d502fff4
I saw some comments recently on commons suggesting that
better ways are needed to manage duplicate files (There are tools
for if a specific file is a duplicate, but no backlog of
outstanding duplicate files).
This seems like a fairly easy first step in that direction.
Wasn't sure if this should be an image gallery type
query page, or just a list. I think in this case a plain
list is more useful.
Change-Id: Ibe4b9da71ca6451ec4e6b0050feaf3ca70e1b888
Per existing FIXME comment: "This is not very polite. Assume we
do not manage the class."
Reverts the remaining portion of r44296 / 2f584f68a9 while
clarifying the "Give up" comment.
Change-Id: I4471f9376cae6b3c3e8df99e960770863ebf37ca
* Moved ApiRunJobs to a special page instead of going through
ApiMain and having to fight the logic there. As a separate
internal API, this does not show up on the API help page and
is no longer effected by $wgEnableAPI.
bug: 62233
Change-Id: I1db6f526d02e130a66ee03289858a734d89e6c00
I should have done it at the beginning instead of trying to
extract it from recent changes.
Same for SpecialRecentChanges and SpecialRecentChangesLinked
(subclasses).
Created a new API module for it: ApiFeedRecentChanges.
It's somewhat un-API-like and hackish, but all feed modules are.
Old URLs redirect to new ones, so this should be fully
backwards-compatible assuming sane feed reader clients.
Change-Id: I06ee0f01d896bc66545a1800b24693ce7524e433
This makes it more feasible for Wikibase, Flow, etc. to support
enhanced changes format, and allow better support for the rc_source
column in the future.
Change-Id: I873f6b86007000a94337f0c963df4bf8fec5b715
DBUnexpectedErrors are now treated like most other exceptions; we now
hide the error messages (which could contain sensitive information
such as IP addresses) unless $wgShowExceptionDetails is true.
In that case, the messages (and redacted backtraces) would be shown
even if $wgShowDBErrorBacktrace is false, though hiding them would
add complexity to the exception handler for little benefit.
Bug: 26811
Change-Id: I063c241975ce5b12a04abc21821ac67c716b3d5e
they support via Composer.
This change allows extensions to specify they depend on a specific
version or version range of MediaWiki. This is done by adding the
package mediawiki/mediawiki in their composer.json require section.
As MediaWiki itself is not a Composer package and is quite far away
from becoming one, a workaround was needed, which is provided by
this commit.
It works as follows. When "composer install" or "composer update"
is run, a Composer hook is invoked. This hook programmatically
indicates the root package provides MediaWiki, as it indeed does
when extensions are installed into MediaWiki. The package link
of type "provides" includes the MediaWiki version, which is read
from DefaultSettings.php.
This functionality has been tested and confirmed to work. One needs
a recent Composer version for it to have an effect. The upcoming
Composer alpha8 release will suffice. See
https://github.com/composer/composer/issues/2520
Tests are included. Composer independent tests will run always,
while the Composer specific ones are skipped when Composer is
not installed.
People that already have a composer.json file in their MediaWiki
root directory will need to make the same additions there as this
commit makes to composer-json.example. If this is not done, the
new behaviour will not work for them (though no existing behaviour
will break). The change to the json file has been made in such a
way to minimize the likelihood that any future modifications there
will be needed.
Thanks go to @beausimensen (Sculpin) and @seldaek (Composer) for
their support.
Change-Id: I8df66a92971146ab79cd4fcbd181e559115ca240
* A background internal HTTP request used to load the API.
This handles job execution and related periodic tasks.
It avoids blocking the main request or breaking it on fatals.
* This method avoids problems that shelling could have:
** Mismatched apache/cli PHP config or versions.
** Had to start a new process and could not use opcode cache.
** safe_mode and open_basedir restrictions required a fallback.
** Some wiki farms may not respect the --wiki parameter.
** wgMaxShellMemory applies to spawned PHP processes.
** Spawning processes is more prone to DOS due to a lack
of proper limiting/pooling.
bug: 60208
bug: 60210
bug: 60698
bug: 60844
Change-Id: I78b0e709301ac4a0c7b7ed337d6969d7546674bf
So that they are easier to separate from the main debug log.
The two news are:
- 'autoloader' for messages sent by the AutoLoader class
- 'caches' for the list of cache types
Change-Id: Ifb6dc2666fec2323219bbfac94ab53a422e5312a
While redirects can be sort-of queried using list=backlinks with
blfilterredir=redirects, we can get more accurate results with a module
dedicated to this purpose. We can also get the fragment of the redirect
without having to load the content of the redirect page and parse it.
I'm a bit surprised I was able to put together a query for this that
will work as a prop module. Or did I overlook something?
And then we may as well add the corresponding list=allredirects, to work
like alllinks, allfileusages, and alltransclusions.
Bug: 57057
Change-Id: I81082aa9e4e3a3b2c66cc4f9970a97eed83a6a4f
Add action=revisiondelete to the API, and some functions to the
revisiondelete backend to support this.
Bug: 23005
Change-Id: Iee146fed648603b86a35927518f850771fc69bd2
Allows configuration options to be fetched from context.
Only one implementation, GlobalConfig, is provided, which
simply returns $GLOBALS[$name]. There can be more classes
in the future, possibly a database-based one. For convinience
the "wg" prefix is automatically added.
Ironically, this adds the $wgConfigClass global variable
which is used to determine which implementation of Config
to use by default.
The ContextSource getConfig and setConfig methods were introduced
in I23194d1ba (1.23), but have no uses in Gerrit, so they can safely
be re-purposed.
Change-Id: I13baec0b6d4ea7badf20b9c5f9b40846348838e4
This is similar to Special:PermanentLink added in r79036 and has been
asked for several times in different places, including:
- on the English Wikipedia (oldid=539308532)
- on mediawiki.org (lqt_oldid=31691)
- on the French Wikipedia (oldid=93029892)
- on the English Wikipedia again (oldid=588408888)
A notable use-case is linking to diffs in the edit summaries, where
external links are not yet allowed (bug 14892).
All of the following are valid usages:
- [[Special:Diff/12345]] (diff of a revision with the previous one)
- [[Special:Diff/12345/prev]] (diff of a revision with the previous one as well)
- [[Special:Diff/12345/next]] (diff of a revision with the next one)
- [[Special:Diff/12345/cur]] (diff of a revision with the latest one of that page)
- [[Special:Diff/12345/98765]] (diff between arbitrary two revisions)
Co-authored-by: Jérémie Roquet <jroquet@arkanosis.net>
Co-authored-by: Bartosz Dziewoński <matma.rex@gmail.com>
Change-Id: I77fdaf8e04375caa1d67ca4a3ec3bd93920c3309
* envCheckPHP531: Message is outdated ("downgrade to 5.3.0"; the
current minimum PHP version is 5.3.2), and PHP Bug #50394 has
not reappeared in any later version.
* envCheckZE1: zend.ze1_compatibility_mode was removed in 5.3.0.
Also updated the error message for envCheckBrokenXML to remove
the "Upgrade to PHP 5.2.9 or later" wording.
Change-Id: Ifc8754151dd23a0314c6739cb78c7ac61a306bc4
