Customization approval guidelines

To make customization approvals easier on both the team, the community customizers and the authors, we have introduced some approval guidelines for all customizations. This is to cover some of the more common problems we see, most of which result in having to spend time correcting things that could have been prevented in the first place.

No Hardcoded Text

"Hardcoded text" refers to words that are typed directly into the template and source files and displayed to members using the theme. This makes translating the mod for use with different languages much more difficult, so it is for this reason we require that all language strings be placed into language files. This applies even for English! Modifications.english.php is loaded on every page load and should be used for all mods unless your mod is large enough that it would require it's own language file. You may add to other language files to your install file using the error="skip" attribute, but you must at least add them to Modifications.english.php if not creating your own language file.

Theme authors can use a special file called ThemeStrings.english.php to store any extra language strings the theme may require. If using the ThemeStrings file, English is required. Other languages may be included. This topic on the community forums explains how to use the ThemeStrings file.

No Unauthorized Use Of Creative Works

Unauthorized use of other people's copyrighted code or graphics is strictly forbidden. If you are going to use copyrighted material, then you must first obtain authorization from the copyright holders. If we discover that you have used copyrighted material without proof of authorization, we will ask to provide such. If you can't show permission, then you will need to remove the material, or the customization will not be approved or will be removed from the site.

Any customizations (including avatar and smiley packs) submitted to the customization site that contain artwork or graphics must provide the source of the items so we can verify you have permission to use them. If you have obtained permission from the author of said artwork, please state that somewhere in your package (the README is preferable, but in the mod's description, or in the code or comments of the mod works as well). If permission is not necessary to use the artwork (perhaps by the artwork's license), a link to the source of the artwork will still be required so we can verify. If you have made the artwork yourself and claim the copyright, please include a line in the package that you claim the copyright (Artwork © 2010 SlammedDime or similar).

Proper Package Formatting

For mods, avatars and smiley packs, package-info.xml must be in the root of the archive. Depending on which file format you decide to use for your modification installation instructions, it should be in the proper format for that file. For example, when using the XML format, CDATA tags are required on <search /> and <add /> strings. The proper information should be in the files as well, including version information, author and package id. Packages should not be double archived or double foldered.

For themes, theme_info.xml must be in the root of the archive. The information displayed in this file is important - particularly the id, package id, name, and contact information. There are two different versions of this file; one for 1.1, and one for 2.0. You can find examples of these files in the 'classic' and 'babylon' theme of SMF 1.1 and the 'core' theme of SMF 2.0.

Database Queries

All queries and "work" should be done in the Source files, not the files that display the information. You can put your data into $context as needed and then display it in the template files. This also means easier portability in your mod from theme to theme and less work that users of your mod will need to do in order to get it working. It will also allow you to properly sanitize all data before it's used. When using queries in the template files, templates aren't loaded until the end so it is possible that you may sanitize data in the source file, but somehow get changed in before going to templates which can cause issues and security vulnerabilities.

Data Sanitation

Before any data can be used in a query that is passed in by the user either by form or by URL, it should be checked that it first actually exists, and secondly that it is the right type. You should use the appropriate PHP functions to test for variables for proper type or explicitly cast them when being used. For example, when searching the database by member id which is passed in via the URL GET variable of 'id', you should perform (int) $_GET['id'] or (int) $_REQUEST['id'] before using that variable in the query.

Installation / Uninstallation

Your customization should install without any errors on an unmodified copy of SMF and must uninstall without ever leaving a trace that the customization was installed (aside from the ~ backup files). Information/Data can be kept in the database, but should be uninstalled if it would create errors after the customization was uninstalled.

Mods With Theme Changes

Any mods that make changes to themes must at least make the changes, and work on, the SMF 'Default' theme, (for SMF 1.1, Core; for SMF 2.0, Curve). You may include changes to other themes as well, however you must use the 'error="skip"' directive for each file you are modifying in another theme. Keep in mind that 2.0 can install mods on other themes as long as the same block of code you are searching exists in the other themes.

W3C Validation

Template files must be valid to HTML or XHTML standards. Typically XHTML is more common in themes for SMF, but HTML can also be used. Remember to validate while logged in as both a user and as a guest. (To test while logged in, you can copy and paste the source code into the Direct Input box on the W3C Validator or use the Web Developer Toolbar for FireFox.) Your customization should also use valid CSS. We are aware that sometimes CSS 'hacks' are needed to make things appear right in a cross-browser situation; these 'hacks' would be acceptable. Examples of invalid CSS include leaving the # off of a color declaration or not including a measurement type on sizes (px, em, ex, etc...).

Excessive Files

Customization packages should not contain files that they don't use. This would include extra images or template files that are not modified from the default, Thumbs.db files (common for files zipped together on Windows computers), or PSD's of images. Source images for customizations may be attached as an extra file on the customization's summary page.

Theme Settings

If your customization adds or removes theme settings, it should modify or include a replacement of Settings.template.php. More information can be found in the community.

Customization Descriptions

All descriptions should contain at least an English description of the customization. You may not place links that have nothing to do with the support or demo of the customization (ie: no 'Sponsor' links). The description should be relevant to the customization and provide meaningful insight into the functionality or changes it makes.

It Must Work

This is the most important guideline. Your customization should work as described. All added features should work as expected and your customization should not throw any unwarranted errors in the error log. We understand that your customization will likely have bugs that users will find through use; however, when we test it, it should install properly, be usable without throwing errors in the error log, and uninstall properly and leave behind nothing but data in the database.

Keep in mind the requirements for SMF itself when making your customizations and ensure you will not alienate users on lower versions of required server software. Mods are not required to support all databases that SMF supports, however you are required to use SMF's database functions when querying the SMF's database. Customizations must support the minimum PHP version that SMF supports. For example, if you are using a PHP function only available in PHP 5.1 or higher, it must be backported to less than PHP 5.1 for use in SMF. Even though PHP 4 is EOL'd, it is still supported by SMF and many hosts.

Clean Code

This is not required for approval, but heavily suggested. You should try to keep your code easily readable and use meaningful variable names. Easily readable code will be indented properly using tabs (not spaces) and will follow the existing flow of the code you are modifying. Your code should not introduce a performance block into the normal flow of code (ie: do not create race conditions or endless loops). You should use the LF style of line ending (Unix style); most quality text editors have this option. If we do find large performance blocks, we will deny the mod approval until they are fixed. We heavily recommend customization authors follow our Coding Guidelines.

Extra Notes

• Do not submit your customization to the site more than once with different package id's hoping to get it approved faster
• You may update your customization while/before it is approved without it being pushed to the end of the queue
• A topic will automatically be created in the Modifications and Packages board once your mod is approved
• Unless there is a request by the author or a security issue reported in the customization, customizations are only reviewed on their initial submission