The most common reasons for Product improvement requests

Wrong archive structure. Please, refer to the rules and conditions of structuring a product archive.

Issues caused by the readability of design elements. Some elements of your site’s design are difficult to read or feature poor contrast to other elements. Make sure that all blocks of your website make clever use of contrast, are easy to read, and feature smartly organized color schemes. You can learn more about web design contrasts and readability here.

Typographic inconsistency. The theme’s typography should be polished. Make sure that content hierarchy is applied clearly on all pages and in all blocks of the design. To get a better understanding about the typographic hierarchy, follow this link.

Wrong visual hierarchy. Make sure that the theme utilizes the common, logical principles to highlight essential design blocks and group the most significant elements. To get a clearer understanding of the key visual hierarchy principles and their proper use, read this.

Inconsistent use of tabs and spaces. Make sure that your work is formatted properly. Double check that there is clear logic in the way your design’s elements are organized into tabs and the way spaces are used. Refer to the detailed article to get a better understanding of the issue

Color scheme. The chosen color scheme should be polished. You can find more information in the following article.

Font choices. The choice of typography is of significant importance in the creation of a visual hierarchy of web designs. Make sure that the chosen fonts fit your work logically.

Documentation. Documentation is either missing or needs further improvement. Provide users with detailed and easy-to-follow documentation, making it easier for the end user to work with your theme.

Titles of groups and layers in PSD files. In PSD files, all layers and groups should be properly named and organized in a logical order. Keep the end users in mind when working on the creation of PSD files.

All groups should be collapsed. Before saving PSD files, make sure that all groups of layers are collapsed.

Replacing images with placeholders. Replace all commercial images with placeholders, except for the cases where your license allows you to apply images to the end product.

Blog publications display. Test all blog publications and post formats with Theme Unit Test

Widget stylization. Double-check that all standard WordPress widgets are styled properly, and seamlessly perform in all widget areas and on all devices.

Mobile friendliness. Make sure that all design elements are stylized to be properly displayed on mobile devices. Child theme issues. Child theme doesn’t install or causes issues in the work of the parent theme.

Use of inline CSS style is prohibited.

CSS file is poorly documented. Divide a CSS file into logical blocks, title them, and add table of contents.

CSS specificity. You need to enhance CSS specificity and avoid “!important”.

Use local files for jQuery instead of CDN.

JavaScript should be used at the bottom of the page.

Code formatting. Make sure that the code is properly formatted and is easy to read.

INDENTATION & SPACE VS TABS: please make sure that your code is correctly indented and that it’s consistent with the use of spaces or tabs for indentation of the code. We do not give preference to any, but we need the author to pick one and use it for all the code.

SPECIFICITY: Please, make sure you improve the specificity in your CSS code, there are too many “!important” declarations.

JavaScript files need to be placed at the bottom, barring critical exclusion. [Modernizr, for instance].

Use a local copy of JQuery. Not a CDN.

Inline CSS is not permitted. Please, remove all the inline CSS.

CSS TABLE OF CONTENTS: Make sure the CSS file is well documented with proper table of contents. For more information, see: http://www.smashingmagazine.com/2008/…yleguides/

Scripts and styles should not be hardcoded anywhere in your theme or added any other way but with wp_enqueue_* hook and should be added from the functions file. This includes custom JS/CSS. For inline styles use: https://developer.wordpress.org/refere…ine_style/ and for scripts https://developer.wordpress.org/refere…ne_script/

You should avoid, and not hardcode, custom body_class(). Main reason for this is being able to remove the class when needed i.e. child themes. What you can do –

• https://gist.github.com/kailoon/d4d22c…909dff21eb
• http://themeshaper.com/2014/11/20/mas…-function/
• https://codex.wordpress.org/Function_Reference/body_class

Always use esc_url when sanitizing URLs, including WordPress related, also, all home_url() must include a trailing slash such as home_url(‘/‘) See: https://codex.wordpress.org/Function_R…ce/esc_url

wp_footer should be placed immediately before body closing tag.

Please, make sure your theme doesn’t raise any errors or warnings with theme-check.

The localization file should be in English and delivered as .POT file. .POT will contain all translation strings. .POT file name should match the themes-slug. Theme can include actual translation files, but it should not add the en_US.mo or en_US.po because English is already implied.

Please, use a unique prefix for all function names, custom image sizes, classes, CONSTANTS, hooks, public/global variables, and database entries to avoid conflict issues with plugins and other themes. For example, themename_ OR frameworkname_

Please, use the latest version of PrettyPhoto, more info – http://themeforest.net/forums/thread/…pt/1811…

Please, use proper hooks to enqueue any scripts / styles i.e.:

• – wp_enqueue_scripts for frontend
• – login_enqueue_scripts for login screen
• – admin_enqueue_scripts for admin dashboard

These hooks should never be used to enqueue files:

• – admin_print_scripts
• – admin_print_styles
• – wp_print_styles
• – init
• – wp_head
• – wp_footer

Directory path should be get_template_directory() and not dirname( FILE ).

Please, make sure you properly prepare your data for $wpdb.

Please, also read

• – http://codex.wordpress.org/Data_Valid…n#Database
• – http://codex.wordpress.org/Class_Refe…on_Attacks

Data Validation issues have been found in your theme. All dynamic data must be correctly escaped for the context where it is rendered. – All dynamic data must be escaped with esc_attr() before rendered in an html attribute. – Whenever you are rendering a url to the screen its value must be passed through esc_url() first. – If dynamic data is rendered inside an attribute that triggers a JavaScript event, it must be escaped with esc_js().

Please, make sure you read these articles:

• https://make.wordpress.org/themes/tags…re-themes/
• http://codex.wordpress.org/Data_Validation
• http://developer.wordpress.com/themes/escaping/
• http://code.tutsplus.com/articles/dat…–wp-25536
• https://vip.wordpress.com/documentatio…-escaping/

Directory path should be get_template_directory() and not dirname( FILE ). Some of your files contain validation errors that will need to be fixed. Please, be sure that all files validate before resubmitting.

Translate all strings within PHP variable and escape where needed. JS and TGMPA included (when/if used). You need to use a text domain to denote all text belonging to that theme. The text domain is a unique identifier, which makes sure WordPress can distinguish between all loaded translations. This increases portability and plays better with already existing WordPress tools. Any strings within a PHP variable require to be translated. https://developer.wordpress.org/themes…alization/

Prefix everything and use unique (theme-name-based) consistent slugs. Additional prefix is acceptable for when the author is using a framework. Avoid using initials or abbreviations. Here’s a list of the most common things that should be prefixed: PHP function names, PHP class names, PHP global variables, Action/Filter hooks, Script handles, Style handles and Image size names. Please, see: http://themereview.co/prefix-all-the-things/