Follows-up Idb5b0d21adc6. Avoid hardcoded references to REST internal
configuration variables, which create awkward "APIs" in the long run.
These are hard to deprecate or detect use of, and even harder to
normalize/support once variations exist. E.g. in T189966 and T233886,
I've been working to remove the concept of dynamic config in favour of
the uncomputed values being only valid as configuration for the
component that owns the variable, instead of using Config as public
API to read non-normalized information that belongs to a different
component.
By making the recipient responsible for any dynamic computation, it
also becomes clear that these are in fact not normalized or validated,
which can expose any number of unpredictable behaviours if used
directly. Consider special values like `false` or `null` and the
responsibility for interpreting that. Accessing these from a stable
function also gives a natural place for deprecation to happen. The
alternative, is for dynamic computation to happen in Setup.php for
all variabls, and only ever grow and become an append-only dumping
ground for every thing that we feel at some point needs validation,
normalization or expansion, which doesn't scale well, hence I reversed
this trend in T189966/T233886.
As it happens, RestPath actually is already computed, albeit very
trivially. This patch opens the way for someone to remove that in
favour of PathRouter accept `false` directly and expanding (and testing)
that code there instead.
As for REST API, the only stable and universally supported entrypoint
is /w/rest.php. Unlike some older entry points, we don't support
moving or removing the rest.php file. We do support routing/aliasing
additional paths to it.
Change-Id: I589a8aed8db3b8e7b72e4505749bb7ef25a755d9
Move open search description endpoint from /w/opensource_desc.php
to /w/rest.php/v1/search.
Bug: T363984
Change-Id: Idb5b0d21adc6152ef77e6d17846b6acc6a904e01
This patch introduces a new namespace declaration,
MediaWiki\Xml and adds Xml and XmlSelect to it
and establishes class aliases marked as deprecated
since version 1.43.
Bug: T353458
Change-Id: I45cccd540b6e15f267d3ab588a064fbeb719d921
Changes to the use statements done automatically via script
Addition of missing use statements and changes to docs done manually
Change-Id: I443aada1c18c8628b02671aa9fd6f441961e5c2e
The Hooks class contains deprecated functions and the whole class is
going to get removed, so remove the convenience function and inline the
code.
Bug: T335536
Change-Id: I8ef3468a64a0199996f26ef293543fcacdf2797f
Avoid leaking local variables into the global scope by accident, by
moving the entry point code to a function.
In index.php, document the intentional $mediaWiki global so that
nobody removes it by accident.
Change-Id: Ie1a181ae3ebdda90cd2321f0c1b50e31fb0d586e
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
Turn this into a doc group, and let the descriptions come
directly from the files in question. This makes the list easier
to maintain, and alsom means that the overview page becomes
discoverable whenever one is looking at the entry point file
as well. Previously the doc page pointed to the entry points,
but not the other way around. This is also fixed.
Bug: T244294
Change-Id: I891c5a37e17592edc1136d7367949927121c8bc8
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
These two entry points have themselves partly indexed by Doxygen
in a very strange way where these two comments cause part of an
if-statement to be seen as the name of a local variable.
Probably due to some kind of bad interaction with the
maintenance/mwdoc-filter.php filter applied to the file before
it gets indexed.
Fix it for now by avoiding use of /** blocks for something that
isn't a class, function, class member or documented global var.
Change-Id: I4903069e704c3283e6ec7a39999a489d0117cc71
Attempts to use session data via these endpoints will now cause
exceptions to be thrown.
Bug: T127233
Change-Id: I28b080a84e7b928e4336a5a1ec770bb57b05d009
* a9.com OpenSearch website doesn't exist anymore. I replaced it with OpenSearch.org.
* Change HTTP protocol for the xmlns:moz website. I removed the website redirection.
Change-Id: I2c261cd654f009a9316510f2cf80944235c1af82
The siteinfo API response's 'writeapi' value is now hard-set to true,
as are the ResourceLoader variables wgEnableAPI and wgEnableWriteAPI,
to be deprecated later.
Bug: T115414
Change-Id: I54ff9428b247ba203d67aba079149393f323d5a9
These are so simple there will probably be no problems, but let's set
them to 'warn' for a week just to be sure.
Bug: T127233
Change-Id: I04007faaf541f30dcaf2085fa86b45bea1ecb754
This allows empty lines inside the comment as found by the
MediaWiki.WhiteSpace.SpaceBeforeSingleLineComment.EmptyComment sniff
Change-Id: Iac155bbda4a84562db2b452baeae9b8973899453
There's really no reason for the extension to exist separately from
core, and merging it reduces the risks of bitrot in both the extension
(lots of deprecated functions there) and core (missing integration with
PageImages and TextExtracts, for example).
Change-Id: Ie0ab90902ede9499879402290006466efba479e9
Follows-up I1343872de7, Ia533aedf63 and I2df2f80b81.
Also updated usage in text in documentation and the
installer LocalSettingsGenerator.
Most of them were handled by this regex:
- find: (require|include|require_once|include_once)\s*\(\s*(.+?)\s*\)\s*;$
- replace: $1 $2;
Change-Id: I6b38aad9a5149c9c43ce18bd8edbab14b8ce43fa
Fix up spaces in our function calls, we do not want spaces before a
comma and try to avoid multiple commas whenever possible.
Errors:
* No space found after comma in function call
* Space found before comma in function call
Change-Id: I51aec02016f742422fa60b92ad35ba3f0ef59ba3
Removed left over uses of dirname( __FILE__ ) to __DIR__, even in comments.
Running the PHP version test in maintenance/Maintenance.php earlier, so that
we no longer have to stay PHP < 5.3 compatible in there.
Change-Id: I5a00bd5c6af44b7f826c4e5576a7b3de7b5026d8
This is done by adding the <moz:SearchForm> extension element with the Special:Search URL.
Removed the 24-character truncation on ShortName... neither Firefox nor IE seems to care about longer names, but both expect the ShortName and <link> title to match, and will think you have a duplicate search provider if they don't match because only one was truncated. (Besides, 24 was longer than the spec's limit of 16 -- why bother limiting at all if not to spec?)
The JSON suggestions are now no longer included in the OpenSearch description if the API is disabled, since the interface won't work.
Generally removed some hardcoded escape-then-stick-vars-in-string-output eww... Extension hooks now have a more general opportunity to alter or replace the OpenSearch URLs by tying into the OpenSearchUrls hook.
* check in a new ajax suggestion engine (mwsuggest.js) which uses
OpenSearch to fetch results (by default via API), this should
deprecated the old ajaxsearch thingy
* extend PrefixSearchBackend hook to accept multiple namespaces for
future lucene use (default implementation however can still
process only one)
* Added to preferences, also a feature to turn it on/off for every
input (disabled atm until I work out browser issues completely)
* WMF wikis probably won't be using API to fetch results, but a
custom php wrapper that just forwards the request to appropriate
lucene daemon, added support for that
SpecialSearch:
* moved stuff out of SpecialSearch to SearchEngine, like snippet
highlighting and such
* support for additional interwiki results, e.g. title matches
from other projects shown in a separate box on the right
* todo: interwiki box doesn't have standard prev/next links to
avoid clutter and unintuitive interface
* support for related articles
to avoid passing the length limit as often, is customizable per site via
'opensearch-shortname' message.
Note that the spec actually says ShortName should be trimmed to *16* chars,
which is pretty awful -- 'Wikimedia Commons' doesn't even fit. I haven't
changed the current trimming (to 24 characters).
Note that Firefox uses the longer 'Description' field for its 'add' menu
item, but the ShortName for the actual item once you add it to the menu.
Possibly should have separate description and shortname thingies and do some
smarter trimming. Sigh.
