The variables are set conditional later, but all condition branches set
it or the variable is not used outside that scope
Change-Id: Ic9612915db507028ad4733a061d3ce9be3babfb6
The code relating to the editing of JS/CSS/JSON is pulled out
into a separate function getCodeEditingIntro
AS well as aiding readability this will also allow us to improve
communication with editors on these important pages.
Bug: T311891
Change-Id: If63aeddf7adfacaa29bd43b997fefc28ee2f5f86
Despite the label stating "Preview of subject:", the thing shown
afterwards was actually the preview of the entire edit summary.
This has been the case since 2008 (b49d9f5ae3).
Previewing just the subject (section title) would be useless, since
it's included in the main preview.
Also fix live preview to preview the whole summary, not just the subject.
Change-Id: I9c3acb2e722d70ffe57bdbaa7cc175ef33e91928
Previously, `$this->summary` was used for two different purposes.
Usually it was just the summary. But when `$this->section` was 'new',
then it was actually the section title most of the time – unless
`$this->sectiontitle` was also set (in which case it took priority),
and until it was replaced by the real edit summary (near the end of
the processing, after copying the section title to the page content
and before saving changes).
Unsurprisingly some of the code didn't handle this duality correctly,
causing T191722 and T311533.
Now `$this->summary` is always the summary, and when `$this->section`
is 'new', then `$this->sectiontitle` is always the new section title.
The only place where this duality remains is in the input attributes
and query parameters, where 'wpSummary' is still used for both the
summary and the section title inputs (only one of them can appear,
depending on whether `$this->section` is 'new'). It would be an
unreasonable backwards-compatibility break to change this, and the
code handling this is somewhat isolated from the rest of the logic.
Bug: T191722
Bug: T311533
Change-Id: I5313ca9a045d112ece390b011a34192220e2abc1
When a page save fails due to a rate limit being exceeded, show an error
message and the edit form with the submitted text, instead of throwing
away the submitted text.
Most error display in EditPage is done in showHeader(), hence the lack
of examples to follow here in handleStatus(). PermissionsError has a
bunch of useful logic so is not easily replaced, and permissions errors
may also be shown before save. ReadOnlyError handling is duplicated in
edit() and showHeader() so the exception here is usually not thrown.
Change-Id: I7cb268fb6e20888cddef73d0ee9b0bf060ccafda
WikitextContent methods replaceSection() (used when adding a section
to an existing page) and addSectionHeader() (used when creating a new
page) behaved inconsistently - the former would omit the heading
syntax when the section title was empty, but the latter would not.
They both omit it now.
Some callers of addSectionHeader() handled this case, but others did
not, which caused T311489. (I am removing the checks now, since the
change makes them redundant.)
Bug: T311489
Change-Id: Icd59bcf2b75bf50865f19fac92bddabe0c183dcc
Before this commit, the base page is always returned in some
situations, e.g. if the UI and content language are the same. This
avoids extra lookups and ensures a cleaner URL.
In some cases, we would prefer to get a subpage even in this
situation, e.g. transcluding a translatable page. Add a method
that always performs the lookup.
Also update EditPage::getPreloadedContent to use the new method.
Bug: T309329
Change-Id: I739cee94620bc8d0689a4d3ec5898bfd75c18b8a
'summary' must only be used as the section title when 'sectiontitle'
is not provided. Otherwise the provided section title must be used,
even if it is empty.
Bug: T54747
Change-Id: Id86d5cdd9e04cf1b2f3fbf243a4b250e2924cf87
This is mostly about adding return types to methods that implement PHP
interfaces, and not passing null to core functions that want a string.
After this patch, and an update to return types in RemexHtml,
tests/phpunit/integration/ has no more errors than in PHP 8.0.
Bug: T289879
Bug: T289926
Change-Id: Ia424f5cc897070f4188ae126b5bf6a1f552db0e1
This is required for the Vector (2022) skin to display
the new floating table of contents.
Bug: T294950
Bug: T307256
Change-Id: I9922e411634dfe66b2ed3d84aeb8f4ffffe84faf
- Use PageIdentity instead of LinkTarget
- Inject all needed services
- Use Html class to build html
- Use the PageIdentity to build the link and not build new TitleValue
- Break line and improve comments for readability
Change-Id: I70062862053640e073ee8595ad9e78a02a3eff78
The TempUserCreatedRedirect hook was called with the request user, which
is typically an IP address. This causes an exception in the proposed
CentralAuth patch, because User::newFromName() returns false for an IP
address.
So, pass the "user for save", which is the actual created user with a
correct user ID.
Change-Id: Id4f0e393216da4a1da35922e27f97050931761f0
IDs "#mw-anon-edit-warning", "#mw-anon-preview-warning",
"#mw-undelete-revision", "#mw-userinvalidconfigtitle", and
"#mw-previewconflict" are replaced with same-name classes,
while "#mw-preferences-success" is removed.
Bug: T304363
Change-Id: I2d42520e7adc7e6fa7ec3a85b089d5f303cf9bfd
Add a hook "TempUserCreatedRedirect" which allows an extension to modify
the post-save redirect after a temporary user is created. CentralAuth
will handle this hook in order to redirect to loginwiki. Loginwiki will
redirect back to the page being saved.
In LoginHelper::showReturnToPage add an "anchor" parameter to specify
the URL fragment to redirect to. This is intended for section editing
with a redirect via loginwiki.
In AuthManager::autoCreateUser(), just allow any valid username, don't
require it to be creatable. Previously a non-creatable username was
allowed only with $source=AUTOCREATE_SOURCE_TEMP, but CentralAuth
depends on user autocreation from the session during refreshCookies. The
session is already validated at this point, so it's not like a user can
exploit this to create arbitrary names.
Change-Id: I623330dbf5d0573c93ae22f962618d6ddbd126d9
* Treat temp users as anons for skin login, logout and create account
links. Suppress temp user preferences and watchlist UI.
* Show a post-edit notification box after a temporary account is
created.
Change-Id: Ib935fc04387100f25cafd75c632ac5ae7114d5d5
* Allow EditPage to create a user on page save. This has to be enabled
in config and then activated by the UI/API caller.
* Add an autocreate source for temporary users.
* Allow editing by anonymous users via automatic account creation when
$wgGroupPermisions['*']['edit'] = false. On an edit GET request, use
an unsaved placeholder user to stand in for post-create permissions.
* On preview or aborted save, the username to be created is stashed in a
session and restored on subsequent requests.
* On a (likely) successful page save, create the account.
* Put regular non-temporary users in a "named" group so that they can be
given additional permissions.
* Use a different "~~~" signature for temporary users
* Show account creation warnings on edit and preview.
Change-Id: I67b23abf73cc371280bfb2b6c43b3ce0e077bfe5
I somehow missed the usage in TwoColConflict. So undeprecate the
property until that is fixed.
Bug: T305028
Change-Id: I6629e449eb8444a53950387953bb6da3a317113a
Use name constants instead of string literals in calls to Config::get
and ServiceOptions::get, when referring to core configuration variables.
This protects against typos and makes the decumentation and schema
declaration of the config settings discoverable.
This is the first batch, only touching files directly under /includes/
Change-Id: I7252e636c7c86d950d9257b33491af492c6dd5eb
This should not change any behavior. Just makes the code easier to
read and gets rid of one reference to the problematic, deprecated
$textbox2 property.
Bug: T305028
Change-Id: Ib49cc284dc7299169fa14b5d2d1855f54b8504ad
Make phan stricter about conditional variable declaration
Remaining false positive issues are suppressed.
The suppression and the setting change can only be done together
Bug: T259172
Change-Id: I1f200ac37df7448453688bf464a8250c97313e5d
Forgot some usage in previous patch, these should be entirely
rewrite in task T304363
Bug: T300358
Change-Id: I512b2fccaf07ba7578b66df04f6e5ab3baafe55b
Only unused properties were hard-deprecated. Everything else wasn't
touched due to the lack of proper replacements.
Also simplify getEditPermissionErrors, and make a few more methods
private after their only usages were removed in
Ie4d6389912557cd4dbe380334d0726eef5746e61.
Change-Id: Idf2ba30e2e9b24e34ad22968a1b7d931f818dd91
One of the things that make refactoring EditPage even harder is the
large number of public/protected methods and the existence of
subclasses. This class changes the visibility to private for all methods
that are never used outside of EditPage itself.
I've manually checked codesearch (in "Everything") for usages of these
methods, and only changed the ones unused outside. A single usage, even
if in an unmaintained 3rd party extension, means that the method stays
protected/public for now. The only exception to this is ::tokenOk, which
is marked as @internal since I4c7c6e7b5a80e86456965521f88d1dfa7d698f84
(in 2020) and before that, as @private since [1] (in 2004); as such, any
external use of that method was ill-advised in the first place.
Although it happens quite commonly, this class is not stable to extend,
hence these changes do not need a deprecation phase.
Also replace a couple more deprecated methods and adjust some typehints.
[1] - 7030f69a1a
Bug: T252907
Change-Id: Ic5bd295cd896b05f0a88cb2085e11ad5b640e240
Conventionally, public constants are accessed via their declaring
class, except for self:: which is an acceptable shortcut.
Change-Id: If05eab72140267e6ef54736710d751d7f24a7860
Use multiple error boxes instead of a wikitext list of error messages,
as the latter has several issues (as reported on phab). Also, remove the
edit-error-* messages as they don't seem to add any value. Also, don't
use the passed-in context, inject what the class actually needs instead
(but keep the context for the hook).
Bug: T303060
Bug: T230229
Change-Id: I2806e57826e7ab062b45dd1d9972b05fd6baeafb
Make phan stricter about null types by setting null_casts_as_any_type to
false (the default in mediawiki-phan-config)
Remaining false positive issues are suppressed.
The suppression and the setting change can only be done together
Bug: T242536
Bug: T301991
Change-Id: I0f295382b96fb3be8037a01c10487d9d591e7e01
