This is some kind of PageViewInfo bug that's somehow related to API continuation (continuation is incorrectly triggered in the pageviewinfo module, even for very small result sets like 10 pages).
I can look into it tomorrow, or we could hack around it temporarily by using pageviews data from the RESTBase/PCS summary endpoint instead.
Also, we use raw numbers here, right? That could be up to 9 characters (million + two separators) for very popular pages.
Ehhh right, that works for pageviews but not for uniques. I should probably recondsider that.
I didn't bother adding monthly metrics support to PageViewInfo because that's just daily data summed up in batches of 30 (or it can be aligned to calendar months if someone particularly cares; in any case, monthly data is contained in daily data). For hourly, I just doubted there'd be much need for it.
@RHo Kosta pointed out elsewhere that the design is similar to the drawer component of MobileFrontend, but when the MF drawer is open, the rest of the page is dimmed (and inaccessible) but in the mockup here the top navigation bar is still accessible. Would it be OK to use the standard drawer UX? Dimming only parts of the page might be complicated even if we use a custom component, and it would be nice to avoid the code duplication.
Thanks a lot!
We discussed this in the standup, but for the record, the code should alternate exactly, if it doesn't, that's a bug; but given that loading the next card can be slow and the navigation arrows are not disabled while the card loads, it's currently easy to accidentally skip tasks.
(Also, for now we filter out protected pages on the client side, so whenever that happens, there will be a gap, ie A followed by C. But that should be rare, affected something like 1% of the tasks in my tests. Eventually we'll probably move filtering to the server side and the issue will disappear, but it's considered low priority.)
The steps are:
- user starts off at #/homepage/start, clicking on the Done button of the intro overlay (screenshot )
- dialog closes, exposing the start module detail view (without suggested edits) (screenshot , first flash)
- page reloads and at the same time navigates to #/homepage/suggested-edits
- while the JS spins up, user sees the server-side rendered page (fragment URL gets ignored), which is like #2 but with the suggested edits related changes (one less start module sub-item etc) (screenshot , second flash)
- JS overlays the suggested edits overlay, which is in the server-side rendered HTML but hidden by default (third flash)
- suggested edits overlay loads the first task suggestion card (fourth "flash" although this one is less jarring)
I think the architectural constraints are:
- we don't want to maintain the HTML structure in two different places (both client and server side)
- we don't want to keep that structure in different places for different modules
- we don't want to move it to the client side for all modules (eventually, maybe, but not now)
I will wait a day just in case something went wrong, then repeat with kowiki.
Seems to be defunct most of the time these days. E.g. notifications for GrowthExperiments pretty consistently don't work, none of the core patches I checked work...
Mon, Nov 18
A PHP RFC has been accepted to implement the WHATWG Living Standard DOM as an extension in PHP 8.0.
Sun, Nov 17
Fri, Nov 15
Wed, Nov 13
One cluster of things that seems like low hanging fruit (useful and easy to do without dedicated staff time) is conventions for Gerrit / wiki sync:
- Introduce a norm of linking to all affected documentation pages from gerrit changesets
- Have a maintenance template for tracking pages which will be affected by a pending patch
- Maybe make a parser function for telling whether a patch is still pending (more effort but still not crazy to have it as community-maintained code)
- alternatively as a poor man's version use Tool-extjsonuploader and Lua tables for syncing that data
Mon, Nov 11
Yes but I don't know if I have restarted the vagrant box since then, and apart from the error during vagrant up I never saw any obvious effect in the first place. vagrant reload does work fine now.
Sun, Nov 10
I thought Parsoid/PHP is not using RESTBase?
Turns out HitCounters works fine despite the warning.
Matomo has a manual web-based installer and doesn't really support automated installs (that's in their paid version AIUI). In theory it's not super hard, just generate a config file and set up the database (they don't provide an SQL file or anything, but we can just snapshot the result of the manual setup I guess).
Fixed via sudo chown -R mwvagrant:wikidev cache/ (outside vagrant). No idea what caused it; oh well.
Sat, Nov 9
Wikispore does not run on the normal Wikimedia infrastructure.
Note that this probably involves a lot more than just installing the Wikibase extension; we want to be able to be a client of wikidata.org, but currently Wikibase Client does not support repositories which it does not have direct database access to. T209880: [Investigation - 8h] technical overview of current db based Wikibase federation & blockers to get to an API based federation has some information on the topic.
The first attempt at this failed: wikispore-test has VE but existing content is not preserved (probably RESTBase is broken).
Vagrant seems to be in the middle of a Node migration (for some value of migration: some roles refuse to work without Node 10, some are still on Node 6; cf. T217113: MediaWiki-Vagrant should use the same Node.js version as Wikimedia production) which is probably one of the issues (maybe *the* issue).
Our plan to do the same for Wikispore is to use the OAuthAuthentication extension (T110460: Update OAuthAuthentication to use AuthManager needs to be finished first). Depending on how much of T197969: User registration tasks you want to coexist with OAuth-based identities, that might or might not be the right solution for you.
Seems like there's a lot of overlap with the Wikispore project! We should talk some time.
An example in English (and screenshots for posteriority): https://dev.tietokide.fi/?Q10
I note Extension:PubSubHubbubSubscriber was not archived; is that meaningful on its own?
I think in this task we are looking for a template that links to a wikidata page given as a parameter, not one that pulls data from a linked Wikidata item (Wikispore is not yet set up to do that, and I don't think Wikidata even supports it currently).
This is blocked on T231899: Wikidata property, right?
No property yet, but there's an item: Q67605965
Proposal is at https://meta.wikimedia.org/wiki/Talk:Interwiki_map#Wikispore.
We have a [https://gerrit.wikimedia.org/r/c/mediawiki/vagrant/+/546156 Vagrant customization], a runbook for using it and two wikis (wikispore and wikispore-test) running on it. Marking as done.
Fri, Nov 8
A vagrant reload made the error go away. Oh well. A mystery for another day.
Thu, Nov 7
I can replace B with billion etc, I'm sure that will be weird in some languages but still less bad than hardcoding.
JSON pages can be edited by sysops and interface editors as well, so in that case we should have a task about restricting it.
Wed, Nov 6
Apologies for mass-subscribing you; the name list is a combination of database queries for the most prolific gadget and module editors, and personal recollections about who had good insights about the topic. We would really value your feedback for TechConf 2019 in how the people working on developer productivity could help you with making your gadget or Lua module development work more productive. If you are not interested, I apologize for the spam, feel free to unsubscribe. (In case you are less familiar with Phabricator: the unsubscribe link is in the right-hand sidebar column.) If you are interested, please see the description of this task for the feedback format. (We are very interested in any other feedback too, but would like to have a uniform set of responses that the conference participants can work with.)
I created a subtask for collecting the answers (hopefully helps with reducing the comment notification spam in both directions): T237490: Collect feedback from module and gadget authors for Developer Productivity & onwiki tooling techconf session
Eventually should probably move protected status check to the server side (and ideally to ElasticSearch).
In the short term, probably just fetch 250 tasks and use the extra 50 as a reserve to replace protected articles?
tgr@mwmaint1002:~$ mwscript extensions/GrowthExperiments/maintenance/deleteOldSurveys.php testwiki --cutoff 350 --verbose --dry-run Deleting data before 20181121014408 (over 350 days old) (dry run) Skipping user:27425, past-cutoff survey submit date 20190607131714 Skipping user:29950, past-cutoff survey submit date 20190724014701 Skipping user:30833, past-cutoff survey submit date 20190918212454 Skipping user:39901, past-cutoff survey submit date 20190607172958 Skipping user:40269, past-cutoff survey submit date 20190709193716 Deleting survey data for user:41446 Deleting survey data for user:41447 Deleting survey data for user:41448 Deleting survey data for user:41449 Deleting survey data for user:41450 Deleting survey data for user:41462 Stopping at user:41467 which has past-cutoff registration date 20181121105317 Processed users up to ID 41467 Deleted: 6, skipped: 5
27425 -> Etonkovidova 29950 -> Zilant18 30833 -> Zilant1 39901 -> MMiller (WMF) 40269 -> KHarlan (WMF) 41446 -> Zilant22 41446 -> Zilant22 41447 -> Roantest44 41448 -> Zilant23 41449 -> Jindrat 41450 -> Jindrad 41462 -> Nov-20-2018-test-account-to-suppress
That seems reasonable.
Well, a bot has been written with very much the same mindset.
Pageview counts are not displayed, even though that should work in theory. Something to look into eventually, but very minor.
Also, URLs have been added recently to the config; make sure those are safe.