on update function in plugin.cfc question

[Glyn Jackson]

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!


Interested to hear others opinions on this.

Glyn

[Tony Garcia]

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.

-Tony

[Glyn Jackson]

> 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

[Glyn Jackson]

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?

[Greg Moser]

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.

-Greg

[Tony G]

Yeah, this is news to me. Might be worthwhile to ask the BR guys about
this.

-Tony

[Glyn Jackson]

Thanks for taking a look Tony and Greg. It does give us a few problems
in the furture. Do BR have a bug reporting system?

[Greg Moser]

This is their trac site.  http://trac.blueriver.com/mura/

-Greg

[Glyn Jackson]

cool, submitted.

I just posted what Tony said and stated that it didn't work that way.
Will see what the response is.

http://trac.blueriver.com/mura/ticket/14380

[Glyn Jackson]

Cool, looks like BR will be resolving this issue in the next update to
5.4!

ticket link: http://trac.blueriver.com/mura/ticket/14380

quote:

* status changed from new to closed
* resolution set to fixed

The behavior will be changed to fire the plugin.update() method every
time the settings are updated in 5.4

[Greg Moser]

Great, thanks for following up on this Glyn.

-Greg