In change I625a48a6ecd3fad5c2ed76b23343a0fef91e1b83 I am planning to
make Wikimedia\Message\MessageValue use it, and we try to pretend that
it is a library separate from MediaWiki, so it makes sense to move
MessageSpecifier to the same namespace under Wikimedia\.
Bug: T353458
Change-Id: I9ff4ff7beb098b60c92f564591937c7d789c6684
The documentation for ApiErrorFormatter::addError() was updated in
I1323d18baf17a8a27cc9bed31860c4cc89e61a22
Otherwise, phan complains about handing a MessageSpecifier to that
method.
Change-Id: If421729d58cd7e3e7dd7b866c671915ea8f47154
$this->mParams['file'] and $this->mParams['chunk'] are set to instance
of \Wikimedia\ParamValidator\Util\UploadedFile in the validation step.
Use ApiMain::getUpload
Fix ApiUploadTestCase to set error key to OK,
the null gets converted to UPLOAD_ERR_NO_FILE in
\Wikimedia\ParamValidator\Util\UploadedFile::getError
and breaking the test.
Change-Id: If57307a3f8278fd3fa25732231595bf148935679
With this change, when async uploads are enabled, upload-by-url
will spawn a job and a form with a button to check the status of the
process is shown to the user.
In the process, add processing of warnings in the remote jobs spawned by
the API or the Special page. This is done by adding checks to
UploadJobTrait::verifyUpload. In order to manage warnings serialized in
the job status, a method to unserialize the result of
UploadBase::makeWarningsSerializable.
Things that we might want to fix:
* The form's UI is abysmal, we should probably use Codex
* While it's not a huge deal, I'd like to figure out why I need to
purge the page cache if I want the file to show up. And more
interestingly, why this doesn't happen when uploading via the API
Bug: T295007
Bug: T118887
Change-Id: I49181d93901f064815808380285fc4abae755341
To this end if 'async' is passed with 'url' to the api:
* Avoid downloading the file synchronously, but verify early
if the upload is allowed by adding a canFetchFile to UploadBase
overridden in UploadFromUrl
* Spawn an UploadFromUrlJob
* When checking for the status of the job, do it fetching the data in
the main stash.
Bug: T295007
Change-Id: If95ccf376cfa9fbe9b3cd058e8e334a6bdd2eb44
Uploads can be a long operation that we would prefer not to get
cut off. The API upload module supports a variety of upload types.
This calls useTransactionalTimeLimit() for all of them (except
checkstatus which is not a write operations) however it is more
applicable to some methods than other methods such as "async" where
the real work happens in the job queue.
Change-Id: I6795f6d38693306f22091afa77123f2f0721ef5b
The ChunkedUpload feature stores information about in progress uploads
in the uploadstash table. The AssembleUploadChunksJob reads this data
from the primary DB to prevent race conditions. However the job is
inserted into the job queue before the current transaction commits,
so the race is still present. The job sees the old version, and as
a result drops the final chunk, corrupting the file (Often noticable
by files that have a size which are a multiple of 5mb).
This changes the job push from ->push to ->lazyPush which will make
the job insert happen in a DeferredUpdate after the primary transaction
has commited. Additionally, pass the expected size to the job queue
and assert that UploadStash class has the same filesize as expected.
This will ensure that if this issue happens again, the upload will
abort and it will show up in the logs instead of silently corrupting
files.
Bug: T350917
Change-Id: I37c5c8ffc882026a9fab252b20a10cf4c43d48bc
One possible theory for why chunked upload is unreliable is that
there are multiple jobs racing each other. Add some logging warnings
that should detect such a situation, and abort job if it appears the
job is already in progress
Bug: T200820
Change-Id: Ifaf217bc288dfaa1f7f4ca7e58f8210df232db1b
Users often complain that chunked upload is unreliable. However
it is often difficult to see what happened when it failed. Add
additional debug logging so we can better determine how often
chunked upload fails, and hopefully have a better idea what the
causes are.
This only adds logging and should not change any behaviour
Change-Id: I45b710fa57c7d05bb27a7b00a3303e78f5d2ff2a
The array spread operator is documented to behave identical to
array_merge. The syntax is just much shorter and easier to read in
situations like this, in my opinion.
Change-Id: I3b016e896e552af53d87d5e72436dc4e29070ce1
API modules are high level request handler, lower level code should not
depend on them.
This patch solves the problem only partially, since it leaves references
to ApiUpload in AssembleUploadChunksJob and PublishStashedFileJob. These
jobs were already accessing ApiMain, so while this does not fully resolve
the problem, it reduces it.
Change-Id: I39c9e30cfb2860c573eed8a791f1a292a83cbd76
There are a couple of user options related classes already,
and the T321527 work on dynamic defaults is going to add
even more. Let's move them into a separate namespace
to make core a bit more organized.
Old name is kept as an alias for compatibility purposes.
Bug: T321527
Bug: T352284
Change-Id: I9822eb1553870b876d0b8a927e4e86c27d83bd52
This method is now redundant since rate limit checks are implicit in
permission checks. verifyPermissions() calls authorizeWrite( 'upload' ),
which will enforce any limits on the upload action.
Change-Id: I2ab3c646b8246411df501b548f652eaf11d0bc8e
Mostly used find-and-replace:
Find:
/\*[\*\s]+@var (I?[A-Z](\w+)(?:Interface)?)[\s\*]+/\s*(private|protected|public) (\$[a-z]\w+;\n)((?=\s*/\*[\*\s]+@var (I?[A-Z](\w+)(?:Interface)?))\n|)
Replace with:
\3 \1 \4
Followed by some manual review to make sure I'm not changing too much,
omitting some changes that looked too complicated and anything that
caused test failures, and some whitespace fixes.
Change-Id: I6ec7587607df4f1a4f448a096c3e44c4e5270b70
This class is used heavily basically everywhere, moving it to Utils
wouldn't make much sense. Also with this change, we can move
StatusValue to MediaWiki\Status as well.
Bug: T321882
Depends-On: I5f89ecf27ce1471a74f31c6018806461781213c3
Change-Id: I04c1dcf5129df437589149f0f3e284974d7c98fa
mw.Upload.BookletLayout and ApiUpload prompt IP users to log in
if they do not have the permission to upload. Show the same
prompt to temporary users if they do not have the permission.
Bug: T331578
Change-Id: Ic35d8277772d69155fe95b24cc028f91b8a366bb
Since f102d7b42e882b330030021bb3419af708b26fa5 in the
GlobalBlocking extension, global blocks are found when checking
for blocks, and do not need to be checked for separately from
core.
Bug: T317325
Change-Id: I7e93ec2d8125fd4a41ed3dec7c0ef9148ab1afe2
This patch only adds and removes suppressions, which must be done in the
same patch as the version bump.
Bug: T298571
Change-Id: I4044d4d9ce82b3dae7ba0af85bf04f22cb1dd347
This covers all occurrences of /onfig->.*get( '/ in includes/.
Undoubtedly there are still plenty more to go.
Change-Id: I33196c4153437778496f40436bcde399638ac361
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
If no tags are specified, null shouldn't be passed as it may
cause problems down the stack
Bug: T302918
Change-Id: I46033d5ddda055c275dbda71d5c38c4a7a858c9d
This trait is not needed in ApiBase and its presence here is
proving to be problematic. See I795db12.
In this patch, the trait usage (more precisely the 'use statement')
has been removed from ApiBase and accordingly the signatures of
ApiWatchlistTrait::getWatchlistValue() and ::setWatch() have been
altered to now require User object.
With these changes, the abstract getUser() method in the trait is no
longer needed, so it has been removed also.
All core usages of the affected functions are fixed in this patch.
The trait is used in only one extension according to codesearch tool,
the extension will be fixed in Ic22e163.
Bug: T262175
Bug: T248512
Follow-up: Ia18627b9824dca81f44f0571e8420d89b7626cf6
Change-Id: Idabcea71edfca9e7ed42000a258c99ff407873d4
