👍

ref#3910

Also interface changes is a BC-break

I didn't see that other ticket, thanks for referencing it. I would counter the reason it was closed though because...

1. Fragment generation requires encoding that could gain correctness from framework help (rather than having to encode the fragment yourself)
2. With the redirectToRoute helper in 2.6 it now remains clumsy if you are redirecting to a route with a fragment (ie. You can't so need to use generateUrl and redirect)

I also didn't think of the BC break... That's unfortunate.

I didn't realise there were special parameters (underscore prefixed) to generate, that sounds like a better approach - hopefully my reasons above will help get that other ticket reopened at least.

I reworked the patch to use a 'special' parameter inline with other Symfony special parameters for the fragment. This removes the BC issue with the interface, though would obviously cause a problem if people were already using _fragment as a valid query string parameter.

Still a BC break as you figured yourself.

Just a quick comment. In Drupal we have all kind of additional options, like the fragment, but also language, whether we want to render it as http or https ...
The signature looks like the following:

  public function generateFromRoute($name, $parameters = array(), $options = array());

I agree that a helper for the fragment is useful because of the encoding need. And I cannot think of a better solution than the one provided here. And the tiny BC break is negligible because it's unlikely.

Three things are missing for me to be merged:

1. the special meaning of_fragment must be documented in the phpdoc of UrlGeneratorInterface
2. the slash/ should be decoded from the fragment just as it has been done for the query indecodes some special chars in a URL query #12223. this is also part of the rfc: "The characters slash ("/") and question mark ("?") are allowed to
   represent data within the fragment identifier."
3. we should add a test when_fragment is used as a path parameter name, e.g./fragment/{_fragment} both for generating and matching. and a test with a same document relative reference with just a fragment, e.g.#fragment as a result.

@rodnaph Can you address@Tobion concerns?

@Tobion

I've addressed your first two concerns.

For the third I thought the best solution would be to throw a LogicException when compiling the route, as _fragment has no meaning as a path parameter. I'm not sure what you meant about"a test with a same document relative reference with just a fragment" - would that be a route with no pattern? eg.new Route(''); ?

I also rebased onto current master as there were some failing lint issues.

/cc@fabpot

+1@Tobion

@inso Fixed, thanks.

Apart from my small comment, 👍

ping@Tobion

@rodnaph Can you rebase on current master?

@fabpot done

Thank you@rodnaph.

Why not use the more intuitive (and less conflicting) parameter key# instead of_fragment, like:

// generating a URL with a fragment (/settings#password)$this->get('router')->generate('user_settings', ['#' =>'password']);

@King2500 true, could be an alternative. I guess_fragment was the first idea because it's also_locale that has a somewhat special meaning.

@King2500 I'm always in favor of short option names, but in this case I'd prefer to keep the consistency. Every special routing option in Symfony follows the same pattern:_controller,_locale,_route,_route_params,_redirected, etc.