Fri, Apr 19
I tested this and it works quite nicely. Moving to Done.
I did a rudimentary test on this and it seems to work fine.
I took a look at the new tasks that Max created and it looks like a good start to dig through the first layer of issues with the service.
Thu, Apr 18
This is now invalid. The result of the "invert" isn't high enough fidelity for what we want. We should strive towards something more like what the mobile app does. Maybe we can learn from their code?
We should start with Test. Once it has a feature flag and is fully deployed, enabling/disabling on any wiki is a trivial SWAT deploy of the config change.
Wed, Apr 17
I can confirm Leon's experience. I'm looking at this now.
Tue, Apr 16
@MaxSem I might be able to take a look at this one.
That sounds like a good move to me! Thanks.
Thanks for planning this out @Tchanders.
Thanks. Max did notice that the cron jobs on staging were not configured correctly. That could have contributed to some of the confusion around what was going on with this. I don't think we can consider it complete though.
Mon, Apr 15
It could definitely be misleading. Maybe something like "No matching blocks found..." is even more exact?
Approved and merged. Didn't seem like this needed QA really.
Fri, Apr 12
I vaguely remember us discussing this and recognizing it as a limitation of the tool which we weren't prepared to tackle yet.
It makes sense to me. Maybe we consider it fixed. If it comes back, we can reopen or have a new task.
Thu, Apr 11
@Krinkle This patch should ensure that the coordinates are numeric, either positive or negative. The only change here, from production, is to allow negative coordinates. This modifies Ed's patch which came after your revert.
I've amended https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ImageMap/+/502888 to completely allow negative coordinates.
Wed, Apr 10
Based on the patch and its commit message, I believe the author was following the same logic as is used for the coordinates in a circle or rectangle map. Whatever the spec, I think we can agree that negative coordinates aren't logical in the coordinate system used for polygonal image maps.
@Cirdan Do you have any examples? I'm looking at https://de.wikipedia.org/wiki/Baden-W%C3%BCrttemberg and https://de.wikipedia.org/wiki/Bayern and https://de.wikipedia.org/wiki/Berlin which seem fine.
Nice. It's a bummer we can't install it but I'm glad we didn't have to delve into a bunch of parsing issues.
Tue, Apr 9
It sounds like there's not a lot of consensus with this pattern (correct my assumption here if I've misread the other conversations) so I think we should leave the name as it is.
@jmatazzoni Seems like was resolved for the time being.
Mon, Apr 8
Duplicate of T193814. I moved relevant content to that task.
Should we make a different task to make this run by cron jobs? Seems like we should as this was a spike. I think that this cron job work plus the async pageview work are the two priority things we should work on right now.
Dom's point about server load is also true for load across the entire environment, especially the database. When it's higher, we likely have less resources and so things take longer. When they take longer, there's more likelihood for them to fail.
Thu, Apr 4
A prerequisite, T208636, was just +2ed.
@Samwilson is working on a patch to temporarily skip the browser tests which caused this to fail.
This wouldn't replace the existing Mute management fields in Special:Preferences right? It's just a landing page for links from the email/notifications?
Wed, Apr 3
We've decided to focus on making RTL support work correctly in Event Metrics before prioritizing this. That work will be based on T208371 which we did for SVG Translate.
Tue, Apr 2
We will spend ~ 4 hours or less investigating the issue. The possible outcomes of this week are:
I should have a patch shortly.
I think this syntax is correct. I think the issue is that the $usedProjectIds is empty so there's nothing in the SQL clause for the NOT IN () to filter by.
This is interesting. T219935 seems to indicate that the query is now poorly formed instead of just expensive. I'm taking a look to see if I can see an obvious regression.
Case-matching search fooled me again.
Mon, Apr 1
I would be surprised if the process is actually still running. I think the backend systems would likely have killed this process but that isn't being reflected in the UI for some reason.
My apologies to all for this breakage. Thank you to @Krinkle for cleaning up my mess.
Sat, Mar 30
Fri, Mar 29
@dbarratt Could we merge the two tickets as there are some useful examples and detail here?
As best I can tell, both of those reports end up resolving down to PageviewsRepository::getPageviewsPerArticle() for the source of the data.
At first glance, it appears to largely use the same functions which is interesting. I'm taking a closer look.
@Cirdan I apologize for the breakage. There was discussion here about the fact that the old code simply dumped the error into the log and that behavior might be preferable. It seems in the case you mention that it is.
Thu, Mar 28
This fails a bit lower in priority in me as we are overblocking which is the preferable failure case here, IMO. Not that we shouldn't fix it, just that it doesn't feel all that pressing.
A few notes from our meeting with @Tpt:
This has been fixed and merged and should be available for translation soon.
Wed, Mar 27
I don't know how much work this is but I suggest we get the meatier work out of the way first.
Tue, Mar 26
I mentioned this in the other ticket. I wonder if we are hitting some sort of "open file descriptor" limit on NFS.
Let's take a look at the NFS setup on Labs to see if there's some change there which might be the culprit.
@EvanProdromou I think that a solution like that is something closer to what @Joe was proposing than the job queue thing I described. I really like the idea of a capability like this. I'm glad that Giuseppe helped make it clear in his comments.
Mon, Mar 25
@MusikAnimal I made a suggestion on PR16.
Mar 22 2019
I pushed a new patch that works much better and passes Jenkins.
Upon further examination, it's possible this bug only presents for poly maps. There is code to protect against non-numeric coords for rect and circle and default maps.
That patch fails a CI security check with this error: Calling method \Xml::element() in \ImageMap::render that outputs using tainted argument $attribs. (Caused by: Builtin-\Xml::element) (Caused by: ./includes/ImageMap.php +249; ./includes/ImageMap.php +189; ./includes/ImageMap.php +252; ./includes/ImageMap.php +263)
I'm taking a look at this bug. Seemed like an easy one to tackle on a Friday afternoon.
Thanks for the insight @Joe. I appreciate your giving some thought to this.
Mar 21 2019
An on-wiki request and discussion about this is located on the Arabic wiki.