In T322853#8594713, @ERayfield wrote:

not in core, but probably in skin, may not put in side bar or top personal nav, it sounds like it is the skin
as of now we believe we would have to put something into skin

Some examples of hooks being used in extensions to build menus can be found below.

I'm closing this as it answers all the questions and is okay without product signoff.

@eigyan to update with his latest findings.

Maggie to reformat with spike template.

Maggie to reformat with spike template.

To be discussed in engineering tomorrow, and timeboxed until the end of the week.

Maggie to reformat with the spike template.

Yeah, Growth Experiments is it.

Extensions to look at:

This is the page to navigate to locally to look at what Growth has built: Special:EditGrowthConfig.

The more reusable parts of this would be the WikiPageConfigWriter class and the factory the special page uses.

A few thoughts on ways forward:

• Could we call this *vertical* layout instead of *mobile*? I suggest this because that makes it more usable in other contexts/devices in the future, if for any reason others would rather use this (beautiful) new layout.
• With this approach, I'd suggest pulling the code that handles hashes into a separate file. As I looked at this before break, the issue--with either consolidating files or separating them--is that the hash code is very specific to the tab layout right now and would need reworking to incorporate the newly optimized vertical menu. If we pull the hash code out, the trick too is to trigger the desired behavior in the other files.
• How hard would it be to rewrite preferences in codex? That's ultimately going to be more supportable, and might allow us to restructure the code to address some of these concerns. If that was actually doable within a week, it might be worthwhile. It is not simple to rewrite this in codex right now because they are still working on allowing server-side rendering.

Here's where the special page is in GrowthExperiments: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+/refs/heads/master/includes/Specials/SpecialEditGrowthConfig.php.

I'm looking through these files and understand why this is tricky. Right now, we have the variable useMobileLayout but it is only used in init.js to choose between tabs.js and mobile.js. Assuming it is true, only mobile.js is loaded. Previously, useMobileLayout was loaded in both tabs.js and mobile to js to determine what code to use. Jason's approach would have us moving all the code to tabs.js with useMobileLayout switching between the two display options. I can see his point around maintainability, but it does introduce a lot of complexity into that file and tabs.js could become too heavy. In addition, it is hard to extricate the hash change logic from tabs. Note this comment was edited to consolidate it with the ones below it, which is why they were deleted.

This task got stalled. While we determined the high error rate, we still do not know why the errors are happening.

Most recent final timestamp: 20220426131656.

@ERayfield I really like the logic flow! Your notes above are very helpful. But I don't quite see the pros and cons of sending files. What does

@ERayfield What were your findings here?

As noted in the task above, I have that it is still a huge failure rate with only .05% of images being sent to photoDNA successfully.

I grepped the logs today and got 574 successes out of 971476 files sent.

Most recent timestamp: 20210430135351

I was thinking the first approach. Creating the statistic on an ongoing basis is out of scope for this task, as we need to get these numbers sooner to know how to proceed.

Or this message: Creating moderation request for file

We could maybe use Ellen's output

@jsn.sherman suggests using number of files rather than existing error messages.

Oh! I got exactly one "No hash match found" message now. Also, David Rochford says that there have been a total of 25 emails sent with matches.

It doesn't look like they have, but I was searching for "Hash match found for file" and "No hash match found for file". I wish we had Ellen's messages in now, because it would have been helpful.

I can confirm that I saw no success messages in the logs today.

There appears to be a file type check in MediaModerationService::processUploadedMedia but only if checkOnUpload (MediaModerationCheckOnUpload) is true and it seems to not be true for us currently.

From Cindy on sending files versus urls: "I recall that change being made. I will check my email archive to see if I can reconstruct the reason. I have a feeling it was because they have a relatively small size limit if you send the file itself."

We can also increase the logging level per https://phabricator.wikimedia.org/T303312.

Question from engineering talk: should we stop sending urls and send the photo instead? Why wasn't this done in the past? https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MediaModeration/+/576338 seems to have done this before. The next step might be asking Cindy Cicalese.

@ERayfield will be updating this today with how she had approached the code.

I approve this request.

@ERayfield aside from color ;), it looks like just what was asked for to me! I'd go ahead and push it up for @aminalhazwani and the team to review. We could also set up a patch demo for it. @Scardenasmolinar knows how to do this.

With some local testing I did find that if there's an error in the creation of the thumbnail it's not always caught. I'll need more info to know if that's what's happening here.

I got a response that needs more investigation:

I got some replies:

I followed up today because I haven't heard any kind of response.

I have sent an email to PhotoDNA support.

I've reached out to Nicholas to confirm the best way to reach PhotoDNA.

For my own notes: I'll be asking about the error we're seeing, as well as developer credentials for a sandbox account, if available.

I've reached out to @drochford in slack to make sure I contact the correct person.