Add doc-typehints to class properties found by the PropertyDocumentation
sniff to improve the documentation.
Once the sniff is enabled it avoids that new code is missing type
declarations. This is focused on documentation and does not change code.
Change-Id: I7dec01892a987a87b1b79374a1c28f97d055e8fa
Why:
* Maintenance scripts in core have bolierplate code that is
added before and after the class to allow directly running
the maintenance script.
* Running the maintenance script directly has been deprecated
since 1.40, so this boilerplate code is only to support a now
deprecated method of running maintenance scripts.
* This code cannot also be marked as covered, due to PHPUnit
not recognising code coverage for files.
* Therefore, it is best to ignore this boilerplate code in code
coverage reports as it cannot be marked as covered and also
is for deprecated code.
What:
* Wrap the boilerplate code (requiring Maintenance.php and then
later defining the maintenance script class and running if the
maintenance script was called directly) with @codeCoverageIgnore
comments.
* Some files use a different boilerplate code, however, these
should also be marked as ignored for coverage for the same
reason that coverage is not properly reported for files.
Bug: T371167
Change-Id: I32f5c6362dfb354149a48ce9c28da9a7fc494f7c
Moved to docs/ rather than includes/, update references and remove
from phan exclusion list
Follow-up: I32c034d05bf2354cdaa5f02d19031421cbae78a1
Change-Id: I8d71c29c8cbfa413db47066f00d71783259f0916
Similar to generateAutoload.php, this should work even without
an active MW install.
Fix the casing and signature to match the base class while at it.
Change-Id: I1b0928f7bbb2c151c8350b4bbe503dd2a07da34e
The MediaWiki\MainConfigNames class was added
in I817dc14c4ce8fc0a29d9c07e8fd393c4f359cade
which is not in 1.38 but only in 1.39 and later.
Change-Id: Ic25e64d109defc970c90e038a7de03d4ca8ed82c
generateConfigSchema.php was already generating all other files
directly, MainConfigNames.php was the only one based on the template.
Given the template was trivial and unlikely to change, this change
removes the template and changes the script to generate
MainConfigNames.php directly as well, in the name of consistency and
simplicity.
Change-Id: I7e7f2bfbc232d2ee6582638ced74b3e929be21ed
This allows config variables to be declared obsolete. Obsolete config
will be omitted from the schema, defaults, name constants, etc. The
purpose of keeping a declaration of obsolete config around is to allow
the updater to warn admins that they are using a config variable that no
longer has any effect, and provide them with a remedy.
The idea is that support for deprecated config can be removed after one
release per the stable interface policy, but the declaration of
obsolete config should be kept for as long as we support updates,
that is, at least two LTS releases.
See https://www.mediawiki.org/wiki/Topic:X4bh4nf3pe2ho5jj for
discussion.
Change-Id: Ia7a00742ea7a5311e820a6a43b11135a3f2a825f
The goal is to keep the actual default values for settings in the same
place as the setting is declared, and applied using the regular means
for loading the settings -- not in a separate piece of code that needs
to be loaded through some entirely different mechanism.
SetupDynamicConfig.php now contains a few categories of things:
* Post-processing of configuration settings, where already-set settings
are altered. This could be moved to MainConfigSchema too as a separate
set of methods.
* Processing of old aliases of settings (blacklist, slave) that are not
registered as settings anymore and therefore are not available to
MainConfigSchema. This could perhaps be moved to LocalSettings
processing somehow?
* Setting $wgUseEnotif, which is also not registered as a setting.
Easiest would be just to declare it as a setting and have it set
unconditionally.
* Setting the actual timezone to $wgLocaltimezone. This is not related
to configuration and should just be in Setup.php.
Bug: T305093
Change-Id: Ia5c23b52dbbfcb3d07ffcf5d3b7f2d7befba2a26
This adds support for JSONSchema style property declarations with nested
schemas. This is a step towards using more nested structured for
configuration, rather than adding to the over 700 keys already defined
in the main config schema.
Defaults from property schemas are aggregated into a default value in
the top level schema. Descriptions are however not yet aggregated.
Change-Id: Iaf46a9ecc83bee3566098c56137a1be66bff2ab9
Previously, each of the four derived config schema files had to be
regenerated using a separate maintenance script. This change simplifies
regeneration by combining all for scripts into a single command that can
be used to regenerate all relevant files after changing
MainConfigSchema.
Change-Id: I7d38d8a4aede60475c4bdd0053d2e10e298b9843
Instead of maintaining the config schema as a yaml file, we
maintain it as a set of constants in a class. From the information in
these constants, we can generate a JSON schema (yaml) file, and an
php file containing optimized arrays for fast loading.
Advantages:
- PHP doc available to IDEs. The generated markdown file is no longer
needed.
- Can use PHP constants when defining default values.
NOTE: needs backport to 1.38
Change-Id: I663c08b8a200644cbe7e5f65c20f1592a4f3974d
