Resource standards

While it is not currently possible for XenForo Ltd. to review every single resource available in the Resource manager, it is important that all resource authors are aware of the minimum standards we expect from them when they release their products here.

Following these standards is incredibly important to ensure that we foster a third party development eco-system which is founded on quality. It is imperative that if you currently have any code which falls short of these standards then you work towards resolving those issues as soon as possible. Similarly, if you're unsure of whether you are meeting these standards or need more information about how to adhere to these standards then you must ask in the Development discussions forum.

Should any resource standards violations be noticed, they should be reported to the resource author in the first instance. Should the resource author be unable to or otherwise fail to resolve the issue in a timely matter, then the resource should be reported using the "Report" button on the report itself with the details.

The minimum standards are as follows:

1. The add-on title must be clear as to its function, even if that's at the cost of brevity. For example, an add-on which automatically marks alerts viewed should be titled "Automatic alert view marking" rather than simply "Alerts".
2. The add-on must be installable.
3. Free of obvious bugs - undefined variables, undefined indexes, spelling mistakes, using $this outside of the object context etc.
4. Any resource updates released in the RM should make it clear which issues (if any) have been resolved in the update.
5. Other than for time limited demo or trial purposes, code must not be encrypted, encoded or otherwise obfuscated.
6. Database queries should mostly be performed using the Finder. Where there’s a specific reason not to, database queries must use the default XF database adapter and must use prepared statements.
7. Similarly, add-ons should not bypass Entity objects and should perform reads and writes using these and related objects.
8. Queries must scale well and must avoid a situation that would increase the query count unexpectedly.
9. Queries must be constrained using the appropriate conditions to avoid accidental overwriting of existing data.
10. Where possible, the Schema Manager should be used for all schema changes, though using the database adapter to perform these queries is reasonable but not recommended.
11. The following should be adhered to with respect to schema changes:
    1. New tables must be prefixed with xf_ and additionally an identifier for the add-on e.g. xf_mg_.
    2. New columns to core tables must be prefixed with an identifier for the add-on e.g. xfmg_.
    3. New columns to core tables must have a default value or be nullable.
    4. Any new tables or columns added must be removed on uninstall.
    5. Where possible, an add-on should not change the definition of a core column.
12. Add-on code should follow MVC (Model-View-Controller) principles.
13. Add-on code should follow DRY (don't repeat yourself) principles.
14. All user input must be filtered in line with default approaches (using the XF input filterer). Variables containing user input such as $_POST, $_GET, $_SERVER etc. must not be accessed directly without being appropriately filtered.
15. Use of JavaScript and HTML must not be susceptible to XSS exploitation. Extra care must be taken to escape (or not bypass default escaping) of user generated content.
16. Styling within the add on should be consistent with core styling. Core styling should be used to the fullest extent possible including (but not limited to) structured list, data list, block or content row styles as well as making full use of XF template syntax for producing form elements including (but not limited to) tags such as <xf:form>, <xf:textboxrow> etc.
17. Template modifications should be used to inject modifications into templates rather than modifying the rendered template in code.
18. Template modifications must be careful not to replace too much of a template. This might require the use of more complex methods such as a PHP callback or regular expression match.
19. Existing classes must be extended using the XenForo Class Proxy (XFCP) system via the built in “Class extensions” system.
20. Where a specific code event exists, a listener should be created to utilise it rather than a full class extension.
21. Add-ons must utilise the various “handler” systems where available to their full extent rather than extending classes to inject custom behaviour. Including, but not limited to, Spam checking which must be implemented using the spam checker handler system rather than extending the checkForSpam methods in different places.
22. If a class extension is required to extend core methods then it must be extended properly, rather than overridden, by calling the parent method.
23. If a core method has different return types with different behaviours (e.g. controller actions return different types of reply objects) then the extended code must check to ensure it’s working with the correct type.
24. Add-ons must not attempt to add data which is not associated with the add-on.
25. Add on data which requires unique IDs or keys (such as template modifications) must be prefixed in a way that can identify the add on or developer.
26. Add-ons must only use any sort of license callback if that is made clear in the resource description; usual guidelines regarding this apply.
27. If an add-on needs to make HTTP requests, it must use the XF HTTP client rather than making cURL requests manually.
28. Similarly, if XF has any other framework features including (but not limited to) email sending and image manipulation these should be used where practicable.
29. File system operations must use the XF file system (which uses "FlySystem") particularly for files hosted in data, internal_data or code_cache directories.
30. Third party libraries included in your release must be appropriately licensed.
31. If exec type functions are used, arguments passed into them must be escaped appropriately.