In estimation, we had a discussion about whether we should:

1. Rewrite the link on the fly as proposed (which is complex due to the interaction of Javascript and PHP);
2. Just bring people to a blank Special:Search without preserving a search query;

or

3. Move the link to be a form submit button with a different form action. This would be more performant, and require less complexity in Javascript. It would preserve the spirit of the ticket (allowing users to move from using MediaSearch to Special:Search as needed and preserve their query), without requiring a bunch of extra Javascript - but it also requires more design work.

Moving this back to Needs Design to consider.

Interesting – I didn't realize the "switch to special:search" link actually included the query at all; I just assumed it took the user to a blank page no matter what.

This link is part of the standard wikipage "chrome" – it falls outside of the part of the Special:MediaSearch page that updates as user input changes. We generally leave this wrapper part of the page alone once the JS version of the UI initializes.

However we certainly could "reach outside" of the Vue application to modify the URL parameters in this link whenever the user changes the value of the search term. It is probably not worth it to translate other search parameters that they may have set (a custom set of namespace filters, for example) because this will get complicated quickly. As long as we keep to the simple approach I'd say this option (aka #1 above) might still be easier than #3 (change the design of the page and add a button). But of course the second option is the simplest.

Here's a somewhat related question: should we add instrumentation to track when users click the "switch to special:search" link? Could be useful to know how many users are still reaching for the non-MediaSearch interface.

In T285169#7175918, @egardner wrote:

However we certainly could "reach outside" of the Vue application to modify the URL parameters in this link whenever the user changes the value of the search term. It is probably not worth it to translate other search parameters that they may have set (a custom set of namespace filters, for example) because this will get complicated quickly. As long as we keep to the simple approach I'd say this option (aka #1 above) might still be easier than #3 (change the design of the page and add a button). But of course the second option is the simplest.

This sounds like the best solution to me if it's not that complicated - we won't remove any existing functionality that way, and if it's not as complex as we feared, it's what I prefer. What do you think @mwilliams?

Here's a somewhat related question: should we add instrumentation to track when users click the "switch to special:search" link? Could be useful to know how many users are still reaching for the non-MediaSearch interface.

This would be useful, but I wonder if we can already gather than info just based on usage data for the Special:Search interface, without needing to specifically know whether users are switching over. What do you think @nettrom_WMF ?

In T285169#7176214, @CBogen wrote:

In T285169#7175918, @egardner wrote:

Here's a somewhat related question: should we add instrumentation to track when users click the "switch to special:search" link? Could be useful to know how many users are still reaching for the non-MediaSearch interface.

This would be useful, but I wonder if we can already gather than info just based on usage data for the Special:Search interface, without needing to specifically know whether users are switching over. What do you think @nettrom_WMF ?

I don't see a need for instrumenting it. We aggregate and dashboard usage of legacy search, which should give a good indication of the overall trend. While the dashboard graphs it daily for the past month, it's relatively straightforward to for example change it to show a weekly moving average over the past quarter and see that fulltext searches through Special:Search has been slowly declining since MediaSearch rolled out.

If the team starts working on specific interventions/experiments, this would of course change. But then they'd probably focus on Special:Search to encourage switching from that to MediaSearch, and not on preventing users to switch away from MediaSearch?

If option #1 "Rewrite the link on the fly as proposed" is possible and the easiest solution, I would prefer that over adjusting the current design.

In terms of implementation, I think the following will be needed:

The code that currently initializes a new Vue instance on the Special:MediaSearch page will need to be modified slightly – the App component could emit events every time the search term changes that could be handled here, for instance. A handler method could be defined that reaches out into the markup of the surrounding page via jQuery or document.querySelector and then updates the destination URL of the "Switch to Special:Search" link to match the current search term.

When the search term is cleared, the destination query params should be cleared as well.

This should be a fairly straightforward change.

Change #1037155 had a related patch set uploaded (by Simon04; author: Simon04):

[mediawiki/extensions/MediaSearch@master] Update "Switch to Special:Search" link _target

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

Change #1037155 merged by jenkins-bot:

[mediawiki/extensions/MediaSearch@master] Update "Switch to Special:Search" link _target

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

Checked in commons beta - works as expected; moved to QA column on the Current work board.