Hi everybody, yesterday I moved the current Javascript stuff to a plugin, and didn't notice an error that comes up on my new machine: The Javascript assets are missing. I didn't notice it yesterday, because my /sf alias in the htaccess was still there (but pointing to an 1.0 release :-)) Currently plugins will copy their assets on windows when using the plugin installation, while un *nix systems it tries a symlink. But there is no installation for core plugins. This made me come up with a new idea: We enhance the clear-cache task in a way, that it deletes the plugins asset directory in web folder and then recollects all assets from symfony core, symfony core plugins and optional plugis that are installed and copies them over.
The pros are that this would work quite easily and help my current issue, It would avoid some of the trac tickets that delt with plugin assets in windows, it would also help updating plugins that you get via svn (where the assets are a manual step at the moment)
The cons are limited, at the moment I can see only backwards compatibility issues with regard to how the actual path to the JS/CSS is used in the plugins, but I guess with some deeper investigations this can be solved. A slightly less BC problematic solution would be to do that only for core plugins. The advantage of that wold be that the path is known (its the sf prefixed one) , but it looks a bit inconsistent for me.
As Jonathan is currently working on the deploy task, we could try to think about implications of the old and the new behaviour for deploying. Afaik the symlink recreation on deployment was also an issue in the past.
Hope you have some good inputs.
@Fabien, any other idea how to solve the data directory issue for core plugins?
I think it's a good idea to create a task for that, but I'm not sure we want to do it in the cache:clear task. It has nothing to do with clearind the cache and on windows, it will add a large overhead if you have a lot of plugins with a lot of assets to be copied to the web/ directory.
Fabian Lange wrote: > Hi everybody, > yesterday I moved the current Javascript stuff to a plugin, and didn't > notice an error that comes up on my new machine: The Javascript assets > are missing. I didn't notice it yesterday, because my /sf alias in the > htaccess was still there (but pointing to an 1.0 release :-)) > Currently plugins will copy their assets on windows when using the > plugin installation, while un *nix systems it tries a symlink. > But there is no installation for core plugins. > This made me come up with a new idea: > We enhance the clear-cache task in a way, that it deletes the plugins > asset directory in web folder and then recollects all assets from > symfony core, symfony core plugins and optional plugis that are > installed and copies them over.
> The pros are that this would work quite easily and help my current issue, > It would avoid some of the trac tickets that delt with plugin assets in > windows, > it would also help updating plugins that you get via svn (where the > assets are a manual step at the moment)
> The cons are limited, at the moment I can see only backwards > compatibility issues with regard to how the actual path to the JS/CSS is > used in the plugins, but I guess with some deeper investigations this > can be solved. > A slightly less BC problematic solution would be to do that only for > core plugins. The advantage of that wold be that the path is known (its > the sf prefixed one) , but it looks a bit inconsistent for me.
> As Jonathan is currently working on the deploy task, we could try to > think about implications of the old and the new behaviour for deploying. > Afaik the symlink recreation on deployment was also an issue in the past.
> Hope you have some good inputs.
> @Fabien, any other idea how to solve the data directory issue for core > plugins?
I am fine with a new task, but I just thought that the semantics are similar. The cache, although not built autmatically for web assets is in the web directory, while the "uncached" version is in the plugin directory.
something like "reload assets"? .: Fabian
On Thu, Jul 3, 2008 at 8:44 AM, Fabien Potencier <
> I think it's a good idea to create a task for that, but I'm not sure we > want to do it in the cache:clear task. It has nothing to do with > clearind the cache and on windows, it will add a large overhead if you > have a lot of plugins with a lot of assets to be copied to the web/ > directory.
> Fabian Lange wrote: > > Hi everybody, > > yesterday I moved the current Javascript stuff to a plugin, and didn't > > notice an error that comes up on my new machine: The Javascript assets > > are missing. I didn't notice it yesterday, because my /sf alias in the > > htaccess was still there (but pointing to an 1.0 release :-)) > > Currently plugins will copy their assets on windows when using the > > plugin installation, while un *nix systems it tries a symlink. > > But there is no installation for core plugins. > > This made me come up with a new idea: > > We enhance the clear-cache task in a way, that it deletes the plugins > > asset directory in web folder and then recollects all assets from > > symfony core, symfony core plugins and optional plugis that are > > installed and copies them over.
> > The pros are that this would work quite easily and help my current issue, > > It would avoid some of the trac tickets that delt with plugin assets in > > windows, > > it would also help updating plugins that you get via svn (where the > > assets are a manual step at the moment)
> > The cons are limited, at the moment I can see only backwards > > compatibility issues with regard to how the actual path to the JS/CSS is > > used in the plugins, but I guess with some deeper investigations this > > can be solved. > > A slightly less BC problematic solution would be to do that only for > > core plugins. The advantage of that wold be that the path is known (its > > the sf prefixed one) , but it looks a bit inconsistent for me.
> > As Jonathan is currently working on the deploy task, we could try to > > think about implications of the old and the new behaviour for deploying. > > Afaik the symlink recreation on deployment was also an issue in the past.
> > Hope you have some good inputs.
> > @Fabien, any other idea how to solve the data directory issue for core > > plugins?
> I am fine with a new task, but I just thought that the semantics are
> similar.
> The cache, although not built autmatically for web assets is in the web
> directory, while the "uncached" version is in the plugin directory.
> something like "reload assets"?
> .: Fabian
> On Thu, Jul 3, 2008 at 8:44 AM, Fabien Potencier <
> > I think it's a good idea to create a task for that, but I'm not sure we
> > want to do it in the cache:clear task. It has nothing to do with
> > clearind the cache and on windows, it will add a large overhead if you
> > have a lot of plugins with a lot of assets to be copied to the web/
> > directory.
> > Fabian Lange wrote:
> > > Hi everybody,
> > > yesterday I moved the current Javascript stuff to a plugin, and didn't
> > > notice an error that comes up on my new machine: The Javascript assets
> > > are missing. I didn't notice it yesterday, because my /sf alias in the
> > > htaccess was still there (but pointing to an 1.0 release :-))
> > > Currently plugins will copy their assets on windows when using the
> > > plugin installation, while un *nix systems it tries a symlink.
> > > But there is no installation for core plugins.
> > > This made me come up with a new idea:
> > > We enhance the clear-cache task in a way, that it deletes the plugins
> > > asset directory in web folder and then recollects all assets from
> > > symfony core, symfony core plugins and optional plugis that are
> > > installed and copies them over.
> > > The pros are that this would work quite easily and help my current issue,
> > > It would avoid some of the trac tickets that delt with plugin assets in
> > > windows,
> > > it would also help updating plugins that you get via svn (where the
> > > assets are a manual step at the moment)
> > > The cons are limited, at the moment I can see only backwards
> > > compatibility issues with regard to how the actual path to the JS/CSS is
> > > used in the plugins, but I guess with some deeper investigations this
> > > can be solved.
> > > A slightly less BC problematic solution would be to do that only for
> > > core plugins. The advantage of that wold be that the path is known (its
> > > the sf prefixed one) , but it looks a bit inconsistent for me.
> > > As Jonathan is currently working on the deploy task, we could try to
> > > think about implications of the old and the new behaviour for deploying.
> > > Afaik the symlink recreation on deployment was also an issue in the past.
> > > Hope you have some good inputs.
> > > @Fabien, any other idea how to solve the data directory issue for core
> > > plugins?
Okay, valid point. If I would make such a task, could we integrate it into the plugin installation procedure? Would we need two versions of this Task then? One that installs all, and on that installs only for the given plugin?
Does anyone see a problem replacing the current plugin web asset procedure with this? .: Fabian
On Thu, Jul 3, 2008 at 12:07 PM, markus.staab <markus.st...@redaxo.de> wrote:
> i also think a new task would be the better way...
> because if people edit the assets in their webfolder and start the > clear-cache task all the custom code would be overriden by the default > assets
> On 3 Jul., 08:48, "Fabian Lange" <fabian.la...@symfony-project.com> > wrote: > > I am fine with a new task, but I just thought that the semantics are > > similar. > > The cache, although not built autmatically for web assets is in the web > > directory, while the "uncached" version is in the plugin directory.
> > something like "reload assets"? > > .: Fabian
> > On Thu, Jul 3, 2008 at 8:44 AM, Fabien Potencier <
> > > I think it's a good idea to create a task for that, but I'm not sure we > > > want to do it in the cache:clear task. It has nothing to do with > > > clearind the cache and on windows, it will add a large overhead if you > > > have a lot of plugins with a lot of assets to be copied to the web/ > > > directory.
> > > Fabian Lange wrote: > > > > Hi everybody, > > > > yesterday I moved the current Javascript stuff to a plugin, and > didn't > > > > notice an error that comes up on my new machine: The Javascript > assets > > > > are missing. I didn't notice it yesterday, because my /sf alias in > the > > > > htaccess was still there (but pointing to an 1.0 release :-)) > > > > Currently plugins will copy their assets on windows when using the > > > > plugin installation, while un *nix systems it tries a symlink. > > > > But there is no installation for core plugins. > > > > This made me come up with a new idea: > > > > We enhance the clear-cache task in a way, that it deletes the plugins > > > > asset directory in web folder and then recollects all assets from > > > > symfony core, symfony core plugins and optional plugis that are > > > > installed and copies them over.
> > > > The pros are that this would work quite easily and help my current > issue, > > > > It would avoid some of the trac tickets that delt with plugin assets > in > > > > windows, > > > > it would also help updating plugins that you get via svn (where the > > > > assets are a manual step at the moment)
> > > > The cons are limited, at the moment I can see only backwards > > > > compatibility issues with regard to how the actual path to the JS/CSS > is > > > > used in the plugins, but I guess with some deeper investigations this > > > > can be solved. > > > > A slightly less BC problematic solution would be to do that only for > > > > core plugins. The advantage of that wold be that the path is known > (its > > > > the sf prefixed one) , but it looks a bit inconsistent for me.
> > > > As Jonathan is currently working on the deploy task, we could try to > > > > think about implications of the old and the new behaviour for > deploying. > > > > Afaik the symlink recreation on deployment was also an issue in the > past.
> > > > Hope you have some good inputs.
> > > > @Fabien, any other idea how to solve the data directory issue for > core > > > > plugins?
Fabian Lange wrote: > Okay, valid point. > If I would make such a task, could we integrate it into the plugin > installation procedure? > Would we need two versions of this Task then? One that installs all, and > on that installs only for the given plugin?
You only need one task with one optional argument.
If you provide an argument, this is the plugin for which you want to install/fix web assets.
With no argument, you want to install/fix web assets for all plugins.
> Does anyone see a problem replacing the current plugin web asset > procedure with this?
You don't really replace the current procedure. You refactor the existing code by extracting the web asset part to make a new task and call it from the old code.
> On Thu, Jul 3, 2008 at 12:07 PM, markus.staab <markus.st...@redaxo.de > <mailto:markus.st...@redaxo.de>> wrote:
> i also think a new task would be the better way...
> because if people edit the assets in their webfolder and start the > clear-cache task all the custom code would be overriden by the default > assets
> On 3 Jul., 08:48, "Fabian Lange" <fabian.la...@symfony-project.com > <mailto:fabian.la...@symfony-project.com>> > wrote: > > I am fine with a new task, but I just thought that the semantics are > > similar. > > The cache, although not built autmatically for web assets is in > the web > > directory, while the "uncached" version is in the plugin directory.
> > something like "reload assets"? > > .: Fabian
> > On Thu, Jul 3, 2008 at 8:44 AM, Fabien Potencier <
> > > I think it's a good idea to create a task for that, but I'm not > sure we > > > want to do it in the cache:clear task. It has nothing to do with > > > clearind the cache and on windows, it will add a large overhead > if you > > > have a lot of plugins with a lot of assets to be copied to the web/ > > > directory.
> > > Fabian Lange wrote: > > > > Hi everybody, > > > > yesterday I moved the current Javascript stuff to a plugin, > and didn't > > > > notice an error that comes up on my new machine: The > Javascript assets > > > > are missing. I didn't notice it yesterday, because my /sf > alias in the > > > > htaccess was still there (but pointing to an 1.0 release :-)) > > > > Currently plugins will copy their assets on windows when > using the > > > > plugin installation, while un *nix systems it tries a symlink. > > > > But there is no installation for core plugins. > > > > This made me come up with a new idea: > > > > We enhance the clear-cache task in a way, that it deletes the > plugins > > > > asset directory in web folder and then recollects all assets from > > > > symfony core, symfony core plugins and optional plugis that are > > > > installed and copies them over.
> > > > The pros are that this would work quite easily and help my > current issue, > > > > It would avoid some of the trac tickets that delt with plugin > assets in > > > > windows, > > > > it would also help updating plugins that you get via svn > (where the > > > > assets are a manual step at the moment)
> > > > The cons are limited, at the moment I can see only backwards > > > > compatibility issues with regard to how the actual path to > the JS/CSS is > > > > used in the plugins, but I guess with some deeper > investigations this > > > > can be solved. > > > > A slightly less BC problematic solution would be to do that > only for > > > > core plugins. The advantage of that wold be that the path is > known (its > > > > the sf prefixed one) , but it looks a bit inconsistent for me.
> > > > As Jonathan is currently working on the deploy task, we could > try to > > > > think about implications of the old and the new behaviour for > deploying. > > > > Afaik the symlink recreation on deployment was also an issue > in the past.
> > > > Hope you have some good inputs.
> > > > @Fabien, any other idea how to solve the data directory issue > for core > > > > plugins?
Hi, I just worked on this issue and think I have a good solution:
You don't really replace the current procedure. You refactor the
> existing code by extracting the web asset part to make a new task and > call it from the old code.
I chose an even better way (at least I think its better :-)). I left the current code intact and just added a new plugin-task: plugin:configure-core The only purpose of this task is to iterate over the core plugins and send the plugin.post_install event. I introduced a "sourceDirectory" parameter for this event so that the PluginManager can now use a different directory rather than the current plugin installation directory if requested.
It works fine for the use cases I had in mind and is a very lightweigth solution. And it is extensible as well. If we need some more "plugin general" post installation steps, we can just add them in sfSymfonyPluginManager.class#ListenToPluginPostInstall()
I have not started calling this task from the create project/upgrade tasks, because I first want to let you review this task and check if it is a good idea to do so.
If required we could refactor it to a general "rerun post install for all plugins" invoker task.
|
