If I disable an addon does that kill it's negative effect?

[=MGN=RedEagle]

If I disable an addon does that kill it's negative effects? Is there any addon that changes the core code in such a way that it is not reversible with either disable or install options?

 

[woei]

Depends on the add-on. When installing an add-on there can be mysql queries executed that damage or alter the database. So I always test the before installing them into a live environment.

But it all depends on the add-on. Most add-ons create custom tables in your database to work and don't alter the original xenforo structure or tables, but it all depends on the add-on. So can't say it enough, test! test test

 

[=MGN=RedEagle]

Thanks! Any easy way to check for addons that alter the database?

 

[borbole]

Thanks! Any easy way to check for addons that alter the database?

All add ons that modfiy the database usually come with an install file where all the db stuff that that add on adds/modifies are added. Simply view that file to see how that particular add on affects your db.

 

[Paul B]

Ideally the developer should list any such changes in the resource description.
I do this for my add-on here: http://xenforo.com/community/resources/cta-featured-threads.2599/

Database
1 new table.
1 new column on the xf_thread table.
1 new column on the xf_user table.

If they don't, the only way to confirm is by checking the install file.

 

[Chris D]

Also, if a developer follows best practise it should never affect the database in a negative way.

Some of the best practise includes:

• Prefixing tables and columns with something unique to the developer or add-on. As we have seen, not doing this will cause clashes with other add-ons or core upgrades. As an option, you could still prefix your table with xf_ as long as something unique follows it. Tables prefixed with xf_ will be removed if a person decides to do a clean install of XenForo via the Install system.
• All changes should be removed upon uninstall with no exception. This should include removing orphaned data such as permissions, content type data (e.g. likes, attachments).
• Always include a default value on any added column. Don't just handle the default value in the DataWriter as that will only work while the add-on is enabled. Some column types do not allow a default value (e.g. BLOB), in these cases NULL should be allowed.

 

[Alpha1]

it would be nice if xenforo would force some of these best practices.

 

[Paul B]

How?

Short of writing the add-ons, how can they force developers to do things a certain way?

 

[Alpha1]

make a mandatory field in the resource manager to fill in database changes, another one for the table prefix used.
Don't allow creation of tables, fields or columns without first defining a prefix.

 

[Chris D]

The first one would be useful.

The second one is just something that cannot be controlled. Even if there was some sort of helper that did some sort of validation (that would be pretty complicated), it wouldn't prevent people still doing their own thing. It's just not possible to reliably control it.

 

[Paul B]

It also doesn't address the problem of the uninstall code correctly removing/reverting everything.

In short it comes down to individual developers to do things as well as they can, from writing the code, to creating the resource content, documenting changes, etc.

 

[RobParker]

In short it comes down to individual developers to do things as well as they can, from writing the code, to creating the resource content, documenting changes, etc.

Is there a "best practices" guide from Kier/Mike now? If not that'd surely help.

 

[Paul B]

It's basically common sense.
Any competent developer should know what to do.

The table prefix issue has been posted about numerous times, yet some developers still ignore it.
So again, any sort of guide would still be ignored by some.

 

[Alpha1]

If there would be an official guidance, then users could point developers to the guidance if they do not follow best practices. That would have some beneficial effect. In the past I have asked addon developers to apply some of the best practices listed above. But I am just an addon user with an opinion. It has much more weight if its an official practice that is expected of developers.

One thing that could be of use is to add a simple tickbox to the RM to select if the best practices guidelines have been followed. (with a link to the guidelines)
This way all addon developers are certainly aware of the best practices.

 

[=MGN=RedEagle]

If there would be an official guidance, then users could point developers to the guidance if they do not follow best practices. That would have some beneficial effect. In the past I have asked addon developers to apply some of the best practices listed above. But I am just an addon user with an opinion. It has much more weight if its an official practice that is expected of developers.

One thing that could be of use is to add a simple tickbox to the RM to select if the best practices guidelines have been followed. (with a link to the guidelines)
This way all addon developers are certainly aware of the best practices.

Good idea!