I noticed something when working with the plugin.cfc today.
It seems the 'on update' function from the plugin.cfc only gets called
when adding a new zip file. However if you edit a plug-in and change a
setting, the word 'update' is confusion. It makes me think the 'on
update' function would be called again, but not the case.
This does not give Slatwall issues when actually updating or
installing etc, however if a user decides to change their ORM
preference when not uploading a zip, it will not get executed, becuase
the 'on update' function is not called.
My question is.....
Was this behaviour BR decided on, or a bug? Personally I think this
function should get called on any update of the plugin, even if it's
just an update to a setting in the config.xml by a user. Otherwise the
plugin does not have a chance to respond to any changes the user has
made!
I think this is by design. You don't actually have to update or install with a new zip for the update to fire. If you go to the edit plugin screen (the screen where you can upload an updated zip) and just hit the "Update" button at the bottom (without even uploading a new zip), the update() function will fire. I learned this last year when I went to a Mura training and I've gotten into the habit of doing this whenever I changed any plugin config settings.
> I noticed something when working with the plugin.cfc today.
> It seems the 'on update' function from the plugin.cfc only gets called > when adding a new zip file. However if you edit a plug-in and change a > setting, the word 'update' is confusion. It makes me think the 'on > update' function would be called again, but not the case.
> This does not give Slatwall issues when actually updating or > installing etc, however if a user decides to change their ORM > preference when not uploading a zip, it will not get executed, becuase > the 'on update' function is not called.
> My question is.....
> Was this behaviour BR decided on, or a bug? Personally I think this > function should get called on any update of the plugin, even if it's > just an update to a setting in the config.xml by a user. Otherwise the > plugin does not have a chance to respond to any changes the user has > made!
> If you go to the edit plugin screen (the screen where you can upload an updated zip) and just hit the "Update" button at the bottom (without even uploading a new zip), the update() function will fire.
This is what I am staying, update does not seem to fire when doing
this. I think it should. If you edit the plugin.cfc for Slatwall add a
cfabort to the update event you will see if only gets executed when
adding a zip and then updating. if you were to just update nothing
happends for me.
If this is not the case for you then something else must be wrong for
me.
On Jan 16, 9:27 pm, Tony Garcia <t...@dreamlabsmedia.com> wrote:
> I think this is by design. You don't actually have to update or install
> with a new zip for the update to fire. If you go to the edit plugin
> screen (the screen where you can upload an updated zip) and just hit the
> "Update" button at the bottom (without even uploading a new zip), the
> update() function will fire. I learned this last year when I went to a;> Mura
training and I've gotten into the habit of doing this whenever I
> > I noticed something when working with thepluginncfcc today.
> > It seems the 'on update' function from thepluginncfcc only gets called
> > when adding a new zip file. However if you edit a plug-in and change a
> > setting, the word 'update' is confusion. It makes me think the 'on
> > update' function would be called again, but not the case.
> > This does not giveSlatwalll issues when actually updating or
> > installing etc, however if a user decides to change their ORM
> > preference when not uploading a zip, it will not get executed,becuasee
> > the 'on update' function is not called.
> > My question is.....
> > Was this behaviour BR decided on, or a bug? Personally I think this
> > function should get called on any update of thepluginn, even if it's
> > just an update to a setting in theconfiggxmll by a user. Otherwise the
> >pluginn does not have a chance to respond to any changes the user has
> > made!
tested again by adding a var that does not exist into the update
function of plugin.cfc. reloaded the app edited the plugin then
clicked update. I did not get an error. this would make my think the
update function did not run. do the samething with a zip file and on
update you get an error (as it should). to me it looks like it does
not get run on update without adding a zip file. it this not the same
for you?
On Jan 16, 9:38 pm, Glyn Jackson <cfspa...@gmail.com> wrote:
> > If you go to the edit plugin screen (the screen where you can upload an updated zip) and just hit the "Update" button at the bottom (without even uploading a new zip), the update() function will fire.
> This is what I am staying, update does not seem to fire when doing
> this. I think it should. If you edit the plugin.cfc for Slatwall add a
> cfabort to the update event you will see if only gets executed when
> adding a zip and then updating. if you were to just update nothing
> happends for me.
> If this is not the case for you then something else must be wrong for
> me.
> On Jan 16, 9:27 pm, Tony Garcia <t...@dreamlabsmedia.com> wrote:> I think this is by design. You don't actually have to update or install
> > with a new zip for the update to fire. If you go to the edit plugin
> > screen (the screen where you can upload an updated zip) and just hit the
> > "Update" button at the bottom (without even uploading a new zip), the
> > update() function will fire. I learned this last year when I went to a;> Mura
> training and I've gotten into the habit of doing this whenever I
> > changed anypluginnconfigg settings.
> > -Tony
> > On 1/16/11 4:13 PM, Glyn Jackson wrote:
> > > I noticed something when working with thepluginncfcc today.
> > > It seems the 'on update' function from thepluginncfcc only gets called
> > > when adding a new zip file. However if you edit a plug-in and change a
> > > setting, the word 'update' is confusion. It makes me think the 'on
> > > update' function would be called again, but not the case.
> > > This does not giveSlatwalll issues when actually updating or
> > > installing etc, however if a user decides to change their ORM
> > > preference when not uploading a zip, it will not get executed,becuasee
> > > the 'on update' function is not called.
> > > My question is.....
> > > Was this behaviour BR decided on, or a bug? Personally I think this
> > > function should get called on any update of thepluginn, even if it's
> > > just an update to a setting in theconfiggxmll by a user. Otherwise the
> > >pluginn does not have a chance to respond to any changes the user has
> > > made!
I also just verified that this was the case. I added writeDump(request); abort; to the update function, and it only worked when uploading a new zip. Initially I thought that this issue was because the plugin.cfc got cached in the application scope until you uploaded a new zip file, and that was why your error wasn't showing up because it was calling the function out of cache before the var was set. However I did a test where in the update function I put:
application.timetest = now();
and then dumped the application scope in my default view. Even after this new plugin.cfc got cached (or didn't) if i just hit the update button it is not updating the application.timetest varaible.
That being said, I originally thought that it worked the way that tony said. Maybe the guys at BR changed this for some reason.
> I also just verified that this was the case. I added writeDump(request);
> abort; to the update function, and it only worked when uploading a new zip.
> Initially I thought that this issue was because the plugin.cfc got cached
> in the application scope until you uploaded a new zip file, and that was why
> your error wasn't showing up because it was calling the function out of
> cache before the var was set. However I did a test where in the update
> function I put:
> application.timetest = now();
> and then dumped the application scope in my default view. Even after this
> new plugin.cfc got cached (or didn't) if i just hit the update button it is
> not updating the application.timetest varaible.
> That being said, I originally thought that it worked the way that tony said.
> Maybe the guys at BR changed this for some reason.
> Yeah, this is news to me. Might be worthwhile to ask the BR guys about
> this.
> -Tony
> On Jan 17, 12:03 pm, Greg Moser <gregjmo...@gmail.com> wrote:
> > Hey Glyn,
> > I also just verified that this was the case. I added writeDump(request);
> > abort; to the update function, and it only worked when uploading a new zip.
> > Initially I thought that this issue was because the plugin.cfc got cached
> > in the application scope until you uploaded a new zip file, and that was why
> > your error wasn't showing up because it was calling the function out of
> > cache before the var was set. However I did a test where in the update
> > function I put:
> > application.timetest = now();
> > and then dumped the application scope in my default view. Even after this
> > new plugin.cfc got cached (or didn't) if i just hit the update button it is
> > not updating the application.timetest varaible.
> > That being said, I originally thought that it worked the way that tony said.
> > Maybe the guys at BR changed this for some reason.
