UrlGeneratorInterface::getPathFromRoute() is marked deprecated but will not be removed, so update the docs

roughly we need a method that generates the path without running the processPath() step, and with appropriate naming and docs.

i.e. we want to get the generated but non-aliased path.

@dawehner - however, that doesn't include the query string or fragment?

but yes, roughly it's that simple (and/or we should rename it)

Patch here still applies, is this still relevant?

Given that we fixed the destination query string handling, I think we should instead be killing this method as indicated by the deprecation?

This patch removes all meaningful usages of UrlGeneratorInterface::getPathFromRoute().

There are still some test usages of getPathFromRoute(), but they test the method itself and not integration. We can pull those when we do the follow-up to remove the method.

Ooooookay....

So the need for a non-aliased path is greater than @deprecated.

This patch renames getPathFromRoute() to generateInternalPathForRoute() and fluffs out the documentation a bit.

I'm 80% positive that this could all be refactored to be more elegant and beautiful, but that's not the scope of this issue.

We could re-jigger getInternalPathFromRoute() a bit, make it public and use it, but it's also used by generateFromRoute().

So here we are.

It seems like the last patch is not in line with the goal of the issue. We really do want to remove this, so let's see why the prior patch failed.

There is a need to generate a non-aliased path from an internal route.

There is nothing to replace it.

The patch in #11 fails because it simply removes usages of getPathFromRoute() and replaces them with generatePath() without taking into account this need.

I can only assume that there are historic oral-history-type reasons for having all these similar-but-slightly-different methods for generating paths from routes, and I'm not up to the task of learning them.

@Mile23. Can you please identify where/why we generate a non-aliased path from an internal route? That is the problem to be solved here.

The patch in #11 was useful to start identifying the problems to be adderssed. Possibly this issue needs to have some sub-tasks rather than trying to address everything in one patch.

I think the real issue is that path processing and aliases are coupled to the "internal" path so we cannot remove that capability from the generator if we want to be able to e.g. create a path alias for a given route.

If we are not removing it from the generator, there is no point in removing the wrapper method from Url.

wrong class

Simple docs fix

should @deprecated be changed to be @internal (in the code)?
#2550249: [meta] Document @internal APIs both explicitly in phpdoc and implicitly in d.o documentation has discussion about what should be internal.

guessing at my own answer: no. this is not @internal

@YesCT - I'm not sure what @internal implies, but anyone creating path aliases may need to call this, which doesn't sound strictly internal

#16 mentions some separate issues might be useful, but @pwolanin says that is outdated.
so this is rtbc.

remaining task is look for change records to be updated, but I'm not sure what to search for.

searching for getPathFromRoute
https://www.drupal.org/list-changes/published/drupal?keywords_descriptio...
gives one result
https://www.drupal.org/node/2046643

Afaics we have one real usage left in Url::getInternalPath() and that is not deprecated so I can't see anyway around this. Committed f962623 and pushed to 8.0.x. Thanks!