Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add notes about assets' version #688

Closed
jalliot opened this issue Sep 8, 2011 · 4 comments
Closed

Add notes about assets' version #688

jalliot opened this issue Sep 8, 2011 · 4 comments

Comments

@jalliot
Copy link
Contributor

jalliot commented Sep 8, 2011

At the moment, there is absolutely no information about these options in the doc:

  • framework.templating.assets_version
  • framework.templating.assets_version_format (which defaults to %s?%s in Symfony\Component\Templating\Asset\Package so that URLs look like my_asset.xyz?version)

Notes about those options should be added at least in these places:

These notes should explain what those options are for (basically versionning assets in a project for cache busting) and could link to something like this.

It should also be reminded (clear warning) to bump the assets version in the config file each time we deploy a new version of the assets in production.

@weaverryan
Copy link
Member

Thanks for the very thorough description - this has indeed been missing for two long. We'll also need to document the related packages and base URL options. The reference section as a whole is probably next for me.

Thanks!

@jalliot
Copy link
Contributor Author

jalliot commented Sep 9, 2011

This is great Ryan :)

Just one thing, the default %s?%s for framework.templating.assets_version_format is not set in the DIC but statically inside Symfony\Component\Templating\Asset\Package::__construct(). I'm not sure you should change the default null from the reference (or better we should change this default value to be set in the DIC extension).
What do you think?

@weaverryan
Copy link
Member

I've debated this myself. I think what I have is technically wrong, but very practically right. I'm inclined to stick with showing them the "practical" default, until/unless someone can give me a really good argument on why not to.

Thanks!

@jalliot
Copy link
Contributor Author

jalliot commented Sep 9, 2011

Fine by me ;)

@fabpot What do you think about moving the default value from the parameters of the constructor to the FrameworkBundle configuration extension? Something like that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants