Special thanks go to Dzinc for suggesting the idea of a Visual Rejection Guide and providing a helpful template for the summary. Special thanks go to the users who contributed work to the Guide, including NechitaPaulFlavius, kimi1122, agodesa, magnoworks, kozmica, ToivoMedia, and many, many more!

CSS Rejections

• Low Quality: The most obvious: sometimes, the design simply isn’t of a high enough quality to warrant being sold as a Premium item.
• Too General: Because many CSS files are available around the web for free, items must distinguish themselves, and go above and beyond what’s typical.
• Similarity: If a new submission is far too similar to items that are already available on the marketplace, it will be rejected. To be accepted, yours must be either 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 features to warrant approval. It’s important to us that items we approve are unique and do not offer more of what is already abundantly available online. It’s best to look at what scripts are already online and then possibly improve on what you find, possibly by adding unique features or even a superior implementation — anything to differentiate your item from what’s already available online.
• Implementation: The item’s implementation is simply not up to the level of quality expected. There seems to have been only minimal thought given to application design. I can’t see much abstraction or any intuitive API for the buyer. It seems somewhat rushed and a buyer would find it difficult to customize this or integrate with it their own design and preferences. I suggest looking into design-patterns in JavaScript and abstraction.

PHP Rejections

• Is it Unique: There are plenty of open source solutions available for nearly everything out there. We’re really looking for unique functionality, or items which provide a unique twist to an existing functionality.
• Implementation: We expect code that’s top notch, secure and well commented. A clean application design and proper abstraction is implicitly expected.
• Features: Less is more, sure; but when it comes to, say, a utility class, buyers are going to appreciate more features. There is such a thing as being too focused. Providing just a single, very simple feature isn’t going to get you far unless its implementation is spectacular.
• Ease of Integration: The code must be easy for the purchaser to include in his existing projects relatively painlesslessly. Provide a more intuitive API, document your code better so that the user knows where he can hook into; provide separate config files to make it easier and provide a sample mini codebase to show them how it’s done.
• Documentation: With code, documentation is king. Even for a very spartan utility class, we expect a well written, thorough help file expounding on the various methods it exposes, its signature and so forth. With a user script, take your time to create an installation guide and a quick start guide explaining all the features it provides. Please try to be as pictorial as possible in these guides. Our purchasers need not be tech savvy to use our scripts and being visual gets the point across quickly. Extra cookies for screencasts.
• Lack of Market Prospects: This doesn’t happen often but, at times, we receive items that are generally well written, but have zero sales prospects. Before starting to write some code, please take a moment to think whether purchasers will pay money for such a functionality.

.NET Rejection Factors

• Lack of Code, Binary, or Project: .NET is a rather unique category here at CodeCanyon in that .NET-based code can be compiled and distributed as a binary. However, CodeCanyon is a marketplace 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: Following the submission instructions is not only vital, but it saves time for everyone involved. They can be found here.
• Design: A critical part of every piece of code is its design, and the folks at Microsoft authored a set of design guidelines for developers to follow to encourage consistency and predictability. It is expected to be designed according to the information found here.
• Configuration: The best location for configuration settings is the web.config or app.config file – not in code. While the <appSettings/> 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+.
• Too General: You can find code freely available on the web. So, your item must distinguish itself from free code by providing features well beyond those free items.
• 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.
• 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 as they use your component in their project.

Other Rejection Reasons

• Browser Testing: Have you tested your design in IE6 (optional), IE7, IE8, Firefox, Safari, Chrome, and Opera? While we do allow for alternative displays for older browsers — think simplified layout for IE6 users — your design must not break in any of these. If they do, your item will be rejected, with a request from the reviewer to make the necessary updates.
• Documentation: Every template on CodeCanyon must include documentation to make the installation process as simple as possible for the purchaser. While you don’t have to teach the reader how to code, you should absolutely discuss any unique aspects of your template, which require further explanation.

  We encourage you to use the documentation template, found here.

Documentation

Every Project File on VideoHive must include documentation to make the customization process as simple as possible for the purchaser. While you don’t have to teach the buyer how to use After Effects, you should absolutely discuss any basic changes every buyer must make, and the process to make such changes..

For example, if your file is a video display, the buyer will obviously need to replace your placeholders with their own assets. Your documentation should guide the buyer through the steps necessary to make this change. Other things you might want to talk about are how to change colors, how to add or remove placeholders, which layers contain important elements, which compositions contain important elements, etc.

The medium you choose is also important. We accept a wide variety of help file formats, but you should try to stay away from basic TXT files. As they are generally hard to read, and any formatting can easily become messed up. It’s all about making it as easy as possible for the buyers, so try to use one of the following formats.

• Rich Text
• PDF
• Video Tutorial (FLV or MOV)

Watermark

We employ a watermark that we require to be present on every preview video. The watermark comes in three resolutions, and the resolution of your preview video should match the resolution of the watermark you choose. You can download the watermark file here: VideoHive Watermark.

Non-Standard Codecs

While Divx is a very popular codec for digital video playback. It’s not a standard codec for video assets. Rendered video and footage must be in the Quicktime MOV format, and must make use of only standard industry codecs. Some of the more popular codecs include Quicktime PhotoPNG, or Quicktime PhotoJPEG.

Messy Project File Structure

• File Management

  When a buyer decompresses your ZIP file, the folder structure should tell the buyer how to begin using the file. For example, the main project file should always be in the root directory. Along with the project, you should have two folders. One for any assets used, and another containing your help file/documentation. Other folders can be used if you have more to add. And sub-folders can also be used to further organize larger folders containing assets. You’ll want to name these folders obvious names like “Assets” and “Help File”.

• Project Management

  Projects need to be organized properly as well. Messy projects make it harder to move around within, and more difficult for the buyer to customize. In your project panel make sure to group similar assets or compositions in folders, with direct and easy names. Name the layers in your time line, and even feel free to add notes and markers to the time line to better explain to your buyers how and where to customize.

• Remove Assets That Don’t Belong

  When you finish your project, make a copy of the whole folder and ZIP it up. Then with the original render out your preview video. We often see projects come in with the VideoHive watermark layer still on the time line from when you made your preview. Sometimes the watermark is not in the ZIP, so After Effects throws an error when the file is opened because it’s missing assets. Make sure to remove anything that isn’t intended for the buyer. Remember to give the buyer the most polished product possible.

• Keep Your Folder Structure Intact

  If you make any changes to your folder structure after your final save in After Effects, this will cause errors when the file is opened. For example, lets say your working out of a folder with every asset in the root. You save your project the final time. But then after saving you organize all of these assets into a clean folder structure. Since they have all moved, when the project is opened it causes errors, because After Effects cannot locate the assets. Buyers can easily locate the assets, but they shouldn’t have to. Also, buyers with less experience may interpret these errors as genuine file issues, and write in to support.

Poor Description and/or Attributes

The description and attribute sections are provided for your benefit. They help buyers locate your file, and once found they explain to buyer what it is they will be purchasing. It’s important to keep these section as descriptive and accurate as possible.

• Descriptions

  Descriptions should be used to accurately describe your file. YES, the preview video will show the viewers what the end result looks like. But you should use this field as an opportunity to explain what you’re providing (what comes with the file), what it can be used for, duration, if you included any variations, etc. You have comments for questions, but if you use the description wisely, you can answer many common questions before the people need to ask.

• Attributes

  Attributes explain the common aspects of your file. The most common mistake is the category selection. To ensure authors find your file, you should select the bottom-most category possible. The top level describes the type of file your uploading, and the second level describes the style of the file.

Improper Use of Assets

When you use external assets its important to ensure they are all properly licensed and properly credited. It’s also important to remove any assets that cannot be distributed commercially from your ZIP file.

• External Assets

  Any assets you use that you didn’t create yourself need to be specifically licensed for commercial distribution. If a file is submitted that contains another person’s assets, you’ll need to provide a link where the reviewer can view the license to verify it can be distributed. We often see files that include assets that can be used, but because we couldn’t located the license, we have to reject it. So always make sure your assets can be commercially distributed, and then make sure to provide us with the license location.

• AudioJungle Files in your Preview

  The easiest and most recommended method to find high quality audio for your preview is through AudioJungle. Many AudioJungle authors will gladly provide you with a free copy of their music in exchange for a little promotion. A few things to remember when using an AudioJungle file in your preview.

  1. NEVER include the file within the actual download.
  2. ALWAYS give the author credit. All you have to do is explain who made the audio used in your preview, and provide a link to the file’s page on AudioJungle.
  3. You must seek permission from the AJ author before you use their audio.
  4. Only the watermarked version of the audio can be used in the preview, UNLESS you purchase the file.

The soft-rejection system was built for otherwise great files with minor issues preventing them from being accepted. For example, a file that would normally have been accepted, but the preview.swf was named incorrectly may be soft-rejected. In cases like this, the author would just need to fix the minor issue rather than re-uploading everything from scratch.

If your item has been soft-rejected, you’ll receive an email letting you know. Follow these steps to get your soft-rejected file re-reviewed.

1. Follow the link found in the email.
2. Click the edit button. The edit page is split up into two parts, “Update Description” and “Update Item and Tags.”
   
3. Make the changes outlined in the email.
   1. If you change anything under “Update Description” like the description, published size, or resolution, be sure to click and return to the edit tab to complete the final steps.
      Note: Just clicking will not put your item in the soft-rejection queue!
   2. Under “Update Item and Tags,” re-upload anything you’ve changed. Be sure to re-upload the preview, whether it changed or not.
4. In the notes to the reviewer, outline the changes you’ve made.
5. Click .

Once you’ve completed these steps, your file will enter the soft-rejection queue, which moves along more quickly than the normal queue.

The soft-rejection system was built for otherwise great files with minor issues preventing them from being accepted. For example, a file that would normally have been accepted, but the preview.swf was named incorrectly may be soft-rejected. In cases like this, the author would just need to fix the minor issue rather than re-uploading everything from scratch.

If your item has been soft-rejected, you’ll receive an email letting you know. Follow these steps to get your soft-rejected file re-reviewed.

1. Follow the link found in the email.
2. Click the edit button. The edit page is split up into two parts, “Update Description” and “Update Item and Tags.”
   
3. Make the changes outlined in the email.
   1. If you change anything under “Update Description” like the description, published size, or resolution, be sure to click  and return to the edit tab to complete the final steps.
      Note: Just clicking will not put your item in the soft-rejection queue!
   2. Under “Update Item and Tags,” re-upload anything you’ve changed. Be sure to re-upload the preview, whether it changed or not.
4. In the notes to the reviewer, outline the changes you’ve made.
5. Click .

Once you’ve completed these steps, your file will enter the soft-rejection queue, which moves along more quickly than the normal queue.

Documentation

Every template on ThemeForest must include documentation to make the installation process as simple as possible for the purchaser. While you don’t have to teach the reader how to code, you should absolutely discuss any unique aspects of your template, which require further explanation.

We encourage you to use the documentation template, found here.

Typography

• Line-Height

  Generally, a line-height of 1.3-1.6em (depending on font size and usage) is most appropriate. While this isn’t set in stone, make sure that you have a specific reason to choose beyond this range. A great resource on this can be found here.

• Visual Hierarchy

  We recommend that designers research this topic and spend time refining your skills in this area. It will dramatically help your template aesthetics.

• Text Alignment

  Though we don’t generally reject templates specifically for text alignment, if it seriously contributes to poor aesthetics, we will. Justified alignment on the web should be used appropriately, though it’s unfortunately often misused.

Validation

There is no reason your template should have unnecessary validation errors, unless you happen to be working within the confines of a particular CMS or framework which limits your control over the code output. HTML5 and CSS3 “errors” will not count against your template, so feel free to progressively enhance as much as you wish! With all that said, ALWAYS validate before submitting.

Lacking Code Quality

• Poor List Mark-up

  A list of links should be written with the link elements, not a series of anchor tags. This is called semantics, and is essential to your upload. A general rule of thumb is: if you would describe a particular section of your mark-up as a list of links, images, advertisements, etc., then you should appropriately use a “ul,” “ol,” or “dl.”

• List Separators

  Do not separate links with the ”|” character. This is bad form, and should instead be accomplished with CSS.

• Browser Testing

  Have you tested your design in IE6 (optional), IE7, IE8, Firefox, Safari, Chrome, and Opera? While we do allow for alternative displays for older browsers — think simplified layout for IE6 users — your design must not break in any of these. If they do, your item will be rejected, with a request from the reviewer to make the necessary updates.

Category-Specific

• WordPress

  You must include the WordPress GPL license within your “main files” zip file. Please refer to our original blog posting for more information.

The soft-rejection system was built to prevent authors from having to reupload all files again and instead, just fix the minor issues reviewers discover during the submission/reviewing process. For example, a submission that has everything present and correct except for a missing AudioJungle watermark on the preview file may be soft-rejected. In cases like this, the author would just need to fix the minor issue rather than re-uploading everything from scratch.

If your item has been soft-rejected, you’ll receive an email alerting you of the soft-rejection status. Follow the following steps to fix and resubmit your soft-rejected file:

1. Follow the link found in the email.
2. Click the edit button. The edit page is split up into two parts, “Update Description” and “Update Item and Tags.”
3. Make the necessary changes the reviewer outlined in the email.

3.1. If you change anything under “Update Description” like the description or audio files included, be sure to click  saveChanges and return to the edit tab to complete the final steps.
Note: Just clicking saveChanges will not put your item in the soft-rejection queue!
3.2. Under “Update Item and Tags,” re-upload anything you’ve changed.

4. In the notes to the reviewer, it is important that you outline the changes you’ve made.
5. Click submit.

Once you’ve completed these steps, your file will enter the soft-rejection queue, which moves along more quickly than the normal queue.

The soft-rejection system was built for otherwise great files with minor issues preventing them from being accepted. For example, a 3D file that would normally have been accepted, but some textures were missing may be soft-rejected. In cases like this, the author would just need to fix the minor issue rather than re-uploading everything from scratch.

If your item has been soft-rejected, you’ll receive an email letting you know. Follow these steps to get your soft-rejected file re-reviewed.

1. Follow the link found in the email.
2. Click the edit button. The edit page is split up into two parts, “Update Description” and “Update Item and Tags.”
   
3. Make the changes outlined in the email.
   
   
   1. If you change anything under “Update Description” like the description, category, geometry type, or poly count, be sure to click and return to the edit tab to complete the final steps.
      Note: Just clicking will not put your item in the soft-rejection queue!
   2. Under “Update Item and Tags,” re-upload anything you’ve changed.
4. In the notes to the reviewer, outline the changes you’ve made.
5. Click .

Once you’ve completed these steps, your file will enter the soft-rejection queue, which moves along more quickly than the normal queue.

The soft-rejection system was built for otherwise great files with minor issues preventing them from being accepted. For example, a file that would normally have been accepted, but the preview video was not properly watermarked may be soft-rejected. In cases like this, the author would just need to fix the minor issue rather than re-uploading everything from scratch.

If your item has been soft-rejected, you’ll receive an email letting you know. Follow these steps to get your soft-rejected file re-reviewed.

1. Follow the link found in the email.
2. Click the edit button. The edit page is split up into two parts, “Update Description” and “Update Item and Tags.”
   
3. Make the changes outlined in the email.
   
   
   1. If you change anything under “Update Description” like the description, published size, or resolution, be sure to click and return to the edit tab to complete the final steps.
      Note: Just clicking will not put your item in the soft-rejection queue!
   2. Under “Update Item and Tags,” re-upload anything you’ve changed.
4. In the notes to the reviewer, outline the changes you’ve made.
5. Click .

Once you’ve completed these steps, your file will enter the soft-rejection queue, which moves along more quickly than the normal queue.

The soft-rejection system was built for otherwise great files with minor issues preventing them from being accepted. For example, a file that would normally have been accepted, but the preview.swf was named incorrectly may be soft-rejected. In cases like this, the author would just need to fix the minor issue rather than re-uploading everything from scratch.

If your item has been soft-rejected, you’ll receive an email letting you know. Follow these steps to get your soft-rejected file re-reviewed.

1. Follow the link found in the email.
2. Click the edit button. The edit page is split up into two parts, “Update Description” and “Update Item and Tags.”
   
3. Make the changes outlined in the email.
   1. If you change anything under “Update Description” like the description, published size, or resolution, be sure to click  and return to the edit tab to complete the final steps.
      Note: Just clicking will not put your item in the soft-rejection queue!
   2. Under “Update Item and Tags,” re-upload anything you’ve changed. Be sure to re-upload the preview, whether it changed or not.
4. In the notes to the reviewer, outline the changes you’ve made.
5. Click .

Once you’ve completed these steps, your file will enter the soft-rejection queue, which moves along more quickly than the normal queue.