Anomie added a comment.
In T132676#6575067 <https://phabricator.wikimedia.org/T132676#6575067>, @Mpaa
wrote:
> @Anomie is base64 encode supported by api action=upload?
Not in itself, but you can use MIME's Content-Transfer-Encoding to encode the
data as base64 rather th
Anomie added a comment.
In T249705#6040712 <https://phabricator.wikimedia.org/T249705#6040712>,
@ssastry wrote:
> - also shows a bunch of errors on April 6th around 1500 UTC (before the
current train rollout to group 0)
Also I see it continues to occur on 1.35.0-wmf.26,
Anomie removed projects: Core Platform Team, MediaWiki-API.
TASK DETAIL
https://phabricator.wikimedia.org/T249705
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Anomie
Cc: Aklapper, pywikibot-bugs-list, Dvorapa, Zkhalido, Viztor, Wenyi, Tbscho
Anomie added a comment.
No need IMO. T145545 <https://phabricator.wikimedia.org/T145545> exists for
the WMF side of things.
TASK DETAIL
https://phabricator.wikimedia.org/T224712
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Dvorapa, Ano
Anomie added a comment.
In general, Wikimedia should probably figure out some way to reconfigure
things so it doesn't wind up trying to set both cookies with
domain=.wikisource.org and domainless cookies for wikisource.org. It's probably
best to use T145545 <ht
Anomie added a comment.
In T224712#6019636 <https://phabricator.wikimedia.org/T224712#6019636>,
@Dvorapa wrote:
> When you/Pywikibot interact with any wiki, you only have one centralauth
session cookie. But when you visit wikisource.org after you visited
*.wikisource.org
Anomie added a comment.
It's hard to copy-paste from screenshots... Hopefully the OCR doesn't mangle
things too badly.
In T224712#6018928 <https://phabricator.wikimedia.org/T224712#6018928>,
@Urbanecm wrote:
> F31719968: image.png <https://phabricator.wikimedia.o
Anomie removed a project: Core Platform Team Workboards (Clinic Duty Team).
Anomie added a comment.
Where is this news? All I see is a giant paste showing pywikibot caught in
some sort of loop. I see no MediaWiki requests/responses that claim to be
showing incorrect behavior.
TASK DETAIL
Anomie removed a project: Core Platform Team.
TASK DETAIL
https://phabricator.wikimedia.org/T130911
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Xqt, Anomie
Cc: alanajjar, Meno25, Anomie, Dvorapa, jayvdb, gerritbot, Aklapper, Xqt,
pywikibot-bugs
Anomie added a comment.
In T224712#5920305 <https://phabricator.wikimedia.org/T224712#5920305>,
@Dvorapa wrote:
> @Anomie @Jdforrester-WMF I broke Pywikibot login loop and found out the
issue with zh.wikisource.org. It seems API sometimes reacts weirdly to
action=login
Anomie moved this task from Waiting for Review to Done on the Core Platform
Team Workboards (Clinic Duty Team) board.
Anomie added a comment.
In T224712#5913343 <https://phabricator.wikimedia.org/T224712#5913343>,
@Dvorapa wrote:
> Beta Cluster is fixed, but st
Anomie moved this task from Unsorted to Needs details or plan on the
MediaWiki-API board.
Anomie edited projects, added Core Platform Team Workboards (Clinic Duty Team),
DBA; removed Core Platform Team.
Anomie added a comment.
The query in question is
SELECT
rc_id,rc_timestamp
Anomie moved this task from Unsorted to Non-core-API stuff on the MediaWiki-API
board.
Anomie added a comment.
This seems unlikely to be anything to do with the API itself. More likely for
these symptoms is some failure in the session storage or in the client's cookie
handling.
I can't
Anomie removed projects: MediaWiki-API, Core Platform Team.
Anomie added a comment.
> Pywikibot is using POST and not GET, but it fails the same. Most recent
attempt resulted in
>
>
{"error":{"code":"internal_api_error_WMFTimeoutException",&qu
Anomie closed this task as "Resolved".
TASK DETAIL
https://phabricator.wikimedia.org/T232672
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Anomie
Cc: Xqt, Anomie, Aklapper, Zoranzoki21, pywikibot-bugs-list, WDoranWMF,
holger.knust, Eva
Anomie added a comment.
I don't know of a way to force such errors on Wikimedia sites, as any way of
doing so would be considered a bug that we would want to fix. I suppose you
could see if there are any open tasks in Phabricator with reproducible test
cases.
If you have your own wiki
Anomie added a comment.
In T210657#4785525 <https://phabricator.wikimedia.org/T210657#4785525>,
@Anomie wrote:
> In T210657#4784221 <https://phabricator.wikimedia.org/T210657#4784221>,
@Xqt wrote:
>
>> Is that really right? Can’t see any changes for the co
Anomie closed subtask T242537: A lot of wikisource interwikimap urls are
redirected as Declined.
TASK DETAIL
https://phabricator.wikimedia.org/T241413
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Anomie
Cc: Aklapper, Dvorapa, Liuxinyu970226, Xqt
Anomie removed projects: MediaWiki-API, Core Platform Team.
Anomie added a comment.
In T238992#5791159 <https://phabricator.wikimedia.org/T238992#5791159>, @Mpaa
wrote:
> Because it is not exposed by mediawiki API, afaik.
The core API is not in the business of parsing
Anomie claimed this task.
TASK DETAIL
https://phabricator.wikimedia.org/T232672
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Anomie
Cc: Xqt, Anomie, Aklapper, Zoranzoki21, pywikibot-bugs-list, WDoranWMF,
holger.knust, EvanProdromou, DannyS712
Anomie added a comment.
Any image with a version showing "No thumbnail" will probably give you the
response described in this task. It's not necessary to give more examples of
the same.
The inability to delete that file is not related to this task, although it
may be an
Anomie edited projects, added Core Platform Team Workboards (Clinic Duty Team);
removed Core Platform Team.
TASK DETAIL
https://phabricator.wikimedia.org/T239213
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Anomie
Cc: Anomie, daniel, mobrovac
Anomie added a comment.
In T239213#5692769 <https://phabricator.wikimedia.org/T239213#5692769>,
@Reedy wrote:
> Though I don't completely agree with the change log of all these things
being "meaningless in this context", especially if the UI is showing some of
t
Anomie added a project: mariadb-optimizer-bug.
Restricted Application added a project: Pywikibot.
TASK DETAIL
https://phabricator.wikimedia.org/T78276
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Anomie
Cc: gerritbot, Anomie, jayvdb, Aklapper
Anomie added a project: mariadb-optimizer-bug.
TASK DETAIL
https://phabricator.wikimedia.org/T220999
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Anomie
Cc: Dalba, Dvorapa, pywikibot-bugs-list, hashar, Xqt, jcrespo, Marostegui,
Aklapper
Anomie added a project: Core Platform Team Workboards (Clinic Duty Team).
TASK DETAIL
https://phabricator.wikimedia.org/T75370
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Xqt, Anomie
Cc: Anomie, IoannisKydonis, AndyTechGuy, Dufferzafar, Aklapper
Anomie moved this task from Needs details or plan to Needs Code on the
MediaWiki-API board.
Anomie added a comment.
So probably the most consistent thing to do here is to pass it through
`Title::newFromText( $value, NS_USER )` (then get the IP back out with
`->getText()`), like `U
Anomie updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T232672
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Anomie
Cc: Anomie, Aklapper, Zoranzoki21, pywikibot-bugs-list, WDoranWMF,
holger.knust, EvanProdromou, Viztor
Anomie updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T232672
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Anomie
Cc: Anomie, Aklapper, Zoranzoki21, pywikibot-bugs-list, WDoranWMF,
holger.knust, EvanProdromou, Viztor
Anomie updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T232672
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Anomie
Cc: Anomie, Aklapper, Zoranzoki21, pywikibot-bugs-list, WDoranWMF,
holger.knust, EvanProdromou, Viztor
Anomie renamed this task from "API error baduser_rcuser in pywikibot (not for
all IP addresses)" to "API does not strip bidi characters (or trim whitespace)
when validating IPs for 'user'-type parameters".
TASK DETAIL
https://phabricator.wikimedia.org/T232672
EMAIL
Anomie moved this task from Unsorted to Needs details or plan on the
MediaWiki-API board.
Anomie added a comment.
> kizule@kizule:~/development/pywikibot-core$ python3 pwb.py patrol
-usercontribs:'213.149.159.237' -ask
The value you're passing there is not just an IP address. I
Anomie added a comment.
What do you do now, without BotPasswords? Have your test account have the
same password everywhere?
TASK DETAIL
https://phabricator.wikimedia.org/T137805
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Anomie
Cc
Anomie closed this task as a duplicate of T220999: Slow query
ApiQueryLogEvents::execute after actor rollout.
TASK DETAIL
https://phabricator.wikimedia.org/T221543
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Anomie
Cc: hashar, Aklapper
Anomie merged a task: T221543: Travis test fails for wikidata:wikidata site.
Anomie added subscribers: Xqt, hashar, pywikibot-bugs-list, Dvorapa, Dalba.
TASK DETAIL
https://phabricator.wikimedia.org/T220999
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences
Anomie added a comment.
From the MediaWiki perspective, this is a duplicate of T220999: Slow query
"ApiQueryLogEvents::execute" after actor rollout
<https://phabricator.wikimedia.org/T220999>, which should roll out with the
train next week unless someone backports it on
Anomie moved this task from Unsorted to Non-core-API stuff on the MediaWiki-API
board.
Anomie added a comment.
> @Dvorapa added a project: #MediaWiki-API
<https://phabricator.wikimedia.org/tag/mediawiki-api/>.
What exactly do you think is a bug in the API here? Plea
Anomie added a comment.
Note the fix should be deployed to Wikimedia wikis with 1.33.0-wmf.12, see https://www.mediawiki.org/wiki/MediaWiki_1.33/Roadmap for a schedule.TASK DETAILhttps://phabricator.wikimedia.org/T212356EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel
Anomie added projects: MW-1.32-release, Regression.Anomie added a comment.
Marking as a regression and blocking the 1.32 release.TASK DETAILhttps://phabricator.wikimedia.org/T212356EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AnomieCc: Anomie, Zoranzoki21
Anomie added a comment.
In T210657#4784221, @Xqt wrote:
Is that really right? Can’t see any changes for the code but it was announced that it will be just “internal_api_error”
The code is not changing yet in 1.33.0-wmf.8, so we can avoid breaking your existing code that's looking
Anomie added a comment.
Getting a better estimate for Retry-After is T172293. This doesn't seem to really be a bug other than that existing feature request.TASK DETAILhttps://phabricator.wikimedia.org/T210606EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences
Anomie moved this task from Unsorted to Needs details or plan on the MediaWiki-API board.Anomie added a comment.
I'm not sure there's really an API bug here. Pages that exist aren't supposed to be able to be create-protected, and create-protection on such pages doesn't do anything, so the API
Anomie added a comment.
Ah, that explains it. They apparently forgot to run maintenance/namespaceDupes.php after adding the namespace.TASK DETAILhttps://phabricator.wikimedia.org/T198721EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AnomieCc: JJMC89
Anomie added a comment.
The page "Draft:Testing AFCH" in the "Draft talk" namespace does not exist. But that's not what's being returned here.
The page "Draft talk:Draft:Testing AFCH" in the main namespace does exist, presumably due to some bug around July 2015 wh
Anomie added a comment.
In T194950#4322078, @Magnus wrote:
maxlag does not appear to be documented for the query action...
That's because it's a parameter to the "main" module, not the query action.TASK DETAILhttps://phabricator.wikimedia.org/T194950EMAIL PREFER
Anomie added a comment.
Looks like a duplicate of T101400: This result was truncated because it would otherwise be larger than the limit of 12,582,912 bytes
.TASK DETAILhttps://phabricator.wikimedia.org/T195992EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences
Anomie added a comment.
In T194233#4199135, @zhuyifei1999 wrote:
@Anomie While testing how batchcomplete interacts with pageid, I tested the same query for File:Example.jpg on commons, which contains many redirects and multiple file revisions, but I got batchcomplete with only a single imageinfo
Anomie added a comment.
In T194233#4198809, @zhuyifei1999 wrote:
Merging until 'batchcomplete' is not realistic if a certain generator yields too many results
No, batchcomplete is specifically designed to do the right thing with generators.
If you were to complain about prop=transcludedin
Anomie added a comment.
prop=imageinfo is showing the data for the image associated with File:1979-80 National Football League (Ireland) final.jpg. MediaWiki's logic for finding "the image associated with a title" follows redirects behinds the scenes.
So what happens here at the
Anomie added a comment.
In T154324#4163280, @MarcoAurelio wrote:
In T154324#2907447, @Anomie wrote:
Is there a reason you need to do this?
I find myself sometimes in need to use the delete.py script using my sysop account, and I keep logged it on the web sesion because I want to check what I
Anomie added a comment.
If you fail 3 logins on a WMF wiki, I believe it'll send a captcha for additional attempts from that IP or username.
If you set up your own wiki to test things on, you can configure things however you like.TASK DETAILhttps://phabricator.wikimedia.org/T186274EMAIL
Anomie added a comment.
ApiQueryQueryPage does not support additional parameters that a random query page might use. That includes the "namespace" parameter being used there.
If you're willing to ignore an "Unrecognized parameter: namespace." warning, it does seem to cu
Anomie closed this task as "Resolved".Anomie added a comment.
The fix should be deployed with 1.30.0-wmf.11, see https://www.mediawiki.org/wiki/MediaWiki_1.30/Roadmap for the schedule.
If it's needed faster, feel free to submit it for SWAT.TASK DETAILhttps://phabricator.wikimedia.org/T1
Anomie claimed this task.
TASK DETAILhttps://phabricator.wikimedia.org/T171416EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AnomieCc: gerritbot, Dalba, Anomie, Aklapper, pywikibot-bugs-list, JJMC89, Lordiis, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, Magul
Anomie added a project: MediaWiki-API.Anomie added a comment.
It's a bug in the API, due to the fact that PHP's ternary operator is stupidly left-associative.TASK DETAILhttps://phabricator.wikimedia.org/T171416EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences
Anomie added a comment.
To clarify: Both assert=user and assertuser=NAME will prevent logged-out edits. assertuser=NAME will also prevent edits if somehow logged in as any user other than NAME, which is useful in UI _javascript_ in case the user re-logs-in to a different account in a different
Anomie added a comment.
Off the top of my head, I can think of two ways pywikibot might be affected here:
It's possible a script might break when ordering by timestamp rather than revid, in the cases where the ordering differs thanks to imports or the like.
The revid supplied now must exist
Anomie added a comment.
If you're asking me, this isn't on my priority list. The code change itself is #Easy, just add
public function isReadMode() {
// Nothing sensitive here
return false;
}
to ApiQueryUserInfo. The part that's work is running that past Security to verify
Anomie closed this task as "Resolved".Anomie claimed this task.
TASK DETAILhttps://phabricator.wikimedia.org/T41492EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AnomieCc: gerritbot, Aklapper, Nemo_bis, pywikibot-bugs-list, jayvdb, Magioladiti
Anomie added a comment.
FYI, the warning you report ("Fetching a token via action="" is deprecated. Use action="" instead.") doesn't actually have anything to do with BotPasswords.
I note that site is serving a "login_session" cookie with the 'secure' fla
Anomie added a comment.
It adds another warning when a deprecation warning is already being output, so if you're trying to ignore all deprecation warnings you'd have to ignore this warning too. I hope you're not hiding deprecation warnings, though.
It also changes the "See URL for usage.&
Anomie added a comment.
MediaWiki API provide some sort of dummy output
Not going to happen.
But there's probably no reason that meta=userinfo should require the 'read' right, I don't see anything in there that seems like it needs that right. If someone wants to go that route, you'd run the idea
Anomie added a comment.
The error Unrecognized value for parameter "meta": wikibase. indicates that the bot is including meta=wikibase in the request to action=""> but the wiki does not have a meta module by that name. You can check the modules available for the m
Anomie added a comment.
As I said, if you believe it's in the API then show me API queries that are not doing what they're supposed to be doing rather than quoting some random pywikibot script. Without that there's nothing I can do here.TASK DETAILhttps://phabricator.wikimedia.org/T155293EMAIL
Anomie removed a project: MediaWiki-API.Anomie added a comment.
There does not seem to be anything here for #MediaWiki-API. If you identify actual queries to api.php that are not behaving as expected due to errors in the API, rather than vague issues that might be in pywikibot or CirrusSearch
Anomie closed subtask T154663: Some of the search results sometimes don't show up as "Invalid".
TASK DETAILhttps://phabricator.wikimedia.org/T151369EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Magul, AnomieCc: Lokal_Profil, Xqt, jayvdb, Dalba,
Anomie added a comment.
In T137805#2778915, @MaxBioHazard wrote:
When the old login method will be turned off?
There are currently no plans to turn it off. However, if something makes the "main account" login process require anything beyond the submission of a username and pass
Anomie added a comment.
In T142155#2530987, @Tgr wrote:
I'll leave it to @Anomie to decide whether two months is an acceptable delay (once he is back from vacation).
No, it's not acceptable. I already gave them seven months as part of the documented deprecation process for the API. But I
Anomie closed subtask T50824: Creating a page in category namespace does not insert row in category table. as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T67149EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Mpaa, AnomieCc: Ri
Anomie added a comment.
In https://phabricator.wikimedia.org/T130915#2154997, @Xqt wrote:
> @Anomie Why have these pages a namespace 105 property if this ns does no
longer exist?
As far as MediaWiki is concerned, a namespace is just a semi-arbitrary number
and any number &quo
Anomie closed this task as "Invalid".
Anomie added a comment.
I note that particular page actually //is// a redirect. But it's this page
<https://ar.wikipedia.org/w/index.php?curid=2677629> in namespace number 105,
not the page in namespace 0
<https://ar.wikipedia.org/w
Anomie added a comment.
You're assuming that it's incorrect for it to be exposed. That is far from
evident here, it could well be that the bug was that it wasn't being listed
before when it should have been, and something recently accidentally fixed that.
TASK DETAIL
https
Anomie changed Security from None to Software security bug.
TASK DETAIL
https://phabricator.wikimedia.org/T130099
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Anomie
Cc: valhallasw, Anomie, Aklapper, Xqt, pywikibot-bugs-list, dg711, jayvdb
Anomie added a comment.
In https://phabricator.wikimedia.org/T130099#2128902, @Xqt wrote:
> >>> pdc.content[:50]
>u'\n\n >>>
>
It would be nice for that to be expanded upon. There might be useful
information in there as to what exactly
Anomie added a comment.
To start, it would help if you would provide the actual URL being hit (and
POST data, if applicable) and the actual response received. Accessing
pdc.wikipedia.org seems to work fine when I try it:
$ curl
'https://pdc.wikipedia.org/w/api.php?action=query
Anomie moved this task to Needs details or plan on the MediaWiki-API workboard.
TASK DETAIL
https://phabricator.wikimedia.org/T130099
WORKBOARD
https://phabricator.wikimedia.org/project/board/200/
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences
Anomie added a comment.
The thing being complained about here is the list of accepted values to the
`contentformats` parameter to `action=edit`. This list of possible values is
fetched from `ContentHandler::getAllContentFormats()`, which queries every
handler in `$wgContentHandlers
Anomie moved this task to Non-core-API stuff on the MediaWiki-API workboard.
TASK DETAIL
https://phabricator.wikimedia.org/T129281
WORKBOARD
https://phabricator.wikimedia.org/project/board/200/
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences
Anomie moved this task to Non-core-API stuff on the MediaWiki-API workboard.
TASK DETAIL
https://phabricator.wikimedia.org/T119316
WORKBOARD
https://phabricator.wikimedia.org/project/board/200/
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences
Anomie added a subscriber: Anomie.
Anomie added a comment.
In https://phabricator.wikimedia.org/T119316#1865521, @jayvdb wrote:
> `SearchPageGenerator` uses API search
> <https://www.mediawiki.org/wiki/API:Search>.
>
> I see File pages from Commons appearing when
Anomie added a subscriber: Anomie.
Anomie closed this task as "Resolved".
Anomie claimed this task.
Anomie added a comment.
It would be helpful if your test runner were to include more timestamps. Since
a later timestamp in the log (line 2120) is 2015-10-05 23:39:33 this is very
lik
Anomie closed this task as "Invalid".
Anomie claimed this task.
Anomie added a comment.
See explanation of what's going on here in
https://phabricator.wikimedia.org/T112405#1637544. The short version is that
your first chunk's upload isn't actually succeeding.
TASK DETA
Anomie moved this task to Non-core-API stuff on the MediaWiki-API workboard.
TASK DETAIL
https://phabricator.wikimedia.org/T111479
WORKBOARD
https://phabricator.wikimedia.org/project/board/200/
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences
Anomie added subscribers: ori, Anomie.
Anomie added a project: Performance.
Anomie added a comment.
After digging deep into this issue, the slowness for Arabic-language wikis
compared to other languages is because LanguageAr::normalize() is relatively
slow, multiplied by almost 10 calls
Anomie closed this task as Resolved.
Anomie added a comment.
The part of this bug that isn't https://phabricator.wikimedia.org/T97797 should
be fixed now, although if the DB people have anything to add it would still be
welcome.
TASK DETAIL
https://phabricator.wikimedia.org/T78276
EMAIL
Anomie moved this task to Non-core-API stuff on the MediaWiki-API workboard.
TASK DETAIL
https://phabricator.wikimedia.org/T109929
WORKBOARD
https://phabricator.wikimedia.org/project/board/200/
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Joe
Anomie added a comment.
@Joe: FYI, you should be able to grep for 'Call to a member function getNames()
on a non-object (NULL)' in /a/mw-log/exception.log on fluorine if you need to
look for instances of this issue. The log lines include the host, wiki
(dbname), and query.
TASK DETAIL
Anomie moved this task to Needs Review on the MediaWiki-API workboard.
TASK DETAIL
https://phabricator.wikimedia.org/T78276
WORKBOARD
https://phabricator.wikimedia.org/project/board/200/
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Anomie
Cc
Anomie added a project: Database.
Anomie added a comment.
Wikidata is https://phabricator.wikimedia.org/T97797.
As for the rest, I'm seeing some weirdness in the database.
The query here is
SELECT /*! STRAIGHT_JOIN */
page_namespace,page_title,page_id,page_content_model FROM `page
Anomie added a subscriber: Anomie.
Anomie added a comment.
I could reproduce this by directing copies of the erroring queries to mw1230,
mw1147, and mw1200; it didn't happen with the same queries directed to
different hosts. Nothing in the code looks suspect.
I tried using some live hacks
Anomie moved this task to Non-core-API stuff on the MediaWiki-API workboard.
TASK DETAIL
https://phabricator.wikimedia.org/T108322
WORKBOARD
https://phabricator.wikimedia.org/project/board/200/
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences
Anomie added a subscriber: Anomie.
Anomie added a comment.
Finally, IMO MediaWiki paraminfo API should also better handle when a broken
module is loaded to the live wiki, instead of 503 being considered an
appropriate API response.
The API should be able to assume that extensions don't
Anomie moved this task to Needs plan on the MediaWiki-API workboard.
TASK DETAIL
https://phabricator.wikimedia.org/T108322
WORKBOARD
https://phabricator.wikimedia.org/project/board/200/
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Anomie
Cc
Anomie added a comment.
In https://phabricator.wikimedia.org/T101502#1396381, @jcrespo wrote:
Can someone with a full understanding of the code provide a smallish, but
very representative list of different queries that could be generated from
that piece of code (different namespaces
94 matches
Mail list logo
