Add a search API configuration override
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	• Niedzielski
	Dec 21 2018, 5:36 PM

Description

$wgMFNearbyEndpoint and $wgMFPhotoUploadEndpoint are useful configurations for development however they come at the cost of shipping code to production. They also do not apply to all API requests. A notable omission is a search API endpoint override. What should that look like? The seam is currently in the skin, MinervaNeue, but the the other configs reside in MobileFrontend. We can do something like api.defaults.ajax.url = 'https://en.m.wikipedia.org/w/api.php' but do we want to?

Ex: https://gerrit.wikimedia.org/r/#/c/mediawiki/skins/MinervaNeue/+/445203/

Acceptance criteria

Search can be configured to arbitrary URLs. For example, it should be possible to search production enwiki pages from a local instance with no pages.
Reduce the amount of development-code shipped to production

Details

Related Changes in Gerrit:

	Subject	Repo	Branch	Lines +/-
	Generalise api proxying - Introduce actionParams helper	mediawiki/extensions/MobileFrontend	master	+74 -47
	Modernise api proxying in MobileFrontend	mediawiki/extensions/MobileFrontend	master	+57 -125

Customize query in gerrit

Related Objects

Mentioned In: T207787: [EPIC] Reduce the amount of modules in MobileFrontend
Mentioned Here: T122721: Add localhost to $wgCrossSiteAJAXdomains
T212314: Review additional elements exposed by external services that may not work

Event Timeline

• Niedzielski created this task.Dec 21 2018, 5:36 PM

Restricted Application changed the subtype of this task from "Deadline" to "Task". · View Herald TranscriptDec 21 2018, 5:36 PM

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Jdlrobson moved this task from Incoming to Needs Prioritization on the Web-Team-Backlog-Archived board.Dec 21 2018, 6:18 PM

The issue here is CORS. Nearby uses JSONP to get around the CORs issue. $wgMFPhotoUploadEndpoint is actually used in production not development, to access commons from Wikipedia.

I'd be in favor of a single development URI to replace $wgMFNearbyEndpoint and set api.defaults.ajax.url but we'd need to solve the CORs issue first. For that I've not had any ideas (hence why the status quo)

Jdlrobson updated the task description. (Show Details)Jan 3 2019, 9:39 PM

Jdlrobson mentioned this in T207787: [EPIC] Reduce the amount of modules in MobileFrontend.

Change 482233 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Modernise api proxying in MobileFrontend

https://gerrit.wikimedia.org/r/482233

Change 482234 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Introduce queryProps helper

https://gerrit.wikimedia.org/r/482234

I had a tinker with this last week as I needed to test the LanguageOverlay. I'm quite happy with the suggested solution I've come up with - it throws away code, DRYs some things up and most importantly allows us to test more workflows locally!

Jdlrobson claimed this task.Jan 9 2019, 11:01 PM

Change 482233 merged by Jdlrobson:
[mediawiki/extensions/MobileFrontend@master] Modernise api proxying in MobileFrontend

https://gerrit.wikimedia.org/r/482233

ReleaseTaggerBot added a project: MW-1.33-notes (1.33.0-wmf.13; 2019-01-15).Jan 10 2019, 12:00 AM

Hi, For the ExternalGuidance project, we have a usecase where when a content is presented in external context such as Google translate, the search feature in mobile frontend should work. Currently when our content is presented in a foreign domain, sometimes under an iframe like google translate, the search feature in mobile frontend fails because of CORS. See T212314: Review additional elements exposed by external services that may not work

So, it is not only the case for a developer's localhost get the search working with production content and APIs.

Currently this is what happening: When searched, the progress indicator is shown and nothing else happens. There is CORS error in console.

If this task can help to unbeak this usecase, it would be great.

If this task can help to unbeak this usecase, it would be great.

This task is purely for development and not intended for public consumption so won't help this particular issue (to be clear the issue you are talking about has security concerns). The CORS issue with Google is actually a lot easier to address. It would require adding translate.google.com to the trusted domains inside $wgCrossSiteAJAXdomains - easy to do technically, but might prove a little trickier socially!

Change 482234 merged by Jdlrobson:
[mediawiki/extensions/MobileFrontend@master] Generalise api proxying - Introduce actionParams helper

https://gerrit.wikimedia.org/r/482234

Jdlrobson edited projects, added Web-Team-Backlog-Archived (Readers-Web-Kanbanana-Board-2018-19-Q3); removed Web-Team-Backlog-Archived.Jan 10 2019, 7:16 PM

Jdlrobson moved this task from To Do to Ready for Signoff on the Web-Team-Backlog-Archived (Readers-Web-Kanbanana-Board-2018-19-Q3) board.

I don't think there's anything more to do here. Given T122721 and authentication needs it seems unlikely we can support write API requests.

	F27840168: image.png
	Jan 10 2019, 5:38 AM

Add a search API configuration overrideClosed, ResolvedPublicActions