Removed 'Remember my login' from Preferences, as it was unwanted. It adds
to the complexity of the user preferences
Bug: 52342
Co-Author: Tyler Romeo <tylerromeo@gmail.com>
Change-Id: I7c957e1e1aaecf47f7c47bc063b5d3b364644afc
Prior to fc20c30d20, the feed was cached for 10 seconds. That
change accidentally removed varnish caching. Re-add the caching,
and upping to 15 seconds for good measure (15 second delay on the RSS
feed shouldn't matter, people generally read those asynchronously
anyhow. I was thinking of maybe even uping to 30 seconds). Users
can still manually set an smaxage parameter via the url if they
don't like the default cache time.
This assumes nothing private (e.g. per user) is ever on the RSS
feed. Reading through the ChangesList code this appears to be
the case, as everyone is getting the feed from a shared
memcache entry.
Bug: 63249
Change-Id: I268d0a53067738ba96bee74c593358b0b28cc083
API queries must be completely ordered for proper behavior; otherwise
you may get into a situation where a query returns the same continuation
value that was provided. Various modules that have been using timestamps
in/as their continuation parameter can easily run into this problem.
Normally we'd have to add additional fields to the relevant indexes to
be able to make this work without having filesorting queries (which
MySQL really doesn't do well, it fetches all matching rows and only
applies the limit after[1]). But InnoDB has a "feature" where it
effectively appends the table's primary key to all other indexes,[2]
which makes these queries be properly indexed in that situation.
Apparently we're ok with this, since Icc43b62f was merged depending on
this feature.
Also, this change fixes some MySQLisms and other oddities done to
ApiQueryRecentChanges in Icc43b62f.
[1]: https://dev.mysql.com/doc/refman/5.5/en/limit-optimization.html
[2]: https://dev.mysql.com/doc/refman/5.5/en/innodb-table-and-index.html
Bug: 24782
Change-Id: I4c9f8c0c2bfd831755d4fa20a18f93fef1effd28
It's pretty much like action=opensearch but can be used as a generator
which can be handy when you need to retrieve both the list of pages and
some information about them.
Change-Id: Iaffe30a0f7402e1316c4885a805692a34bbe1a6a
Also removed true as second parameter to it from CloneDatabase.php
since it is the default value of that parameter.
Change-Id: I727ebae2bd4df0e26019985ce8c7ce73381c5642
One of the causes (if not the cause) of bug 56269 is if something
manages to throw an exception that makes it to MediaWiki::run's
last-resort exception catcher while having an open database transaction:
the transaction never gets committed or rolled back, so it gets
implicitly rolled back and a warning is raised.
The API has the opposite problem in bug 63145: it catches the exception
but then does the normal DB shutdown which *commits* the transaction.
This is certainly the Wrong Thing to do.
Ideally, neither of these would ever happen because any code using
transactions would have its own try-catch that would catch any
exception, rollback the transaction, and then rethrow the exception. But
it happens anyway, so let's have both of these last-resort exception
handlers do the rollback, and also log the exception so the throwing
code has a better chance of being properly fixed.
Bug: 56269
Bug: 63145
Change-Id: I8f1da51187b281fe4afc0d5a0c49f5caf3612e92
ApiFormatFeedWrapper, for example, has nothing particularly useful to do
when given an API error to print. So allow for punting errors to the
default formatter instead.
Bug: 63150
Change-Id: Ifc034d4c7861905e382c42dc22585f0cd2beaf3f
Always include redirects. Search results are worse without them
and MWSearch has never respected this option anyway.
Change-Id: I0ebe321a3b14e7960aa98e3225dc5a19ba916e7d
* Moved ApiRunJobs to a special page instead of going through
ApiMain and having to fight the logic there. As a separate
internal API, this does not show up on the API help page and
is no longer effected by $wgEnableAPI.
bug: 62233
Change-Id: I1db6f526d02e130a66ee03289858a734d89e6c00
list=logevents&leaction has param values with *, which gets bold, when
there was two of them in the same line.
Bug: 61834
Change-Id: Idace9afd4f3a2dce9be539b209a02fa318df8f45
The immediate impetus behind this change is this series of events:
1. CirrusSearch hooks ApiBeforeMain to handle some setup that requires
the User object.
2. So User is loaded from the session.
3. OAuth checks the headers as part of loading User.
4. OAuth sees that the headers are invalid, and since it was called from
the API it throws a UsageException, expecting the API to catch it and
return an appropriate response to the client.
5. But nothing does so, leading to an unhelpful "Internal Error" page
being returned to the client.
We can do better than that.
Bug: 62312
Change-Id: Ib5735661eec6ebe57eaa69c67b399e703cc90fc4
I should have done it at the beginning instead of trying to
extract it from recent changes.
Same for SpecialRecentChanges and SpecialRecentChangesLinked
(subclasses).
Created a new API module for it: ApiFeedRecentChanges.
It's somewhat un-API-like and hackish, but all feed modules are.
Old URLs redirect to new ones, so this should be fully
backwards-compatible assuming sane feed reader clients.
Change-Id: I06ee0f01d896bc66545a1800b24693ce7524e433
They just end up being used for direct support requests that should
really be done on public mailing lists etc
Change-Id: If704ec8dff5fc4669165b580290cc29cf953a25b
The documentation of leaction= shows actions like "thanks/*", at the
moment this will result in a search for log_action='*', which is always
a empty list.
Changing the validation of param leaction to allow specific any string
for the asterisk in this wildcard action.
Change-Id: Ia77e499909ce6f25ce74617367fc5b622ea9a7c9
When prop=userid is requested, we need the rc_user field; when prop=user
is requested, we need both rc_user and rc_user_text.
But for some reason when only prop=userid is requested the code is
requesting only rc_user_text and not rc_user. Fix that.
Bug: 62301
Change-Id: I86f1f35ebd18e45335cdf43ab3ba0a3e9b0e06b4
Getting api connection before the connection is set to the named
connection and store it in a local var to use it later.
Same comment as in Special:Contributions
Bug: 61982
Change-Id: Ia66c4a65a24876e2a528034e8e003aa535e6b689
* Add newOnly option to Special:Contributions
* Add to i18n files
* Add ucshow={new,!new,top,!top} to list=usercontribs
* Deprecated 'uctoponly' in favor of ucshow=top per Anomie.
* Add param 'newonly' to API action=feedcontributions
* Implementation: rev_parent_id=0
Bug: 42026
Change-Id: I07d597ef378d897690097804bf7c774fdadb654c
* A background internal HTTP request used to load the API.
This handles job execution and related periodic tasks.
It avoids blocking the main request or breaking it on fatals.
* This method avoids problems that shelling could have:
** Mismatched apache/cli PHP config or versions.
** Had to start a new process and could not use opcode cache.
** safe_mode and open_basedir restrictions required a fallback.
** Some wiki farms may not respect the --wiki parameter.
** wgMaxShellMemory applies to spawned PHP processes.
** Spawning processes is more prone to DOS due to a lack
of proper limiting/pooling.
bug: 60208
bug: 60210
bug: 60698
bug: 60844
Change-Id: I78b0e709301ac4a0c7b7ed337d6969d7546674bf
Per Sean Pringle:
> In all cases the STRAIGHT_JOIN forces an index scan on logging.times
> index, or more rarely a range access on logging.type_time index. Both
> query plans hit tens of millions of rows and take many minutes.
>
> Removing the STRAIGHT_JOIN allows the MariaDB query optimizer to
> choose a plan that takes seconds. Often it includes a filesort step,
> but more importantly it allows "index condition pushdown" which makes
> the filesort cheap.
Bug: 61889
Change-Id: Iad3905f29a2bdee1e3ebbfb2e1909b330faa8e81
While redirects can be sort-of queried using list=backlinks with
blfilterredir=redirects, we can get more accurate results with a module
dedicated to this purpose. We can also get the fragment of the redirect
without having to load the content of the redirect page and parse it.
I'm a bit surprised I was able to put together a query for this that
will work as a prop module. Or did I overlook something?
And then we may as well add the corresponding list=allredirects, to work
like alllinks, allfileusages, and alltransclusions.
Bug: 57057
Change-Id: I81082aa9e4e3a3b2c66cc4f9970a97eed83a6a4f
possible errors for requireMaxOneParameter are generated with getRequireMaxOneParameterErrorMessages,
not getRequireOnlyOneParameterErrorMessages
Change-Id: Ia3d705ddf2f2d969b3112962a13f27dc9a106037
