The feature is available to test on https://reading-web-staging.wmflabs.org/

When testing I noticed couple things:

Moving back to doing to address T216152#5125450

@Krinkle thanks for your input. When building Definitions::insertCommunityPortal I found the code that was doing almost the same what I needed. That's how the insertCommunityPortal() was made. I'll check it with Skin::buildSidebar() and update the code.

This task didn't have design review yet, moving it to "Needs design review".

@alexhollender you can verify it here: https://reading-web-staging.wmflabs.org/

@Krinkle we load the MediaWiki:Portal-url, and then verify if title exists -> if the page doesn't exist we do not show the link - https://github.com/wikimedia/mediawiki-skins-MinervaNeue/blob/master/includes/menu/Definitions.php#L323

https://gerrit.wikimedia.org/r/504938 removes The recent changes link from Advanced menu. If we decide to put Recent changes link once again, please revert this patch.

Use the same structure to build all menus in the system. We have pretty good Menus implementation and a Hook for registering new Menu elements. Instead of rewriting the system we could tweak a bit existing implementation, and write a reliable system for building menus. There are two reasons for that choice:

• BlueSpiceMultiUpload and GrowthExperiments already use MobileMenu hook to create MenuEntry objects
• we don't have enough time to refactor existing Menu system, the existing system allows us to play with it a little and make it much easier to extend.

@TheDJ the new MainMenu implementation still sticks to old way of having MainMenu entries defined/hardcoded in the MinervaNeue. But now, it will be much easier to change it/override it. Menu building is finally fully configurable, and the only required thing is a new class, sth like WikiSourcedMainMenu that implements Menu/Main/IBuilder. That class would have to fetch the WikiPage, parse it, and return Groups[] set based on the wiki page. Previously such change wasn't available, now, finally, it should be possible to do. The only thing is how to tackle user-related entries (like login/log out buttons),

In T216152#5104050, @ovasileva wrote:

• Ignore it if this is an URL to external site. The menu entry "Community Portal" will not be visible

@pmiazga - to confirm, it would be visible when it's an internal link? If so, let's go for this option.

I like the idea of separation of concerns and having a codebase that is explicit and easy to use. From my understanding,

• the action hooks can be used to modify state (expensive calls like update user in DB, log stuff, add tags, etc.)
• the filter hooks can be used to build/filter things (like building UserDefaultOptions array, adding JS modules).

@ovasileva I have a question regarding the Community portal menu entry. Link for that menu entry comes from MediaWiki:Portal-url page. Usually, it has a Title (something like Wikipedia:Community portal), but it is possible, that this page will have an absolute link: (something like https://test.com/link). Therefore (when it's a link), we cannot get the menu entry label. By default, the label is the page name (which is also localized -- translated to user language). For absolute links, we can add a fallback translation, but most probably it will not be used as most probably all wikis definte Portal-url as a Title.

I think it's valuable to do this thing, but IMHO we shouldn't allow users to enable things, that are disabled via config. I see the point of having ?amc=true to force AMC mode to be on, but only when AMC mode is available. But then it makes it
bit useless when it comes to testing because the automated browser test can just go and enable the AMC mode by itself.

@alexhollender I have everything. Thank you.

@Niedzielski the Minerva print button is handled uniquely. First, after injecting button, it logs shownPrintButton (printing is not always available, there is no need to inject the button if you cannot print). Then when clicked - it doesn't add printable=yes to the URL, what it does, after it's clicked first it logs the click, then tries to load images on the page (the one that is lazyloaded), then calls window.print().

I encountered the same issue while working on https://gerrit.wikimedia.org/r/#/c/mediawiki/skins/MinervaNeue/+/502278. After renaming MenuBuilder to Group and registering it via PSR-4 the AutoLoaderStructureTest started to fail. After adding MediaWiki\Minerva\Menu\Group also to AutoloadClasses it works again.

@Daimona the original error message is solved (now we log this error as a warning, not an exception), and looks like the AbuseFilter is the only extension that causes the ManualLogEntry::publish() to log a warning.
I created a separate ticket to fix the AbuseFilter behavior T219951: AbuseFilter shouldn't publish `udp` LogEntries with $newId=0 and I'd like to resolve this task.

@Edtadros AC1 and AC2 -> this is our env misconfiguration (CentralAuth plugin), it's not related to the QuikcSurveys extension. When you log in, please go back to testing urls manually. Sadly once you login, it cannot properly redirect you back to the site.

What about autofocus=true? https://www.w3schools.com/tags/att_input_autofocus.asp

The flash is pretty visible on my machine:

When I'm testing this feature on https://en.m.wikipedia.beta.wmflabs.org/wiki/Main_Page I see a small blue outline flash. When I click search bar first it gets the blue outline, then (when overlay gets visible) it loses the blue outline and then after less than half of second it gets the blue outline again. In short -> it gets outline, loses the outline and gets the blue outline again. Then after it gets the outline second time it stays while I input search query.
The browser is Chrome 72 on Linux (Debian testing).

@Isaac thank you for quick reply. Everything is clear now. Thanks. Also, registrationStart and registrationEnds sounds like much better names. I'll use those instead of registrationBefore and registrationAfter.

@ovasileva @Isaac couple questions regarding this task (mostly just to clarify things):

there is a function mw.user.getRegistration() that returns user registration as Date object.

This task is merged, I think we can resolve it. If you have any questions please re-open the task @Jdlrobson

I have to agree with you. It's not an epic, the task was relatively simple, the hardest part was finding people who can provide feedback on the changes to core repository. Also, the work is already done, and the tagging system works on production. There was a problem with some log entries (see T218940) but it's also tackled.

@Daimona definitely there is a configuration problem with AbuseFilter. If you have the RCID, then $wgAbuseFilterNotifications has to be set to rc or rcandudp. If it's set to udp, then tags are not applied to the RecentChange.

Looks like it's fixed, I don't see errors from wmf.23 branch, but let's keep it open for a couple more days to make sure the issue is fixed.

I'll add QA steps

It's not clear to me how to proceed with this task, this looks like a long task as we need to:

• create a new tag and start tagging everything with a new tag, then deploy to wikis
• during that time we will show both tags on Special:Tag page (the old one and the new one)
• create a maintenance script (I don't see anything like that), that will update the change_tag.ct_tag_id = NEW_ID where change_tag_ct.tag_id = OLD_ID. It also needs to update the change_tag_dev.ctd_count properly (don't miss edits that happened during maintenance script execution)
• run the maintenance script, and I'm afraid it can take ages for all wikis.

This whole maintenance process can take up like a week, plus most probably there are some edge cases are we ok with having two tags at the same time? Also, we need to do the same for both advanced mobile edit and mobile edit.

@dduvall it just got +2

This task is blocked by https://phabricator.wikimedia.org/T218940 - we need to solve logspam with Logging system, otherwise, our tagging system will be reverted, therefore tagging thanks action will stop working.

@dduvall we're very close to merge

Maybe it's a opcache issue?

I checked the https://en.wikipedia.beta.wmflabs.org/w/api.php and it works for me bot as logged in and logged out user.

The MobileFrontend.Context is available for 12 days in the codebase (https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/includes/ServiceWiring.php#L52), it was added in rEMFR95629c2ef014: Move creation of MobileContext to MediaWikiServices.

Explanation what's going on here:

I'm on it

I'll look into that, user preferences update happens as a deferred update (it's executed as a last thing during page request). Same happens with the Beta switch. I think that can happen when prod is bit overloaded, and server renders you a new page, but the properties update didn't finish yet. Thats why it renders as "off" state (because switching to ON is still in progress).

@akosiaris - yes, there is some logic that tries to kill the browser instances if browser.close() promise doesn't succeed[1]. Looks like this code requires some tuning, and most probably it should try to kill the browser instance after some time without waiting for promise resolution/failure.

@Edtadros - The failed test is ok, the texts are bit different. If you want I can update the QA steps and fix the expected messages.
The second step "tagged correctly at" => it means that it has all three tags (Advanced mobile edit, mobile edit, mobile web edit), and those tags are applied.

@Krinkle I agree with you that there is no good place for that. Currently we do same buckets for:

• QuickSurveys: https://gerrit.wikimedia.org/g/mediawiki/extensions/QuickSurveys/+/966ed14b56ba2b93317b31dfbd1e25264648c33a/resources/ext.quicksurveys.views/utils.js#22
• Popups: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Popups/+/b416e6b505e6fc03ed2cb0d3a4d387b7c8daa57e/src/counts.js

I think that we had similar bucketing code somewhere else, but most probably it's already removed because I cannot find it. With AMC most probably we will use the same code once again (creating same 9 lines of code in another extension).