> A long, long time ago,
> I can still remember how those warnings used to make me smile.
> And, I knew if I had my chance, that I could make those traces dance,
> and... Maybe they'd be present for a while.
Ever since T45086, we have traces for warnings in production
so this is no longer needed. Also it uses getTraceAsString()
which is something we're trying to phase out.
Bug: T233342
Change-Id: I79ce582c7f057b22a9ead2f2b014aba41f869325
For compliance with the new version of the table interface policy
(T255803).
This patch was created by an automated search & replace operation
on the includes/ directory.
Bug: T257789
Change-Id: I17e5e92e24c708ffc846945a136347670a3a20c7
For compliance with the new version of the table interface policy
(T255803).
This patch was created by an automated search & replace operation
on the includes/ directory.
Bug: T257789
Change-Id: Ie32c1b11b3d16ddfc0c83a757327d449ff80b2e4
For compliance with the new version of the table interface policy
(T255803).
This patch was created by an automated search & replace operation
on the includes/ directory.
Bug: T257789
Change-Id: I5ffbb91882ecce2019ab644839eab5e8fb8a1c5f
For compliance with the new version of the table interface policy
(T255803).
This patch was created by an automated search & replace operation
on the includes/ directory.
Bug: T257789
Change-Id: If560596f5e1e0a3da91afc36e656e7c27f040968
This classes were found by surveying concrete classes derved from base
classes in core.
Bug: T247862
Change-Id: I231752aaad26e2ab3f097301e449b31e723590f0
The following glasses are marked as newable per the
Stable Interface Policy, even though logically, they should not be
newable. This is done for classes that are currently instantiated
by extensions, and lack an alternative.
A better way for obtaining an instance of these classes should be
created in the future. At that point, direct instantiation should
be deprecated and replaced.
- includes/ApiMain.php - needs factory
- includes/media/BitmapMetadataHandler.php - should become a stateless service or use handler pattern
- includes/GitInfo.php - should become a stateless service
- includes/logging/LogPage.php - should become a stateless service or use command pattern
- includes/logging/ManualLogEntry.php - should become a stateless service or use command pattern
- includes/poolcounter/PoolCounterWorkViaCallback.php - needs a factory
- includes/context/RequestContext.php - needs to be narrowed down, and should use a factory
- includes/search/SearchHighlighter.php - should have a factory
- includes/TitleArrayFromResult.php - should perhaps be part of TitleFactory
- includes/user/User.php - should at least get a factory method for anons
- includes/diff/Diff.php: needs a TextDiffGenerator service or a factory
- includes/EditPage.php: needs a factory
Bug: T247862
Change-Id: I033158e693c98630ee167d9528fc8c9936f978d4
Per the Stable Interface Policy, PHP interfaces should not be
directly implemented by extensions, unless they are marked to be safe
for that purpose.
Bug: T247862
Change-Id: Idd5783b70fc00c03d57f5b1a887f0e47c4d7b146
This annotates classes that can safely be instantiated by
extensions, per the Stable Interface Policy.
Bug: T247862
Change-Id: Ia280f559874fc0750265ddeb7f831e65fd7d7d6a
A terminating line break has not been required in wfDebug() since 2014,
however no migration was done. Some of these line breaks found their way
into LoggerInterface::debug() calls, where they mess up the formatting
of the debug log.
So, remove terminating line breaks from wfDebug() and
LoggerInterface::debug() calls.
Also:
* Fix the stripping of leading line breaks from the log header emitted
by Setup.php. This feature, accidentally broken in 2014, allows
requests to be distinguished in the log file.
* Avoid using the global variable $self.
* Move the logging of the client IP back to Setup.php. It was moved to
WebRequest in the hopes that it would not always be needed, however
$wgRequest->getIP() is now called unconditionally a few lines up in
Setup.php. This means that it is put in its proper place after the
"start request" message.
* Wrap the log header code in a closure so that variables like $name do
not leak into global scope.
* In Linker.php, remove a few instances of an unnecessary second
parameter to wfDebug().
Change-Id: I96651d3044a95b9d210b51cb8368edc76bebbb9e
Migrate all callers of Hooks::run() to use the new
HookContainer/HookRunner system.
General principles:
* Use DI if it is already used. We're not changing the way state is
managed in this patch.
* HookContainer is always injected, not HookRunner. HookContainer
is a service, it's a more generic interface, it is the only
thing that provides isRegistered() which is needed in some cases,
and a HookRunner can be efficiently constructed from it
(confirmed by benchmark). Because HookContainer is needed
for object construction, it is also needed by all factories.
* "Ask your friendly local base class". Big hierarchies like
SpecialPage and ApiBase have getHookContainer() and getHookRunner()
methods in the base class, and classes that extend that base class
are not expected to know or care where the base class gets its
HookContainer from.
* ProtectedHookAccessorTrait provides protected getHookContainer() and
getHookRunner() methods, getting them from the global service
container. The point of this is to ease migration to DI by ensuring
that call sites ask their local friendly base class rather than
getting a HookRunner from the service container directly.
* Private $this->hookRunner. In some smaller classes where accessor
methods did not seem warranted, there is a private HookRunner property
which is accessed directly. Very rarely (two cases), there is a
protected property, for consistency with code that conventionally
assumes protected=private, but in cases where the class might actually
be overridden, a protected accessor is preferred over a protected
property.
* The last resort: Hooks::runner(). Mostly for static, file-scope and
global code. In a few cases it was used for objects with broken
construction schemes, out of horror or laziness.
Constructors with new required arguments:
* AuthManager
* BadFileLookup
* BlockManager
* ClassicInterwikiLookup
* ContentHandlerFactory
* ContentSecurityPolicy
* DefaultOptionsManager
* DerivedPageDataUpdater
* FullSearchResultWidget
* HtmlCacheUpdater
* LanguageFactory
* LanguageNameUtils
* LinkRenderer
* LinkRendererFactory
* LocalisationCache
* MagicWordFactory
* MessageCache
* NamespaceInfo
* PageEditStash
* PageHandlerFactory
* PageUpdater
* ParserFactory
* PermissionManager
* RevisionStore
* RevisionStoreFactory
* SearchEngineConfig
* SearchEngineFactory
* SearchFormWidget
* SearchNearMatcher
* SessionBackend
* SpecialPageFactory
* UserNameUtils
* UserOptionsManager
* WatchedItemQueryService
* WatchedItemStore
Constructors with new optional arguments:
* DefaultPreferencesFactory
* Language
* LinkHolderArray
* MovePage
* Parser
* ParserCache
* PasswordReset
* Router
setHookContainer() now required after construction:
* AuthenticationProvider
* ResourceLoaderModule
* SearchEngine
Change-Id: Id442b0dbe43aba84bd5cf801d86dedc768b082c7
Add hook interfaces which were generated by a script which parses
hooks.txt and identifies caller namespaces and directories.
Hook interfaces are mostly placed in a Hook/ subdirectory
relative to the caller location. When there are callers in multiple
directories, a "primary" caller was manually selected. The exceptions to
this are:
* The source root, maintenance and tests, which use includes/Hook. Test
hooks need to be autoloadable in a non-test request so that
implementing test interfaces in a generic handler will not fail.
* resources uses includes/resourceloader/Hook
* The following third-level subdirectories had their hooks placed in
the parent ../Hook:
* includes/filerepo/file
* includes/search/searchwidgets
* includes/specials/forms
* includes/specials/helpers
* includes/specials/pagers
Parameters marked as legacy references in hooks.txt are passed
by value in the interfaces.
Bug: T240307
Change-Id: I6efe2e7dd1f0c6a3d0f4d100a4c34e41f8428720
Follows-up to cad882954a. I considered augmenting
the sanitizeLangCode() or isValidCode() function to reject
invalid UTF-8. But I realise now that it isn't so much about
"invalid" UTF-8 as it is about non-canonical forms for expressing
otherwise valid UTF-8 strings.
For example "Le\xcc\x81cole" and "L\xc3\xa9cole" both render
as "Lécole" but use different ways to accomplish it. To prevent
creation of inaccessible page titles, and to make link creation
easy, UtfNormal is used to normalises these when opening redlink
urls and when saving wikitext.
While non-ASCII will continue to work after cad882954a, any
links to such characters must be made in normal form. Given
these are generally linked to from wiki pages or gadgets with
a predefined set of urls (and not typed ad-hoc by an end user)
this seems fine to require. I fid not find violations of this
on Commons.
Document the ceveat for now.
Change-Id: I36fece34e40f7e58b7aed5521c49a241a67d006f
Previously the first two post-hook checks where mutually exclusive
and the fallback was generic (not conditional) which means we
would also allow the first two conditions to succeed in a way that
leaves $this->skin as null.
Aside from that not being possible right now, it also duplicates a
null check in two places, which isn't ideal.
Codify that the first two blocks always result in $this->skin
being assigned non-null by using an 'else' branch instead of another
generic check.
Change-Id: I7986684bf1bb2daad3aaddfbcd2ca02e652f78c2
Wikimedia\quietCall() is deprecated and AtEase is here for use.
I would have loved to do restoreWarnings() and suppressWarnings()
in this same patch set but will continue the work for a later patch.
Bug: T182273
Change-Id: I43e3a5f378c99b5c40883b35ba133cbd126fc433
When this exception handler was introduced in change Ifbc1db4b82 (commit
9636d44448), MediaWiki still supported PHP 5.3.2, where finally was not
available. It was added in PHP 5.5, though, which we’ve required for a
while now, so we can simplify this a bit.
Change-Id: I7c967fb713de7495739e18ff6c6058a630129fda
This class specifically has these 2 things in many cases and converts
into the use of a tenary operations.
Quoting @Thiemo_WMDE from Gerrit comment: "The ?: operator will skip
empty arrays, empty strings, as well as the string "0". But this is
not a problem here because the properties under test are all objects.
Objects are always considered true in PHP."
Sample change can be seen below as, from;
```
if ( !is_null( $this->skin )) {
return $this->skin;
} else {
return $this->getContext()->getSkin();
}
```
to
```
return $this->skin ?: $this->getContext()->getSkin();
```
Change-Id: I377b118d86a24c7bcb15512f6714e6201a3e36ee
Per Krinkle's comments here: T198054#4598447, it's exactly what is
happening. @Fomafix suggests we handle the exception that is been
thrown by Language::factory() when there is an invalid language code
provided. The attempt is to fix this in the central way of ever request
whether POST or GET.
We're working within a particular context, and within this request
context, we can create a language user's language object then generate
a language object. If uselang parameter is provided an invalid language
code, getLanguage in this request context will default to $wgLanguageCode
then use this code to create the user's language object. In addition,
getLanguage() invalidates cached user interface language.
Bug: T198054
Change-Id: I825fdfa882a4243ffc63c9de0d7f482e2cfb9862
Uses new PHP 5.6 syntax like ...parameter unpacking and
calling anything looking like a callback to make the code more readable.
There are much more occurrences but this commit is intentionally limited
to an easily reviewable size.
Change-Id: Idcec077ef3fdf029b632cceafd0150851ad723e3
I'm also removing obsolete short comments that don't add anything to
whats already obvious from the method header. For example, I really don't
need a comment to understand that a method that's called "setUser" and
accepts a parameter named "$user" of type "User" is meant to "set the
User object". I mean, how more obvious can it be? ;-)
Change-Id: Ib079108457a5aa2a6896e95837542ab93b465144
I can see that "parent::__construct" literally calls the parent
constructor. I can see that stuff preceeded by the keyword "protected"
is protected. I really (really) don't need comments explaining such.
Change-Id: I7458e714976a6acd3ba6a7c93fdc27d03903df83
I spotted one of these in my debug log. Without context it is not
useful nor informative. Given it can actually come from three places,
it is useless.
Change-Id: Ic293d8944e9a1a8152c5a5e0b695c5ddc07ee6aa
For some varargs a variable name is added with suffix ,... as seen for
many other varargs
Some @param are swapped, because there are in the wrong order
Enable Sniff MediaWiki.Commenting.FunctionComment.ParamNameNoMatch
Change-Id: I60fec6025bce824d5c67563ab7b65ad6cd628ad8
Having such comments is worse than not having them. They add zero
information. But you must read the text to understand there is
nothing you don't already know from the class and the method name.
This is similar to I994d11e. Even more trivial, because this here is
about comments that don't say anything but "constructor".
Change-Id: I474dcdb5997bea3aafd11c0760ee072dfaff124c
Follows-up I2874175647e (7fdc3d09a3).
* Avoid "MediaWiki" in class names. If unavoidable, always camelcase.
* Use a more descriptive name, matching the implementing the class ("Buffering").
* Use "I" prefix for consistency with other MediaWiki-provided interfaces.
(Avoid "Interface" suffix, which is foreign to MediaWiki and is only used
in the StatsdClient namespace, which this interface is not in).
Bug: T166354
Change-Id: I06de59122625f9c23e7c1a1bfa69a7ddabbf379e
