Divi Marketplace Developer Guidelines
The Basics
All products must adhere to a few basic guidelines that ensure compatibility with the Divi Marketplace system.
- No Custom Update Functions – Products within the Divi Marketplace are updated through Divi’s own update system. You are not allowed to include your own update system and serve updates from your own API. This ensures that we can review each new version of your product before it is released to our customers.
- No Additional Requirements – Your products must function with Divi and WordPress alone. Products must not have additional compatibility requirements.
Security
Security is top priority. A good general reference:
Validate Data
- Validation Functions – Utilizing functions that verify or or sometimes even cast values to what is expected. Examples: is_email(), absint(), or (int).
- Whitelisting Values – Whenever possible is wise to whitelist acceptable values, so that the only allowed values are those within the specified whitelist.
- Blacklisting Values – Sometimes it’s not feasible to whitelist but another solution could be to reject and values from a specified blacklist.
Sanitize Input
- All values that enter your product that originate from user input, API results or any other untrusted source must be sanitized. This includes data passed to WordPress hook callbacks in some cases like wp_ajax_* and heartbeat_* and WP_REST callbacks and any other hook where it’s untrusted data. If you cannot be 100.00% certain of the safety of a value then it needs to be sanitized always.
- The method of sanitization depends on the type of value needing sanitization, for example strings most often are sanitized via sanitize_text_field().
Escape Output
All variables and user input that is to be output needs to be escaped. WordPress provides many different functions to use for many escaping needs, see here.
Utilize Nonces
You must utilize nonces when receiving requests ($_POST, $_GET, $_REQUEST) to verify that the request came from a valid source, see here. Usually this is the first thing to check in a function about to act upon a request.
Check User Capabilities
- Functions that expect to be run only by a certain role or higher need to check the current user permissions using i.e. current_user_can( ‘manage_options’ ).
- You should use as fine grain checking as is needed, for example you might not only need to check if the current_user_can(‘edit_posts’) in general but instead check if they can edit this particular post, like this: current_user_can(‘edit_post’, $post_id).
- Take special care when creating and displaying lists of posts and which arguments you set in WP_Query like the post_status, especially to handle private and password protected posts properly.
- Beware of top and common vulnerabilities
Coding
Prefix All Functions
Many WordPress installs have custom themes and many plugins and due to that there are high potential chances another product could create a PHP function with the same name as yours, which would result in a fatal PHP error. To highly reduce the likelihood of a naming collisions, you should choose a prefix for all your functions in your products that’s unique to your product. For example, instead of a function like make_uppercase() prefix it like my_product_make_uppercase() or mp_make_uppercase().
Enqueue Scripts
WordPress provides helpful functions to help you get all your javascript files loaded and output properly, including any dependencies your scripts may have, see here.
No Inline Styles
It’s best practice to avoid styling your product using inline CSS, like in the actual style=”” attributes, it’s best to write your styles using proper selectors in .css files. This especially makes it easier for other products to choose to override your styles if they need.
Minimal Inline Javascript
Again it’s best to utilize the functions and API provided by WordPress for including your scripts on the page. See here.
Quality
No PHP Warnings Or Errors
- You should test your product thoroughly:
- Make sure error logging is enabled while you are testing so you can spot PHP errors or warnings generated by your product. Enable WP_DEBUG and WP_DEBUG_LOG, see here, and keep an eye on the WordPress error log file: ‘/wp-content/debug.log’ (unless it’s moved elsewhere in your configuration).
- Test in a variety of scenarios:
- With other top plugins and/or themes installed and activated.
- With a couple older versions and especially the latest version of WordPress.
- In multiple versions of PHP, especially the range that WordPress supports.
- In multiple browsers.
- See WordPress minimum requirements.
- Test a variety of use cases, use your product in every possible way one of your users would or could.
- You should also test your product in the top browsers to make sure things look and work as intended. Make sure to also monitor the developer tools javascript console for any JavaScript errors.
Code Formatting
While there is no single correct answer as to the right way to style your code, there’s no question that at least having a style guide or code standards and keeping consistent with them is helpful for code readability, for reducing the likelihood of bugs and to ease others or yourself later coming back across code and being able to quickly understand it.
WordPress publishes their style guides, see here.
Memory Usage
If you have a large and complex product you might need to also watch and make sure you keep your product using an efficient amount of memory, approaches to improving memory usage is beyond the scope of this guide.
Compatibility
Divi Compatibility
You should keep your product compatible with at least a few minor versions backward and definitely up with the latest Divi version. Monitor the changelog with each release for changes that may be applicable to an area your product depends on.
WordPress Compatibility
You should follow or subscribe to WordPress core updates to keep on top of latest WordPress changes.
Plugin Compatibility
You should make sure your product is compatible with ideally all other plugins, but you should at least test your product with top common plugins activated to ensure there are no compatibility issues.
PHP Compatibility
WordPress users use a variety of hosting providers that offer a wide range of PHP versions, WordPress officially supports PHP version 5.6 and above so you should follow that range as well read more here.
Translation Ready
WordPress has a thriving international community and offers robust support for internationalization (i18n), a string translation standard. All string that are displayed should be wrapped in an appropriate WordPress i18n function like __(), esc_html__(), esc_attr__(), etc, see here.
Ethics
No Customer Tracking
- Be aware of GDPR regulations as well as any possible other local, state, federal, or international laws that your product needs to adhere to or comply with.
- Do not add any customer tracking that’s outside of the normal functioning of or stated purpose of your product.
No Hidden Functions
- Do not purposely obfuscate your code or behavior of your code or in any way intentionally hide or mislead the true purpose of the code or functionality.
