Add-on developers: Why do you include an option to enable/disable your add-ons in your options?

[Chris D]

Well, I know why, obviously.

You want your users to be able to enable or disable your add-ons...

But, there really isn't any point, is there?

I would think that overall it is best practise to NOT have a separate option to disable/enable your add-ons.

Your add-on can be enabled/disabled easily enough from the home page of the Admin CP. Having further options would only confuse people, and furthermore having an option in the Admin CP doesn't actually disable your add-on properly anyway.

If you have an option to enable/disable your add-on, and you put that option in an if statement in your Listener (for example), your Listener still runs.

I'm actually looking at some code right now where someone has experienced an "Undefined index" server error in an add-on. That parameter is being checked OUTSIDE of the option check, therefore the add-on could be disabled in the options, but this error could still be occurring.

So, this thread isn't actually asking you why... It's more of a polite suggestion that perhaps you shouldn't (unless I'm missing something).

 

[Mr. Goodie2Shoes]

Well... when I first started, I added the option, but then found it totally pointless as users can just do that from Admin Home silly me

 

[Chris D]

I just thought of an instance where it might be acceptable, but there are still other things to avoid it.

Perhaps the add-on would require a massive lot of options and permissions configuring and having it enabled while doing so could cause issues. Maybe a separate option then would be appropriate?

Where it isn't appropriate is where I've just seen it being used to enable or disable a template hook that can easily be done by just disabling the add-on.

 

[James]

I wondered this myself: www.xenforo.com/community/threads/do-add-on-developers-still-create-enable-add-on-options.18139/

 

[tenants]

I just thought of an instance where it might be acceptable, but there are still other things to avoid it.

Perhaps the add-on would require a massive lot of options and permissions configuring and having it enabled while doing so could cause issues. Maybe a separate option then would be appropriate?

Where it isn't appropriate is where I've just seen it being used to enable or disable a template hook that can easily be done by just disabling the add-on.

I've not had to do it myself, but think of an addon which has merged lots of other sub-addons
It's then not possible to turn each sub-addon off from the "Installed Add-ons" page, but each sub addon could be "turned off" from their separate ACP options... generally I agree though, it's not required and in doing so you leave the listeners open

 

[SchmitzIT]

Whatever add-on I built myself had an option to enable/disable, and would have it disabled by default.

The main reason is to give the admin the opportunity to first set permissions and tweak things as wanted prior to enabling. Nothing ticks me off more than installing a new add-on and then finding it inadvertently created a new tab that has not yet been styled to my forum's regular look, and that enables absolutely everybody to do everything possible.

 

[Chris D]

I've not had to do it myself, but think of an addon which has merged lots of other sub-addons
It's then not possible to turn each sub-addon off from the "Installed Add-ons" page, but each sub addon could be "turned off" from their separate ACP options... generally I agree though, it's not required and in doing so you leave the listeners open

That's definitely a good case. But my gripe is mainly with a global "on/off" switch for the add-on which (is supposed to) disable the whole add-on.

Whatever add-on I built myself had an option to enable/disable, and would have it disabled by default.

The main reason is to give the admin the opportunity to first set permissions and tweak things as wanted prior to enabling. Nothing ticks me off more than installing a new add-on and then finding it inadvertently created a new tab that has not yet been styled to my forum's regular look, and that enables absolutely everybody to do everything possible.

That's also a good use of it.

I guess than my main annoyance is seeing it in add-ons where actually it serves pretty much no purpose at all.

For example, I was looking at an add-on earlier which had only one option in the Admin CP. There's no configuration. No permissions. Nothing. Just a template hook. And the check to see if the add-on was switched on or off was after the Listener already executed some code. So ultimately the on/off switch was less than useless.

But yeah, some good genuine uses for actually having a separate on/off switch here.

A lot of time my add-ons don't have an on/off switch as such but do automatically disable themselves under certain conditions. For example, my new one: http://xenforo.com/community/resources/social-connect-bundle.1310/ actually is automatically disabled when the API keys haven't yet been configured. So I guess this is akin to having the on/off switch set to off by default.

Also, I would definitely say as another piece of best practice an add-on developer should always ensure multiple navigation placements are set for things. i.e. yes, include a nav tab but probably have it off by default and an option to enable it if the admin wishes.