Well-known member

That serves no purpose. People can already view and not download them. They ought to be moved to an archive where people using them can download at their own risk. Otherwise it screws current users who don't have a copy.

A developer dies it doesn't make their work useless Just means some editing is needed.

Well-known member

I was talking free ones. Of course the paid ones are out of your download control. They technically can still be bought even once delisted as long as the site that has it is running. I don't discount the idea of callbacks in free addons. How else do you find the domains of people running your plugins to see if they removed branding without permission? Seems too unpopular to risk adding though.

Well-known member

I don't discount the idea of callbacks in free addons. How else do you find the domains of people running your plugins to see if they removed branding without permission? Seems too unpopular to risk adding though.

Well-known member

If a resource listing links to an external site for purchase/download and the addon/resource does not meet XF guidelines, will it also be removed from XF resources?
Eg. XF resources states purpose and description. I click link to go to developers site and purchase. If the developers site lists that it has callbacks, will it be removed from XF resource listing because it doesn't state it has callbacks

Well-known member

If a resource listing links to an external site for purchase/download and the addon/resource does not meet XF guidelines, will it also be removed from XF resources?
Eg. XF resources states purpose and description. I click link to go to developers site and purchase. If the developers site lists that it has callbacks, will it be removed from XF resource listing because it doesn't state it has callbacks

XenForo moderator

For the avoidance of doubt, to comply with clause 4, all that needs to be added to the main resource description is something similar to the following:

"This add-on performs a callback to an external server during installation, for validation against a third-party database. "

If callbacks are also required when in use, for upgrading and uninstallation, you also need to make that clear. So the additional text would be something like:

"Ongoing validation is required when in use, when upgrading, and during uninstallation."

However, with regards to uninstallation, bear in mind clause 3, which states:

Uninstallation must not depend on an external server. If an external request needs to occur during uninstallation and this request fails, uninstallation should still be able to proceed. You must not block or prevent uninstallation in any way.

Well-known member

Interested in the viewpoint on whether resources/add-ons can still be functional, even though they have been disabled in ACP? The guidelines don't seem to mention this. I would have thought that if an add-on is disabled, it should not be functional.

XenForo developer

In that case, it probably isn't a direct breach of the guidelines. They probably aren't inserting code event listeners that are not associated with their add-on. If it is being accessed through files on your server, as Mike says, that's something different.

In that particular case, the onus would be on you to prevent access to those files (or delete them after uninstall).

Thanks.
Then what is the purpose and reason for having a plugin installed in the ACP, and being able to enable or disable it?
If it's just files we place on our servers, then it's not really an add-on then?

XenForo developer

Well the TT example is not actually really "integrated" into XenForo for the most part. If you upload file.php to the server and call it directly, XenForo can't prevent the web server from calling it. Integrating into the XF UI is done via systems that XF can control. (The developer could check the add-on state in their files before handling anything.)