Use base path instead of url object in the DisplayInterface

Sorry, too eager here.

Looks great. Thanks.

Thanks for reporting this issue! I was not aware of this problem, it indeed sounds tricky to resolve. I don't see where in the code Url::fromUserInput() would invoke that hook, but I'm gonna trust you on that.

However, there's still several problems both with the idea and the patch (the latter easier to resolve, of course – see my attached revision):

1. The patch contains whitespace errors.
2. I prefer returning NULL, not FALSE. Core also seems to slightly lean in that direction, although – unsurprisingly – they are more ambiguous on the topic than the Search API.
3. My attached patch also fixes some unrelated code in ViewsTest – sorry about that! (If we don't commit a patch here, I'll just have to think of fixing these regardless.)
4. Regarding the general idea: What about search displays that require GET parameters? Seems these wouldn't be supported anymore? Or do GET parameters work with internal paths? In any case, this would seem like a (small) step backwards, so we should at least be certain that we don't want to support those.
5. Also, we're already in Beta, even quite near to RC, so we should be very careful with such API changes. In theory, this wouldn't even be allowed, I think, using the rules for changes in Beta phase, and normally I try to keep to them as far as possible.

Why do you even need to get the displays' URLs in processInbound()? Isn't there separate configuration for Pretty Paths for each display? If there is, you should just add the path to that, translating from the search display's returned URL.

Core config entities (e.g. \Drupal\views\Plugin\views\displayViewExecutable), use getPath which returns the base path instead of an url object.

There's about as many classes with getUrl() as with getPath(), so that's not an argument.

As discussed with @drunken_monkey we can keep ::getUrl() and add a new method ::addPath().

If we add ::getPath, we should also add tests for that method.

Needs work then. Thanks Joris

Adding tests for ::getPath again

Great job, thanks!
Especially good that we figured out this issue with block displays having paths! Views logic strikes again …

I think some of that code was unnecessary workarounds for that?
Also, I think we should try to explain what the difference is between getPath() and getUrl(). Maybe we should even deprecate the latter? (I don't think having GET parameters as part of a search's base path is really a use case, and if it were, part of the code (i.e., facets, at least with pretty paths) couldn't support it anyways.) I'd just leave it in now for the stable release, seeing as we're really late in Beta.
Then, now that we have getPath(), we should also use it internally in the display plugin base class for getting the path.
Finally, there was a white-space error, as I pointed out to you in person already.

Patch attached, which would be RTBC as far as I'm concerned. Please test/review!

Woooo!

I think deprecating getUrl is a good idea.

OK, needed a re-roll anyways.
Will commit if tests pass.

OK, great.
Committed.
Thanks again, everyone here!