Fri, Feb 17
Thu, Feb 16
Ran into this bug again today on English Wikipedia with Firefox. Below is the HTML of the hovercard while it was stuck. Moving the cursor into and out of the card had no effect. Clicking the page outside the card had no effect. The only way to get it to go away was to open another hovercard.
<div class="mwe-popups mwe-popups-fade-in-down flipped_x_y mwe-popups-is-not-tall" role="tooltip" aria-hidden="false" style="top: 3806.52px; left: 521.567px; display: block;"><div>
I'm assuming that the new refactored code isn't live on English Wikipedia yet. Is that correct?
Wed, Feb 15
Tue, Feb 14
Looks like that did the trick! Thanks!
Created new task at T158097.
@Andrew: I heard you might be able to help with this.
@Niharika: Sounds good to me.
Agree we should keep the "number of pages" field.
Mon, Feb 13
Echo is now live on loginwiki!
@MusikAnimal: That makes sense. It looks like User:PopularPagesBot is available. Let's create a new account and submit it for a BRFA.
@Mattflaschen-WMF: When I tried turning on Echo on loginwiki I got the following error:
A database query error has occurred. Did you forget to run your application's database schema updater after upgrading? Query: SELECT * FROM `echo_event` INNER JOIN `echo_notification` ON ((notification_event=event_id)) INNER JOIN `echo_target_page` ON ((etp_event=event_id)) WHERE event_deleted = '0' AND notification_user = '995' AND notification_read_timestamp IS NULL AND etp_page = '1' Function: EchoEventMapper::fetchUnreadByUserAndPage Error: 1146 Table 'loginwiki.echo_target_page' doesn't exist (10.64.16.18)
echo_target_page doesn't seem to exist on any of the wikis though. Is this a shared table?
It sounds like the consensus is to do an on-wiki config for now. Maybe at User:Mr.Z-bot/PopularPagesConfig? It would be good to set it up under User:Mr.Z-bot since that's the user account it will be running under, at least for now (since it already has the Bot approval).
@jcrespo: The schema has been updated on labsdb1001:
mysql:wikiadmin@labsdb1001 [enwiki]> describe page_assessments_projects; +-------------------+------------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------------------+------------------+------+-----+---------+----------------+ | pap_project_id | int(10) unsigned | NO | PRI | NULL | auto_increment | | pap_project_title | varbinary(255) | YES | UNI | NULL | | | pap_parent_id | int(10) unsigned | YES | | NULL | | +-------------------+------------------+------+-----+---------+----------------+ 3 rows in set (0.01 sec)
@jcrespo: What's the procedure for getting the table updated on Tool Labs?
@Niharika: Added you as a subscriber.
You can just make another wiki send the email, via the job queue.
True, but we'll need to have Echo turned on anyway in order to be able to generate the notification.
Sat, Feb 11
@czar, @Stevietheman, @Framawiki, @Doc_James: Any opinions on what would be better? An on-wiki configuration interface like https://en.wikipedia.org/wiki/User:NKohli_(WMF)/Test1 or a Tool Labs interface like https://tools.wmflabs.org/popularpages/list.php? (Note that either way, we will reuse the existing config data.)
Initial outlook not good :( I tried similar queries that I did with revision and only fetching rc_id, and it didn't seem to be that much faster.
Please post the queries and times if possible. Are you saying that queries using cu_changes for revision data weren't much faster than queries using recentchanges for revision data?
Reading through T97760, it looks like the rationale for not enabling Echo on loginwiki was simply that it wasn't needed there and having fewer extensions meant a smaller attack surface. Now, however, we have a security trade-off. If we don't have Echo on loginwiki, hackers could presumably use that wiki to avoid detection by the LoginNotify Extension.
Since we're about to discuss security issues and attack scenarios, restricting visibility to Security (and existing subscribers).
Fri, Feb 10
Seems to be working now.
I have no objections for what its worth, although I'm not sure what the details are behind it not being enabled in the first place.
No idea. Presumably the assumption was that no one actually used loginwiki (besides the CentralAuth extension), so there was no reason to have Echo there.
Hmm, there are definitely advantages to either approach. Maybe we should stick with a web interface since that's what people are already used to using and it will be less easy for people to break it by entering bad data. There are two existing config tables we can use:
- s51401__pop_data.project_config - The current config data
- s51401__pop_data.config_history - The history of changes to the config
If we use these, at some point we'll need to add columns for the wikis, e.g. 'enwiki', but we can use them how they are for now.
@Samwilson: We should definitely not re-use the existing pageview stat tables. They aren't accurate and don't include mobile views. It will be easier to just use the monthly pageviews API.
Thu, Feb 9
@Sn1per: Are you still working on this? It looks like the task has attracted a bit of scope creep. We should concentrate on tackling the back-end support first and then worry about the front-end UI once we have a working prototype. The prototype could even just use text input fields for now. If you feel like you're stalled, Community Tech would be happy to work on it. Just let me know.
BrowserStack will give you a 30 minute free trial. If you need more than that, I think some of the folks in Reading have accounts we might be able to borrow. Maybe @Jdlrobson knows.