Updated december 2018
The Theme Review Team on WordPress.org encourages reviewers to find their own flow and tools that work for them. There is no right or wrong way to review a theme, as long as the requirements are checked and the author receives useful feedback.
My personal review process require a lot of manual effort.
While I liked the GUI of flywheel, it was just way too slow and sometimes buggy. I also found that it was not suitable for me when I wanted to do other projects than WordPress. Which happens about 3 times per year 🙂
Docker was easy to get started with, but there was a bit of a learning curve for me to get things exactly the way I wanted them. I now use two very basic docker compose files (with a persistent theme and plugin directory).
Sometime during the year, there was a big update to Sublime Text which broke all my settings. I could not get my extras like the PHP Code Sniffer to work again and truth be told, I gave up. I switched to VS Code, and I love it.
I use the theme unit test data, and we have also created a new version of the Theme Unit Test which includes blocks.
Normally it takes me 5-10 minutes to see if a regular sized (or underscore based) theme needs to be closed because there are 5 distinct issues, or if the review can continue.
But summarizing the findings and adding references, explanations and images to help the author fix the issues takes a little longer.
I try to consider whom I am writing the review for:
- -Do I need to add references?
- -Do I need to help them find a solution, or is it enough if I mention the issue?
Not all steps are performed on all themes, it depends how the theme is built.
I also split large themes over several reviews, because I don’t always have enough time to check several hundred files in one go.
If I quickly find 5 distinct issues I may close the theme as not approved without doing a full review.
First I check if the screenshot in the ticket is reasonable and not a logo or mockup.
Then I check the Theme and author URI before I download the zip file.
I look through the theme files before I install the theme.
If I do not recognise the theme author, I normally start by checking the license information in style.css and the readme.txt file, and check the theme and author URI. This is to make sure that I am not spending time on reviewing a theme if the theme is not GPL compatible.
Then I continue by opening functions.php, header.php and footer.php:
- Are there hard coded scripts?
- Is there text that is not translation ready?
- Is everything escaped?
- If there is a footer credit link does it match theme or author URI?
- Are the functions in functions.php prefixed and are scripts and styles enqueued correctly?
- Are menus, widget areas and theme support added correctly?
Then I check if there are folders named js, css, dist, assets or similar, and if there are minified files. I also check if there are any plugins, demo files or similar included in the theme folders.
- If there are minified files, is the non-minified version included as well?
This is when I start making notes and adding items to the review.
I already have texts written for common errors that I can add and adapt for the specific theme.
Run the plugins.
- Are there any errors reported?
- Check any warnings manually.
Then, depending on the theme, I use my code editor to search the entire theme folder for the following:
- get_theme_mod -This helps me find theme mods that are not escaped.
- remove -This helps me see if the author has removed any customizer settings or non-presentational hooks.
- function, -This gives me a handy list to help me check prefixes and whether custom functionality is used in place of WordPress functionality.
- script -This helps me find hard coded scripts.
- alt=, title=, placeholder= -This will help me find translated texts in attributes and make sure the texts are escaped.
- add_theme_support – This helps me check if the author has added support for title (required), custom logo (instead of using their own) etc.
- If there are multiple post formats and templates I might also search for wp_link_pages, query and reset.
Then I install and activate the theme to make sure that:
- There are no php or js errors.
- There is no redirect on activation.
- Notices are not global and can be dismissed.
- Plugins are not required, only recommended.
Testing the theme layout and custom options.
- Is the correct number of posts displayed?
- Are comments displayed correctly?
- Are there any php or js errors?
- Perform a search.
- Test the 404 page.
- Test the navigation.
- Set up a menu, is it working? Test the menu in a smaller window, is it working? Make sure that it is not overlapping or in other ways disturbing the admin bar.
- Test custom widgets and make sure there are no php notices, warnings or errors.
- Make sure that there is only minor content creation.
When I go to the customizer and test the options, I also open the customizer.php or related files in my editor and make sure the options are sanitized and set up correctly.
- Check to see if there is demo content, content creation or plugin territory functionality.
- Is the upsell reasonable and is it added with the customizer API?
Go to the post editor and double check if any meta fields has been added, and that they are for presentation, not content.
- Test the meta options and repeat for pages.
- Test page- and post templates.
- If there is starter content, reset the install to fresh and test it.
- Does the theme match the tags and description in style.css?
Whether I find issues or not, I still open each file in the theme folder manually and review them quickly, including minified files. This is still the fastest way for me to check for untranslated texts and anything that stands out.
When the review is finished, I save it as a .txt file and then cut and paste the text in the Trac ticket.