Standards Checklist When Writing Awesome Support Add-ons

When creating an Awesome Support add-on, there are certain items that should be checked and double-checked before delivery.

The Basics

Did you use the Awesome Support Add-on Boilerplate located on github?
Did you rename the main boilerplate file so that the name of the main add-on file start with awesome-support? Eg: awesome-support-custom-fields?
Did you set the name of the extension in the boilerplate header to be Awesome Support: custom fields?
Did you set an appropriate description for the add-on in the plugin header?
Did you set an appropriate version number in the plugin header?
Did you set an appropriate text-domain in the plugin header? eg: wpas-custom-fields?

Did you create an assets folder?
Does your assets folder contain separate folders for JS, CSS and IMAGE files?
Did you create a languages folder?
Did you create an includes folder?
If you have both front-end code and back-end code did you create an includes/admin folder for the back-end code?

If you are using 3rd party libraries, have you created and tested composer.json and composer.lock files?
- Do NOT include 3rd party libraries directly in your repository – they should only be included in the final .zip distribution!
Have you removed the VENDOR folder from the bitbucket/github repository?

Did you follow the WordPress coding standards for PHP, JS, HTML and CSS?
Do all your class names start with capital letters?
Is HTML that is more than a couple of lines extracted to their own “template” or “view” folder and files?
Are your function names that are not inside classes prefixed with something appropriate to prevent conflicts with other plugins? eg: wpas_cf_my_function or wpas_doc_my_function
Are your class names prefixed with an appropriate prefix if no namespace is defined?
If there are more than 20 lines in a PHP or JAVASCRIPT function/block is there an opportunity to refactor into smaller functions/blocks?
Have you verified that you are not using anonymous functions in your PHP files (especially around “add action” hooks)?

Is all user data sanitized before being saved to the database or otherwise used?
Is sanitized data that are rendered inside a data editor, text field or otherwise used as a string unescaped before rendering to display or used?
- In particular did you test your input and output with slashes, quotes, back-ticks and forward slashes?
Are nonces used on your AJAX calls?
Are you checking CAPABILITIES for every AJAX call? (i.e.: make sure that the logged in user is permitted to do the action using a user_can() function call. Why? Click this link to see what can happen without capability checks around ajax call!)
Are PHP FILTERS used when referencing data from $_POST and similar items?

Are all strings wrapped in translation functions with the correct text domain (and context hints if appropriate)?
Is an up-to-date and appropriately named POT file in the languages folder?
For any dates that are displayed or used in calculations, have you checked to make sure that the data is correct with different data form settings on the browser and the server?

Do all PHP functions, classes and instance variables have PHP DOC style headers?
Are JS files, functions and major code elements commented?
- Complex, unique or time and date-based logic needs to be extensively documented. A reader of the code should be able to read the comments and follow along with the basic logic.
Are there comments in your CSS files?
- Each block should be commented to let the reader know what area of the screen is being affected without forcing them to go search the html source to figure out what each CSS block is targeting.
If a function is being fired by a WordPress filter or hook, do you have the hook/filter name in the PHP Doc header?
- This is only necessary if the do_action or add_filter statement is NOT directly above the function. For example if the do_action or add_filter statements are set in the class constructor you should add the name of the hook to the function header since the function might be defined 100 lines below the constructor. Its always nice to know why a function exists and knowing that it’s hooked into an action / filter is important.

Did you change the PUBLISH button to “SAVE” or something more appropriate to the function being defined?
Did you double-check to see the what happens when the user bulk-edits your CPT data?
Have you verified that any WP_query searches or filters on your CPT does not include deleted or draft items?
Have you verified that the BULK EDIT options on WordPress does not introduce unexpected side effects when used?
Have you verified that converting a PUBLISHED CPT item to a DRAFT does not accidentally erase data?

Did you test the plugin as a new plugin install on a site that has never run the plugin?
Did you test the plugin on a brand new install of WordPress?
Did you test the plugin on a multi-site version of WordPress?
Did you use multi-site compatible user option functions?
- update_user_option instead of update_user_meta?
- delete_user_option instead of delete_user_meta?
- get_user_option instead of get_user_meta?

Have you verified that the plugin works on PHP Version 5.6, 7.0, 7.1 and 7.2 without throwing errors into the debug.log file?
- Items that work in 7.1 might throw deprecation warnings on 7.2 for example
Do not use anonymous functions

Do NOT create global variables or assign the jQuery function to a variable. Instead, use something like this: jQuery(document).ready(function ($) { }
Make sure that all strings are being translated (translations are pushed from PHP to the Javascript using WP conventions)

NO INLINE STYLES ARE PERMITTED
Each html block and important element must have a class name AND and ID
Our stylesheets should use the class name for styling. The ID will allow 3rd parties to force-ably overwrite our styles if necessary.

Did you remove unused files?
Did you remove unused or commented out code?
Did you use a code analysis tool to double-check for potential security errors and easily identified bugs?
Did you look in your DEBUG.LOG file to verify that there are no errors related to the add-on?
Have you made sure that you are not enqueing items that WordPress already includes for you (such as jquery)?