There are too many ways to generate URLs and links

Well, Url::toString() was chosen in order to make it possible to not have to worry about the url generator or the unrouted url assembler.

The link value object is valueable, I would not remove that. Links are not just markup, things like breadcrumb builders should return a list of links, in
which case a value object works perfectly here.

remove \Drupal::url(), it only exists for legacy reasons, and 80–90% of the callers in core are 1) tests, 2) hook_help() implementations.

+1!

only have a single URL-generating mechanism, I don't care which one, as long as it's only one. Perhaps UrlGenerator::generate() without complying with the Symfony interface, because it doesn't make sense for Drupal to only have one option (absolute or relative). And have that always return an object that includes the cacheability metadata

Well, getting rid of the parent interface will be tricky, given that RouterInterface forces you to inject one.

Even if we keep \Drupal::l() it could just call \Drupal::service('renderer')->render($render_array_with_type_link). Together with the rest of the plan, that would also keep sanity.

For Urls I think the best is - as Crell said - to have a UrlRenderer as the single mechanism that has both the UrlGenerator and the Renderer injected - and use that to 'render' urls to a String.

Please do not make me write "\Drupal::service('renderer')->render($render_array_with_type_link)" to print a simple link. :)

Well, except we obviously do:

$ grep -r '\Drupal::l(' . | wc -l
     105
$ grep -r '\Drupal::url(' . | wc -l
     371
$ grep -r 'UrlGenerator::generate' . | wc -l
      10
$ grep -r 'LinkGenerator::generate' . | wc -l
      13
$ grep -r 'Url::to' . | wc -l
       3
$ grep -r 'Link::to' . | wc -l
       0

versus:

$ grep -r "#type' => 'link" . | wc -l
      73

But fair point that best practice in D8 is definitely to use render arrays. But core is apparently setting a very bad example of that currently.

Also cross-linking a few things.

And another.

\Drupal::url() (cfr. Drupal 7's url())
\Drupal::l() (cfr. Drupal 7's l())
UrlGenerator::generate() (Symfony's interface, only able to opt in to absolute links, all other options lost)
UrlGenerator::generateFromRoute() (the recommended way)
UrlGenerator::generateFromPath() (deprecated)
Url::toString()
Url::toRenderArray() (used once all across core)
LinkGenerator::generate()
LinkGenerator::generateFromLink() (to pass in Link objects)
Link::toString()
#type => link render arrays

a) Mark \Drupal::url() and \Drupal::() as something which clearly indicates that you are a lazy person if you use them!
b) Document ::generate() that its discouraged to be used because its the interface inherited by symfony ... We better keep it, as this allows people to build more generic code
c) Yeah. You could see generateFromRoute as internal API function for Url objects. I think we kinda thought about that like that.
d) Well, there are issues to remove the usages
e)
f) Url::toRenderArray() ... I think this is a helpful wrapper for some usecases. The world is not just strings and render arrays.
g)
h) Link::ToString() I really hope we don't remove those value objects. Its super helpful for some usecases. You know what a breadcrumb builder is returning.

So to sum things up: Clearly document that \Drupal::url()/\Drupal::l() are convenience wrappers, Document on the URL object that you should use them and point to the url generator.
Make it clear that ::generate() is not considered to be used for Drupal only code.

"Url::to" will only include documentation, it is ->toString() on a Url object, which isn't always constructed on that line...

grep -r "Url::.*toString" core | grep -iv 'Test.php' | grep -iv '_test.module' | wc -l
      33

So that's only a subset of them.

Quote the webchick:

But core is apparently setting a very bad example of that currently.

Yes, which is a large part of the problem. :-) That is largely due to the url-generating process evolving over the past 4 years, and full metadata actually having significant value only coming in rather late. (Also, the eternal "I don't know how far we'll be able to push it" problem.) Given the current state of things, though, I would agree with Wim that the primary way of dealing with links SHOULD be via value objects at this point, as those can encapsulate metadata better than any of the other options. Those value objects can be tossed into render arrays fairly easily, which is what you should do in the majority case.

The Generator et al still exist, and will continue to exist, but become internal implementation details of rendering. You'll rarely touch them yourself, except perhaps for creating redirect responses or other places where you're interacting with HTTP directly rather than through HTML. (If you're doing HTML, you want to use our mechanisms.)

Getting rid of hook_help() will make this problem space FAR easier, as well as the dozen or so other advantages of killing it. (One of which being that we can use the line "the last remnants of Drupal 3 have been swept away.")

Imagine that all hook_help() implementations actually lived in Twig files.

Isn't that ship sailed already? #1918856: Put each module's help into a separate Twig file, #2188753: Get rid of hard-coded markup in hook_help() implementations and #2351991: Add a config entity for a configurable, topic-based help system

Instead of hook_help() topic pages at all within the site, why not just have an external link to the information on the module that already exists on drupal.org ? --- This would make the information more easily updated and available in other translated languages.

Well, Url::toString() was chosen in order to make it possible to not have to worry about the url generator or the unrouted url assembler.

In which contexts? I did a search through my D8 contrib code to look for potential use cases and only once did I use Url::toString(), which is done to return a Symfony RedirectResponse. As Wim said, in most cases code should build a render array rather than render a URL on the spot.

In which contexts? I did a search through my D8 contrib code to look for potential use cases and only once did I use Url::toString(), which is done to return a Symfony RedirectResponse. As Wim said, in most cases code should build a render array rather than render a URL on the spot.

There are gazillions of generic code in Drupal 8 which don't want to have to deal with the difference between being an internal URL vs. an external URL, so its encoded as being a Url object.

There are other ways to abstract out that logic than to add logic and dependencies to Url. A generic link/URL renderer can internally dispatch calls to the correct URL handlers, so most code just uses Url objects and inserts them into render arrays.

My perfect URL interface:

- \Drupal::url() (cfr. Drupal 7's url())
- \Drupal::l() (cfr. Drupal 7's l())

using e.g. twig inline templates via

- Url::render() - returns render array, for twig
- Link::render() - returns #type => link render array, for twig

( need to extend TwigExtension::renderVar to check for RenderableInterface )

Both should be used primarily within twig.

Leave:

- Url::__toString()
- Link::__toString()

but push any metadata this would generate to the current render context.

Deprecate:

- UrlGenerator::generate() (Symfony's interface, only able to opt in to absolute links, all other options lost)
- UrlGenerator::generateFromRoute() (the recommended way)
- UrlGenerator::generateFromPath() (deprecated)

- LinkGenerator::generate()
- LinkGenerator::generateFromLink() (to pass in Link objects)

- Url::toString()
- Url::toRenderArray()
- Link::toString()

Fabian: No, using Drupal:: is not the preferred interface for anything. I'm hoping we can remove it entirely in Drupal 9. It's a BC shim for procedural code only.

The Url and Link objects are, I would argue, the right way to approach it. Value objects for complex values.

This is the result of some research of @plach, @Wim Leers and @dawehner

Yeah not okay with the phrasing of the "remaining tasks".

I came across this issue after in this comment @Crell steered me towards not using Drupal::l() and using a render array instead.

Thus replacing:

$items [] = \Drupal::l($nodes[$count]->getTitle(), $nodes[$count]->urlInfo('canonical'));

with something like:

$items [] = array(
  '#type' => 'link',
  '#title' => $nodes[$count]->getTitle(),
  '#url' => $nodes[$count]->urlInfo('canonical'),
);

I'm not sure we should be removing ways to do things, but better documenting stuff, especially with @deprecated would be good.

So what's now the "right" and "not deprecated" way to create a link?

That change record is incomplete, it says other methods have been deprecated, but doesn't give the new recommendation (other than the entity example).
We should expand it to give an example of the Link and Url object usage.

+1 for #29

I was need to create html to put in #suffix so I did next

use Drupal\Core\Link;
Link::fromTextAndUrl("Add New page", Url::fromRoute('mymodule.add_new_page'))->toString();

1) Can i use summary field as meta description and call call on the head of .twig file??
2) If yes, what will be the proper syntax to call summary field in .twig file?
Since i have page.twig and html.twig with me..
3) Also how can we make block call in internal basic pages in drupal 8?

Please reply me as earliest..

#29 yes, the change record is incomplete. Inspiration can be gotten from https://dev.acquia.com/blog/coding-drupal-8/generating-urls-and-redirect... .

I would try to draft it myself if I had a full picture but there's at least one thing I find confusing:

* On one hand, I (Drupal dev who's dabbling in core contribution but never keeps up with everything that's happening) have been told by a zillion articles to Inject All The Things. So, great. As far as I can see, the url_generator service / UrlGeneratorInterface is what I should be injecting into all my services/plugins/components.

* but wait! UrlGeneratorInterface::generateFromRoute() is marked as internal so apparently I shouldn't use it in my components. Apparently Url::fromRoute(ROUTE)->toString() is the replacement to get a link in string form. (And AFAICT there is no alternative to 'string form' for at least doing redirects.)

* but but but wasn't I supposed to Inject All The Things and isn't Url::someStaticMethod() just a glorified 'global function' that is 'bad' to call in my components? Confusion!

What gives?

@roderik The Url class is basically a value object, so in that sense doesn't need to be injected. It's only when you render it to a string that the UrlGenerator dependency is pulled in. But you basically shouldn't be rendering it yourself - use a link render array.

@pwolanin thanks for the explanation and @cilefen for the link - it sounds perfectly reasonable now I'm tracing the code and the discussion in the other issue. But it's not a thought pattern I had internalized yet, so couldn't get there myself.

(So now to find time for that change record...)

Here is one subissue which cleans up URL generating for entities: #2818625: Add a Url::fromEntity() method

Drupal 8 and 9 now have too many ways to generate URLs and links.

One variant we can remove without too much trouble: #3151019: Only allow route names, deprecate support for route objects in UrlGenerator methods

#3151017: Deprecate UrlGenerator::supports() and UrlGenerator::getRouteDebugMessage() and #3151019: Only allow route names, deprecate support for route objects in UrlGenerator methods both ready for review - simplifies UrlGenerator a bit.

All child issues and related ones are closed, can we close it?

Looks one of related #2646744: \Drupal\Core\Url does not accept root-relative (file) URLs, making it impossible to let LinkGenerator create root-relative file URL links

And one more #3087434: [meta] Use FileUrlGenerator::generate() everywhere, then deprecate generateString() and generateAbsoluteString()

I think we still might need issues opening for these:

Url::toRenderArray() — 1 occurrence
Remove the sole usage & mark as deprecated.

LinkGenerator::generate() — 28 occurrences
Should be internal.

LinkGenerator::generateFromLink() — 3 occurrences
Should be interna

Thank @catch

Filed for #63.1 - it needs opinions about Url::renderAccess() which is used in contrib but not in code after #3342975: Deprecate Url::toRenderArray() and Url::renderAccess()

and for #63.3 is internal already and only 1 usage #3342991: Deprecate LinkGeneratorInterface::generateFromLink() but it replacable with generate()

The generate() is already internal via #2606390: mark \Drupal\Core\Utility\LinkGeneratorInterface::generate as internal

So we can only deprecate generateFromLink() via #3342991: Deprecate LinkGeneratorInterface::generateFromLink() as it also internal since #2606392: mark \Drupal\Core\Utility\LinkGeneratorInterface::generatFromLink as internal

Also linked child issue #2819197: Generated url cache context is not correct for relative urls from the UrlGenerator

Looking through the issue summary again, we might need one more issue (if it doesn't already exist):

Entity::url() and Entity::link() loose cacheability metadata
They should either be deprecated and trigger an error

And maybe for this bit:

We throw an exception in ::generate() in case we return a string in a inside a render context.
For link objects add toString() so its renderable in twig
Add Link::toRenderArray() to support using Link objects

Both ::url() and ::link() on entities are already replaced by ::toUrl() and toLink() in #2606398: Add EntityInterface::toUrl() and EntityInterface::toLink() and mark urlInfo(), url() and link() as deprecated

As I see generate() always returns GeneratedLink so it should always have cachability metadata
There's already toString() and \Drupal\Core\Link::toRenderable() so not sure Link::toRenderArray() is needed

The remaining is #3342975: Deprecate Url::toRenderArray() and Url::renderAccess()

Thanks @andypost! Given #3342975: Deprecate Url::toRenderArray() and Url::renderAccess() is RTBC I think we can close this now!

Tried to add issue credit for triage, but a lot of comments here and it's hard for meta/policy issues, so might not be perfect.

Awesome! Now API looks polished, would be great to start add types to arguments and clean-up routing leftovers

@Wim Leers please comment/help with remaining related bug #2819197: Generated url cache context is not correct for relative urls from the UrlGenerator

The last one commited! #3342975: Deprecate Url::toRenderArray() and Url::renderAccess()

Late contender #3271570: Rendering the URL part of a link field in a Twig template should work equally for external, internal relative paths, and internal system paths.