Summary: This article outlines common rejection reasons for Code items across different categories. Use this to make sure you get your item approved and don't fall to the common CodeCanyon pitfalls!
CSS Rejections
- Low Quality: The design is not of high enough quality to warrant being sold as a premium item.
- Too General: Many CSS files are available for free and so items must distinguish themselves. They need to go above and beyond what is available in free files.
- Similarity: If a new submission is too similar to items that are already available on the Envato Market, it will be rejected. To be accepted, items must be unique, or of a higher quality than the currently existing items.
- Inline CSS: Do not use inline CSS. Export all styling to an external stylesheet.
- Validation: Excluding any vendor-specific prefixes, all of your code must validate. Otherwise, it will be rejected.
- Inline -> Block: Do not place block level elements (div, h2, etc.) within inline elements (span, em).
JavaScript Rejections
- Degradation: If an item requires JavaScript to work, you must provide an operable degraded version as well. For example, picture sliders should still be functional, at a minimal level, even when JavaScript is disabled. The practice of progressive enhancement should be employed to ensure that the script gracefully degrades in such a way that it remains minimally accessible to all users (or at least, the vast majority).
- Complexity: The item is not of sufficient complexity or it lacks features. Items must be unique and have additional features and/or superior implementation to differentiate from readily available free files.
- Implementation: The item's implementation is simply not up to the level of quality expected. Thought must be given to application design with abstraction and intuitive API for the buyer. It must be easy to customise and integrate with a buyer's own design and preferences.
PHP Rejections
- Too General: With an abundance of open source solutions available we strive for unique functionality or a unique twist on existing functionality.
- Implementation: Code should be well written, secure and well commented. A clean application design and proper abstraction is implicitly expected.
- Lack of features: Items need to have more than one focus, a single simple feature provides little attraction for buyers.
- Ease of Integration: The code must be easy for the purchaser to include in existing projects. API should be intuitive and code should be documented clearly. Separate config files are an excellent place to start.
- Lack of documentation: Documentation should be well written and explain all the features provided. Pictorial guides are ideal.
- Lack of Market Prospects: Occasionally items are well written, but unfortunately lack sales prospects. Please consider whether purchasers will pay money for such a functionality.
.NET Rejections
- Lack of Code, Binary, or Project: .NET is a rather unique category on CodeCanyon in that .NET-based code can be compiled and distributed as a binary. However, CodeCanyon is an Envato Market site for selling code, and all submissions must include the source code, the compiled binary, and the project and/or solution of your component.
- Failure to follow submission instructions: The item must be uploaded in accordance with submission instructions.
- Failure to follow design information: A critical part of every piece of code is its design. Microsoft authored a set of design guidelines for developers to follow to encourage consistency and predictability which must be followed.
- Incorrect configuration: The best location for configuration settings is the web.config or app.config file - not in code. While the configuration section is useful for individual settings, components or libraries that need more complex configuration should incorporate the use of custom configuration sections. You can find a primer to custom configuration sections on Nettuts+.
- Item not unique: Items must be distinguishable from free code.
- Incorrect packaging: Non-visual components should be packaged as class libraries. Visual components (UI) should be packaged according to how they're developed. ASP.NET user controls should be packaged as ASCX files (with code-behind if necessary), and UI controls developed as inheriting Control or WebControl should be packaged as class libraries.
- Lack of documentation: All public data types and their public members should be properly documented using XML documentation. This ensures that Intellisense gives the consumer appropriate information to use the component in their project.
Other Rejection Reasons
- Failure to test in a variety of browsers: Items should be tested in IE7, IE8, Firefox, Safari, Chrome and Opera.
- Lack of documentation: Templates must include documentation explaining installation and, any unique aspects of the template.
We encourage you to use the documentation template, found here.