Imo. the behavior is buggy, and this is my approach to revise it (i may do PR's right?).

I explained why imo. it's needed, so feel free to argue.

There are 2 viable options to me;

• this approach
• introduce a new%asset.default_base_path% param and provide a default context

Option 2 is also reasonable, and may perhaps be the better approach. However i chose this one as we already introduced routing params, and it will work for people who already set the base url with it (not sure about that actually).

edit:
After all, I think we should go with

assets:context:base_path:'%asset.context.base_path%'secure:'%asset.context.secure%'# ...

Any thoughts?

edit: yep, basically#19396 (comment) 😅

@stof different approach, way simpler :) WDYT?

Since this adds new parameters, this is not a bug but only a feature.
Doc PR should be opened before merging, because that's the only way to know about the params.
About the params, they are obscure things usually to users, which means very little are going to know about them and their purpose, even if it's documented.
Which means we shouls try hard tonot add new params when possible (I don't know here, just emphasizing this important point :) .)

Agree.. on the params. Im not even sure we need them, same for routing context params actually; see#21043

However the bug is real.

Before the introduction of the new Asset component theasset() function made use of the request context config options, right?

Not sure, i should have a look at that. Fact is (given the current context options) we cannot go from base url to base path genericly.

/request-base/app_dev.php/route/request-base/asset-base/asset vs. /request-base/app_dev.php/asset-base/asset

I guess practically one could get away with configuring package base urls, going absolute. BypassingRequestStackContext::getBasePath and no support for relative URL's :)

As this used to work in previous releases we should at least strive to make the Asset component compatible with how the Twig functions used to work before. We can still think about how to make things better and deprecate stuff in 3.3/3.4.

As this used to work in previous releases we should at least strive to make the Asset component compatible with how the Twig functions used to work before.

Im not sure i follow.. i did a quik test; installed latest 2.7 in a subdir (reachable athttp://symfony-sub.dev/sf27/web/app_dev.php)

Updated framework config withassets: { version: 1, base_path: /assets }

Updatedapp/Resources/views/default/index.html.twig to display{{ asset('foo.jpg') }}

Added a commandtest with$output->writeln($this->getContainer()->get('twig')->render(':default:index.html.twig'));

Results :)

What did we removed? Or what am i missing here?

I mean before the introduction of the Asset component (so you will have to use a Symfony version before 2.7 to see how it used to behave back then).

I see. Not gonna investigate that now :) I mean, i cannot really compare the asset component against nothing. Either the approach was the same-ish, or it suffered from the same problem. Here's my approach for 2.7 and up 👍 (perhaps along with#21043).

But again, if im missing something in terms of a different approach done previously.. let me know :)

Oh, and it's totally fixable in user land. So we can always keep things as is here; an unsupported feature.

Oh, and it's totally fixable in user land. So we can always keep things as is here; an unsupported feature.

But the thing is that this used to work before (theasset() function did exist before the introduction of the Asset component in#13234, seehttps://github.com/symfony/symfony/blob/2.3/src/Symfony/Bundle/TwigBundle/Extension/AssetsExtension.php#L55).

I think looking athttps://github.com/symfony/symfony/blob/2.3/src/Symfony/Bundle/FrameworkBundle/Templating/Asset/PathPackage.php#L31 andhttps://github.com/symfony/symfony/blob/2.3/src/Symfony/Component/Templating/Asset/PathPackage.php#L35 it suffered the same problem.

But im really not aware of any CLI defaulting with params or so in 2.3, which would be basically this approach.

Now we could do it convention wise perhaps, making use of%router.request_context.base_url%.

If ending with/ it's the base path (/request-base/), otherwise it's the base URL (/request-base/app_dev.php) and we do adirname. Could work...

@ro0NL I'll look into an old 2.3 application to check how exactly it used to work then.

@xabbuh any news? :P

Prettiest fix is still#21043 IMO. But this PR should do as well :-)

Otherwise im planning to close; as it's solvable in userland by using a package base URL (coming from a custom param or so).

About the params, they are obscure things usually to users, which means very little are going to know about them and their purpose, even if it's documented.

I tend to believe people will bump into it (if documented somewhere of course) once dealing with this issue =/

can you add a changelog line to advertise the feature?
also, should we add corresponding config options? not sure, just wondering.

Changelog added; extra config is not needed IMHO; it's the same approach as routing does.

Because of that ive renamed the params to%asset.request_context.*% so it's in line with%router.request_context.*%

changelog updated. Not sure about a note in assets component; change is in no way related to that.

ping@fabpot as I guess you're the one merging on Asset?

Also im not experiencing this issue myself. Honestly thought to fixlinked issue real quick :) confirmed as it is (#19396 (comment)).

Not sure what's blocking here. However i dont wanna imply im pushing this PR or so.

edit: as this is a new feature; now polished :)

Thank you@ro0NL.