*To overwrite a template provided by another Bundle with #Symfony2 just create a Resources/views/TheOtherBundle/mytpl.twig in your Bundle.*
I haven't tested it, but haven't found any documentation on it.
*Symfony2 should allow us to overwrite any file in the Resources folder of a Bundle* (views, public, doc, config ..). This will allow us to create some "abstract" bundles wich can be overwritten easily.
For example i often create new projects so i allways start with the same bundle and start modifing files in the Resources folder (views, config etc ..). What i want to be able to do is: - to have for each of my projects a *CommonBundle* with lots of files in Resources folder. - a bundle in the Application folder who *overwrites* *files* (under Resources folder)* of my CommonBundle*.
So, this will work, but not exactly how you're asking. The Resources files is just a convenient way of grouping files that come from a variety of *very* different systems - templates, configuration, css/js assets, translations, etc. Documentation on overriding in general (especially overriding by placing things in your `app` dir) is forthcoming.
So, I'm not sure if it's totally feasible. But I defer to others.
In a related note, I started to write how all of this could be done, but quickly found myself in a pickle. Namely, I think a lot of making one bundle override portions of another comes down to the order in which they're initialized in AppKernel. But thinking now, I feel like you'd need to put bundle A before bundle B (they'd need the same actual bundle names to override templates) to override its templates, but you'd need bundle A *after* bundle B to override its configuration and translations. I *could* be wrong here - quick somebody try it!
> *To overwrite a template provided by another Bundle with #Symfony2 just > create a Resources/views/TheOtherBundle/mytpl.twig in your Bundle.*
> I haven't tested it, but haven't found any documentation on it.
> *Symfony2 should allow us to overwrite any file in the Resources folder of > a Bundle* (views, public, doc, config ..). This will allow us to create > some "abstract" bundles wich can be overwritten easily.
> For example i often create new projects so i allways start with the same > bundle and start modifing files in the Resources folder (views, config etc > ..). What i want to be able to do is: > - to have for each of my projects a *CommonBundle* with lots of files in > Resources folder. > - a bundle in the Application folder who *overwrites* *files* (under > Resources folder)* of my CommonBundle*.
> Is it enough clear ?
> -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com
> You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to symfony-devs@googlegroups.com > To unsubscribe from this group, send email to > symfony-devs+unsubscribe@googlegroups.com<symfony-devs%2Bunsubscribe@google groups.com> > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en
> So, this will work, but not exactly how you're asking. The Resources > files is just a convenient way of grouping files that come from a > variety of *very* different systems - templates, configuration, css/js > assets, translations, etc. Documentation on overriding in general > (especially overriding by placing things in your `app` dir) is > forthcoming.
> So, I'm not sure if it's totally feasible. But I defer to others.
> In a related note, I started to write how all of this could be done, > but quickly found myself in a pickle. Namely, I think a lot of making > one bundle override portions of another comes down to the order in > which they're initialized in AppKernel. But thinking now, I feel like > you'd need to put bundle A before bundle B (they'd need the same > actual bundle names to override templates) to override its templates, > but you'd need bundle A *after* bundle B to override its configuration > and translations. I *could* be wrong here - quick somebody try it!
You don't need to declare the bundle in AppKernel to override templates. For rendering a template for Hellobundle the templating component will look at a HelloBundle directory under app/views and then under each of the bundle dirs (so Application first then Bundle and finally vendor/symfony/src/Symfony/Bundle if you use the sandbox configuration)
> Sometimes ago i have seen a tweet: > To overwrite a template provided by another Bundle with #Symfony2 just create a Resources/views/TheOtherBundle/mytpl.twig in your Bundle. > I haven't tested it, but haven't found any documentation on it.
> Symfony2 should allow us to overwrite any file in the Resources folder of a Bundle (views, public, doc, config ..). This will allow us to create some "abstract" bundles wich can be overwritten easily.
> For example i often create new projects so i allways start with the same bundle and start modifing files in the Resources folder (views, config etc ..). What i want to be able to do is: > - to have for each of my projects a CommonBundle with lots of files in Resources folder. > - a bundle in the Application folder who overwrites files (under Resources folder) of my CommonBundle.
> Is it enough clear ?
So views are already covered. And config stuff should be handled by the Bundles Extension class. Public is a question of what you use in your templates (and for other stuff it should be configurable) and those can be overridden. Doc's aren't interpreted so there is no need to override them
>> Sometimes ago i have seen a tweet: >> To overwrite a template provided by another Bundle with #Symfony2 just create a Resources/views/TheOtherBundle/mytpl.twig in your Bundle. >> I haven't tested it, but haven't found any documentation on it.
>> Symfony2 should allow us to overwrite any file in the Resources folder of a Bundle (views, public, doc, config ..). This will allow us to create some "abstract" bundles wich can be overwritten easily.
>> For example i often create new projects so i allways start with the same bundle and start modifing files in the Resources folder (views, config etc ..). What i want to be able to do is: >> - to have for each of my projects a CommonBundle with lots of files in Resources folder. >> - a bundle in the Application folder who overwrites files (under Resources folder) of my CommonBundle.
>> Is it enough clear ? > So views are already covered. > And config stuff should be handled by the Bundles Extension class. > Public is a question of what you use in your templates (and for other stuff it should be configurable) and those can be overridden. > Doc's aren't interpreted so there is no need to override them
> So I am not sure what is really needed more?
> regards, > Lukas Kahwe Smith > m...@pooteeweet.org
meta for the License file :) but this is the same as docs. There is nothing more in the best practices.
> What I'm searching now, is to overwrite a file under public folder.
> For example i have a template which use a logo image under public folder. I want to overwrite the logo to use my own, i have two solutions: > - overwrite the view with my new logo (long and not reusable) > - overwrite the logo image under the public folder
> The second solution is better than the first one.
I guess we could consider adding some logic to the install asset CLI command to handle this.
>> What I'm searching now, is to overwrite a file under public folder.
>> For example i have a template which use a logo image under public folder. I want to overwrite the logo to use my own, i have two solutions: >> - overwrite the view with my new logo (long and not reusable) >> - overwrite the logo image under the public folder
>> The second solution is better than the first one. > I guess we could consider adding some logic to the install asset CLI command to handle this.
> regards, > Lukas Kahwe Smith > m...@pooteeweet.org
This can be easily achieved when making a copy of the assets but I don't see how it could work when using the --symlink option.
> Le 06/01/2011 12:35, Lukas Kahwe Smith a écrit : >> On 06.01.2011, at 12:15, gordonslondon wrote:
>>> Good to see that some solutions already exist.
>>> What I'm searching now, is to overwrite a file under public folder.
>>> For example i have a template which use a logo image under public folder. I want to overwrite the logo to use my own, i have two solutions: >>> - overwrite the view with my new logo (long and not reusable) >>> - overwrite the logo image under the public folder
>>> The second solution is better than the first one. >> I guess we could consider adding some logic to the install asset CLI command to handle this.
>> regards, >> Lukas Kahwe Smith >> m...@pooteeweet.org
> This can be easily achieved when making a copy of the assets but I don't see how it could work when using the --symlink option.
Maybe instead of symlink we should use mod_rewrite handling magic?
>> This can be easily achieved when making a copy of the assets but I don't see how it could work when using the --symlink option.
> Maybe instead of symlink we should use mod_rewrite handling magic?
mod_rewrite isn't possible, you could dynamically define Aliases to paths, but that's essentially the same as symlink, and defining aliases to files would fix it but it is just crazy you'd have potentially hundreds of aliases in your .htaccess.
> On 06.01.2011 12:48, Lukas Kahwe Smith wrote: >>> This can be easily achieved when making a copy of the assets but I don't see how it could work when using the --symlink option.
>> Maybe instead of symlink we should use mod_rewrite handling magic?
> mod_rewrite isn't possible, you could dynamically define Aliases to > paths, but that's essentially the same as symlink, and defining aliases > to files would fix it but it is just crazy you'd have potentially > hundreds of aliases in your .htaccess.
How so? mod_rewrite would first check if the file exists in the Application dir and if not fallback to the Bundle dir.
>> On 06.01.2011 12:48, Lukas Kahwe Smith wrote: >>>> This can be easily achieved when making a copy of the assets but I don't see how it could work when using the --symlink option.
>>> Maybe instead of symlink we should use mod_rewrite handling magic?
>> mod_rewrite isn't possible, you could dynamically define Aliases to >> paths, but that's essentially the same as symlink, and defining aliases >> to files would fix it but it is just crazy you'd have potentially >> hundreds of aliases in your .htaccess.
> How so? > mod_rewrite would first check if the file exists in the Application dir and if not fallback to the Bundle dir.
AFAIK mod_rewrite only rewrites the URL, if the file is not in a publicly accessible dir, it won't work, and you don't want to have your entire src/ accessible from the web.
>>> On 06.01.2011 12:48, Lukas Kahwe Smith wrote: >>>>> This can be easily achieved when making a copy of the assets but I don't see how it could work when using the --symlink option.
>>>> Maybe instead of symlink we should use mod_rewrite handling magic?
>>> mod_rewrite isn't possible, you could dynamically define Aliases to >>> paths, but that's essentially the same as symlink, and defining aliases >>> to files would fix it but it is just crazy you'd have potentially >>> hundreds of aliases in your .htaccess.
>> How so? >> mod_rewrite would first check if the file exists in the Application dir and if not fallback to the Bundle dir.
> AFAIK mod_rewrite only rewrites the URL, if the file is not in a > publicly accessible dir, it won't work, and you don't want to have your > entire src/ accessible from the web.
ok for production you want to copy. so this is really only a dev issue. so you would symlink both dirs.
all links would have to point to the application version and fallback to the bundle version or something like that.
i am pretty sure it can be done .. but will require some fiddeling and it will potentially feel a bit iffy.
>> On 06.01.2011 14:31, Lukas Kahwe Smith wrote: >>> On 06.01.2011, at 14:28, Jordi Boggiano wrote:
>>>> On 06.01.2011 12:48, Lukas Kahwe Smith wrote: >>>>>> This can be easily achieved when making a copy of the assets but I don't see how it could work when using the --symlink option.
>>>>> Maybe instead of symlink we should use mod_rewrite handling magic? >>>> mod_rewrite isn't possible, you could dynamically define Aliases to >>>> paths, but that's essentially the same as symlink, and defining aliases >>>> to files would fix it but it is just crazy you'd have potentially >>>> hundreds of aliases in your .htaccess.
>>> How so? >>> mod_rewrite would first check if the file exists in the Application dir and if not fallback to the Bundle dir. >> AFAIK mod_rewrite only rewrites the URL, if the file is not in a >> publicly accessible dir, it won't work, and you don't want to have your >> entire src/ accessible from the web.
> ok for production you want to copy. so this is really only a dev issue. > so you would symlink both dirs.
> all links would have to point to the application version and fallback to the bundle version or something like that.
> i am pretty sure it can be done .. but will require some fiddeling and it will potentially feel a bit iffy.
> regards, > Lukas Kahwe Smith > m...@pooteeweet.org
the symlink option makes a symlink to the public folder currently. How would you do such a fallback ? A symlink cannot be changed on the fly
>>> On 06.01.2011, at 14:28, Jordi Boggiano wrote:
>>>> On 06.01.2011 12:48, Lukas Kahwe Smith wrote: >>>>>> This can be easily achieved when making a copy of the assets but I don't see how it could work when using the --symlink option.
>>>>> Maybe instead of symlink we should use mod_rewrite handling magic?
>>>> mod_rewrite isn't possible, you could dynamically define Aliases to >>>> paths, but that's essentially the same as symlink, and defining aliases >>>> to files would fix it but it is just crazy you'd have potentially >>>> hundreds of aliases in your .htaccess.
>>> How so? >>> mod_rewrite would first check if the file exists in the Application dir and if not fallback to the Bundle dir.
>> AFAIK mod_rewrite only rewrites the URL, if the file is not in a >> publicly accessible dir, it won't work, and you don't want to have your >> entire src/ accessible from the web.
> ok for production you want to copy. so this is really only a dev issue. > so you would symlink both dirs.
> all links would have to point to the application version and fallback to the bundle version or something like that.
> i am pretty sure it can be done .. but will require some fiddeling and it will potentially feel a bit iffy.
The less hacky way would be to say that if you use --symlink, if a dir is present in both Application and Bundle, only Application is symlinked, therefore you would just have to copy all assets if you want to edit one.
> - The convention to overwrite a *Bundle\FooBundle* will be to create a > *Application\FooBundle* ? > - When calling {{ asset('FooBundle:file.jpg') }} it will first check > if /file.jpg/ exists in *Application\FooBundle*, if not take the one > from *Bundle\FooBundle* ?
> +1 It's a good solution, that sound great !
+1 This seems good. Thus it is consistent with the way to override templates.
> ok, i've just checked and we can already overwrite public files (work both, with and without --symlink option).
> If Application\HelloBundle needs to overwrite Bundle\HelloBundle: > • views: Application\HelloBundle before Bundle\HelloBundle. > • config: Application\HelloBundle before Bundle\HelloBundle.
those i know
> • public: Application\HelloBundle after Bundle\HelloBundle
If two bundles with the same name are registered (i've tested with one in Application and the other in Bundle), when installing assets (php console assets:install) the last bundle registered will overwrite public files of the first one.
On 14.01.2011, at 17:51, gordonslondon <jules.boussek...@gmail.com> wrote:
> If two bundles with the same name are registered (i've tested with one in Application and the other in Bundle), > when installing assets (php console assets:install) the last bundle registered will overwrite public files of the first one.
> It works both with and without --symlink option.
files or directories? aka i think the app might replace the entire public dir. aka you would first have to copy the bundles public dir into the app dir and then overwrite the files you actually want to replace.
what jordi last suggested was a solution to be able to skip the copy step.
I think only files that exists in both bundles should be overwritten, the others are kept (current behavior).
Maybe i don't understand what you want to say. Do you mean that the logic should be done when calling assets helper instead of assets:install command ?
> I think only files that exists in both bundles should be overwritten, the others are kept (current behavior).
> Maybe i don't understand what you want to say. > Do you mean that the logic should be done when calling assets helper instead of assets:install command ?
vi src/Application/FOS/UserBundle/Resources/public/foo.txt -> set content to 'foo' touch src/Application/FOS/UserBundle/Resources/public/c.png
vi src/Bundle/FOS/UserBundle/Resources/public/foo.txt -> set content to 'dong dong' touch src/Bundle/FOS/UserBundle/Resources/public/b.png
php app/main/console_dev assets:install --symlink web
Plus adding any file to either place would immediately be available when using the symlink option.
(*) I am saying effectively because in reality the files would be in different locations and the "magic" would be done via the asset helpers. Though I would limit this to just to just symlink mode. When using copy imho everything should be merged into one dir.
Your result: "web/bundles/user/foo.txt (content 'dong dong foo')" Not the same for me. It gives me:
If the bundle in Application is registered *after* the one in Bundle: - web/bundles/user/foo.txt (content 'foo') - web/bundles/user/b.png - web/bundles/user/c.png
If the bundle in Application is registered *before* the one in Bundle: - web/bundles/user/foo.txt (content 'dong dong') - web/bundles/user/b.png - web/bundles/user/c.png
(have you an idea on why i don't get the same result ?)
> Your result: "web/bundles/user/foo.txt (content 'dong dong foo')" > Not the same for me. It gives me:
> If the bundle in Application is registered after the one in Bundle: > - web/bundles/user/foo.txt (content 'foo') > - web/bundles/user/b.png > - web/bundles/user/c.png
> If the bundle in Application is registered before the one in Bundle: > - web/bundles/user/foo.txt (content 'dong dong') > - web/bundles/user/b.png > - web/bundles/user/c.png
> (have you an idea on why i don't get the same result ?)
Did you symlink or copy? Its technically impossible to have to symlinks overlap.
Excuse me for digging up this old topic, but this was the only discussion I found regarding overwriting assets.
I want to extend a Bundle (let's say Foo/BarBundle) to overwrite some images and stylesheets, but it's not possible to use the same name for the extended bundle, because the names must be different when extending (see Kernel::initializeBundles, line 473). And when using a different name, the command 'assets:install' places the image in another folder which is not referenced by the twig template.
Can someone explain how you did the trick?
Besides that, is it possible to extend the Twig's asset() function to look in the correct folder of the extended Bundle?
Op zaterdag 15 januari 2011 12:21:34 UTC+1 schreef gordonslondon het volgende:
