The variable is also read in a few other places, such as to
export the value from api.php (siteinfo) and load.php (mw.config)
but those requests don't need to be held back by this extra
logic.
Alternatively, if we really want to require this for all consumption,
we should probably let PathRouter provide the value and require
consumers to use it. E.g. services->getPathRouter->getArticlePath,
or something like that.
As easy first step, I'm moving it to PathRouter, called from
WebRequest::getPathInfo which is still called on all index.php
requests for any wiki page action in any namespace (incl Special)
when the wiki uses anything other than the default 'index.php?title='
article path.
Test Plan:
* Set '$wgArticlePath = 'bla';`
* View /mediawiki/index.php/Main_Page, and observe the fatal
error message (same as before this change).
Bug: T189966
Change-Id: Id06c2557e2addb58faeef0b6f7767a65b8de55a5
Phan can treat scalar types as non-interchangeable with
`scalar_implicit_cast` set to false. This patch fixes some of those
issues (which are in total >1000), namely the ones with alphabetic order
< includes/actions.
Change-Id: Ib1c6573ab899088bc319b9da9ceaffc850da3dbe
Move the default of 2000 to DefaultSettings.php, and promote
the installer warning to a hard value.
Recommend that the setting be disabled, or increased to 5000.
Change-Id: Ifb0aadf8b52fd2d5c2a32f55e38eaa9c2600dfb5
This is only relevant when processing page views or when constructing
Title urls with an 'action' query. Pretty important stuff, and worth
optimising for if we had to choose, but we can defer it in this case
without slowing it down, which is better for everything else.
It also means we don't mutate configuration (beyond setting whole values
as dynamic defaults), which seems desirable, and makes the overall behaviour
easier to test. Handling absence of 'view' should be PathRouter's
responsibility, not Setup.
Bug: T189966
Change-Id: I9c1eea2dcea74be0e283eb2b175268315ced1793
* Remove checks in HTMLFileCache.php and Article.php.
These haven't been needed since the same check was added to Setup.php,
many years ago. When FileCache is enabled, The Setup.php code disables
MWDebug. There is no reason for FileCache to then also disable itself
based on unused config. That means both of them lose.
We now handle this logic in one place: MWDebug::setup().
* In rebuildFileCache.php, turn it off explicitly, just in case.
The previous code there didn't work because finalSetup()
is called after doMaintenance.php includes Setup.php, which
is what checked this config var to decide on MWDebug::init.
On the other hand, it's also always off in CLI mode.
But, let's not depend on that, maybe we decide to enable it on
CLI one day! Just keep it off explicitly here.
Bug: T189966
Change-Id: I45a8f77092249751dc6f276aa5bb67ebf5b4f64c
Define the global constant MW_REST_API in rest.php, by analogy with
MW_API. Also generalize this by adding MW_ENTRY_POINT, which contains
the entry script name, "cli" or "unknown". This allows tests such as
if ( MW_ENTRY_POINT !== 'index' )
which is probably what is really intended by defined('MW_API') in many
cases.
Change-Id: I24099f4cdd170de17afd6e1bbad67c9b204071fc
This is currently forcing more object cache interfaces to be constructed
than might be needed in a given request. The configuration for these
interfaces is usually quite straight forward or can be trivially
verified from eval.php.
If we do want to log this, I would recommend doing it from the classes
constructor instead e.g. something like:
LoggerFactory::getInstance('MessageCache')->debug( get_class( $cache ) );
Bug: T189966
Change-Id: I06dc6dfbdf274bb57e9295b0c757b8d52c02acbe
This is only needed when viewing SpecialRecentChanges (or a related
page). Move the consuming logic to that class, where it can be
maintained as part of the rest of the code. This also makes it
more testable and makes config easier to work with or load from
elsewhere in the future. Aside from some dynamic default values,
configuration should generally not mutate. If there is some domain-
specific way to consume it, the relevant component should be
responsible for doing so. This also means we defer such logic to
where it is needed, instead of unconditionally for all possible
features that might be used.
Bug: T189966
Change-Id: If17608909711d98ac560b6d64f72ba7913a561a9
To my knowledge this never goes anywhere. These are left overs from
when we used profileIn/profileOut still, which we no longer use
given things like Tideways and XHProf are now recommended for
profiling, instead.
Bug: T189966
Change-Id: Id1bacc951f267dc1d3872aed935afd306adc37b3
This is always true and has been for years. I don't know of any
reason why someone would want to disable it, as the information
is only ever logged when the debug log is enabled, at which point
why not?
Bug: T189966
Change-Id: I17b9f564a61a0f76f2fc8c0006dc13997857829a
This is an unconditional and unconfigurable changes to PHP behaviour.
The earlier the better so that there is less code that can run
without it.
Also improve some documentation of other setup logic bits being
documented by the referenced task.
Bug: T189966
Change-Id: Ia8e1478cf0841d80b1c61c266f2ece75be2303e1
Following discussion in Ibb8175981092d7f41864e641cc3c118af70a5c76, this patch
proposes to further reduce the scope of what unit tests may access, by removing
the loading of DefaultSettings and GlobalFunctions.php. This also has the
implied effect of disabling the storage backend, as well as the global service
locator.
MediaWikiTestCase is renamed to MediaWikiIntegrationTestCase so it's scope and
purpose is more clear. Whether we still need to keep `@group Database`
annotation around is debatable, as it's unclear to me what the performance costs
are of implying database access for all tests which extend IntegrationTestCase.
As far as I can tell, `@group Database` is primarily used in CI to run faster
tests before slower ones, and with the new UnitTestCase the annotation seems
redundant.
To run all testsuites, use `composer phpunit`. Other composer scripts:
- `composer phpunit:unit` to run unit tests
- `composer phpunit:integration` to run integration tests
- `composer phpunit:coverage` to generate code coverage reports from unit
tests (requires XDebug).
Note that you can pass arguments to composer scripts with `--`, e.g. `composer
phpunit:integration --exclude-group Dump`.
Other changes:
- Rename bootstrap.php to bootstrap.maintenance.php so it's clear it's part of
the legacy PHPUnit-as-maintenance-class setup
- Create new bootstrap.php which loads the minimal configuration necessary for
the tests, and do additional setup in the run() method of the unit/integration
test case classes
- Move the unit-tests.xml file to phpunit.xml.dist in preparation for this being
the default test configuration
For a follow-up patch:
- Find unit/integration tests for extensions/skins
- Migrate other test suites from suite.xml
- Support running all tests via vendor/bin/phpunit
Bug: T84948
Bug: T89432
Bug: T87781
Change-Id: Ie717b0ecf4fcfd089d46248f14853c80b7ef4a76
Add some of the basic REST API class hierarchies:
* EntryPoint
* Router
* Request
* Response
* Handler
The actual entry point file rest.php has been moved to a separate
commit, so this is just an unused library and service.
Bug: T221177
Change-Id: Ifca6bcb8a304e8e8b7f52b79c607bdcebf805cd1
Currently, $wgSharedTables - if configured - is injected into the LoadBalancer
before the WAN cache autodetection runs. As such, if $wgSharedTables is set
but $wgMainWANCache was not explicitly given, the LoadBalancer will force
a premature instantion of the WAN cache with an EmptyBagOStuff backend,
preventing the autodetection logic from setting a correct backend.
This change moves $wgSharedTables initialization after the WAN cache
autodetection to accunt for this scenario.
Change-Id: I59bb52f42905cda1c2aa47bc589a2f0b36b2a28f
This is not used when the ID is already in "cpPosIndex".
Also, prefix the "ChronologyProtection" header with "MediaWiki-".
The header is currently usused but might be useful for services
in the future.
Bug: T212550
Change-Id: Ia871e95966d3550bac3dc4b2edb58e18359af7d9
* Remove 'channels' field references from config/setup
* Remove 'relayer'/'channels' field reference in unit tests
* Remove unused DEFAULT_PURGE_CHANNEL class constant
* Also remove long-since bogus 'pool' field references
Follow-up to 4753b0a4ed
Change-Id: If6670ff4e1dccc8ae253a08b46d205601da10024
Running Composer manually with a user different from the webserver
user and ending up with a vendor/autoload.php file that's unreadable
to MediaWiki seems like an easy mistake to make. Make the error
message when that happens less cryptic.
Change-Id: I52600adceb38a7fc5384d00b5298e46a782c684f
In PHP before 7.3, the double start doesn't really matter: session_id()
changes the ID even if it was already started, and the warning from
session_start() can just be ignored. Which is what we did.
In PHP 7.3, now session_id() also warns and no longer changes the ID. To
preserve the previous behavior, we'll need to explicitly close the old
session and open the new one.
Bug: T213489
Change-Id: I02a5be1c3adb326927c156fdd00663bccee37477
Using count() function in loops makes things very slow because
of function overheads and this function gets called everytime the
loop runs meaning the bigger the value of the variable in count(),
the slower the loop as its value always gets computed as the loop
runs.
In this case, the use of foreach(...){} is possible in order to
perform the computation making it pretty fast hence improving the
performance.
Change-Id: Ie21fbf8f6acf72373d1da75023725b4592c80386
Add BCP 47 codes to $wgDummyLanguageCodes to ensure that
Language::factory() will return a valid MediaWiki-internal code if
given a BCP 47 alias. We will want to make $wgDummyLanguageCodes a
private property of LanguageCode eventually, but let's start with
removing it from user configuration.
Setting $wgDummyLanguageCodes in LocalSettings.php has been deprecated
since 1.29. Hard deprecate adding entries to $wgDummyLanguageCodes so
that we can eventually remove manual overrides from user
configuration.
This is a follow-up to 48ab87d0a3,
which described the various categories of codes, and
21ead7a98d, which added the correct
BCP 47 mappings.
Bug: T207433
Change-Id: I9f6dda3360f79ab65f6392f44c98926588d851c8
Way back in r8196, a test was added to assert that Setup.php is being
included at file scope.[1] That test was broken when I633a6ff23 moved the
inclusion of DefaultSettings.php into Setup.php itself.
This fixes the test by having it directly set a variable and see if that
variable is a global. Yes, there's several ways to bypass it, but we're
just trying to avoid accidents here rather than trying to be foolproof.
[1]: Or really, in the same scope as DefaultSettings.php. But it
intended to be checking for file scope.
Change-Id: I9b5f15bf01c2903e8d44d85c54465d90c047cb51
The former is already a wrapper around ObjectCache::getInstance().
The latter was identical to ObjectCache::getLocalClusterInstance().
Bug: T115890
Change-Id: Ib4e43bc8d3f4ac9f7a453e36dcce9b3d962666ba
