Code Quality: Review Options

This documentation pertains to our Code Quality beta program. If you are interested in joining, please open a ticket with us.

Historically, our code review was based on the strict need to ensure that code on the VIP platform did not adversely affect the overall platform’s stability, security, or general performance. However, the VIP Go platform allows us to experiment with new approaches to code review thanks to its containerized nature. With the new Code Quality beta program, we aim to provide client development teams with guided, non-blocking feedback for more agile and flexible workflows. This feedback is intended to support developer education on best practices and, ultimately, improve the continued performance, security, and maintenance of client applications.

Our feedback is completely optional; clients taking part in the program are free to deploy code and continue development without implementing the recommendations.  Please note that items that fall outside the scope of the review request will not be identified, as some reviews may occur at earlier development stages prior to production (e.g. where further edits and QA are expected). 

We have divided our manual code review for this Code Quality program into three main areas: Security, Performance and Best Practices.

Those taking part in the program will find three new labels in their GitHub repositories: [VIP] Review: Security, [VIP] Review: Performance and [VIP] Review: Best Practices. These labels can then be added to pull requests to indicate code review from the VIP team is requested.  Typically, the turnaround time for code reviews will be one business day or less, but it could take longer depending on the size of the review requested.


We focus on the coding practices that could negatively impact application security by identifying any potential vulnerabilities and exploitable flaws in this review. This may include ensuring that only changes intended by authorized users are enacted through protection measures, defending processes such as handling and storing inputs and external data and that all output is safely escaped within the appropriate context to prevent attackers from exploitation.

Vulnerabilities addressed during the manual review process can greatly improve your application’s security disposition. We believe that code security reviews are not only fundamental from an operational risk standpoint, but they may be in accordance with policies that mandate data privacy, integrity, and corporate governance.

Common topics covered, but not limited to:

  • Input sanitization and validation
  • Access controls
  • Database and other input injections
  • Encoding and escaping of output 
  • Clarity of unescaped variable use
  • Inclusion of content and files


When a code review for performance is requested, we’ll investigate potential inefficiencies that can degrade application stability in layers such as the cache, database, filesystem, and any external services.  During this review, we may require clarification on use cases to assess whether a particular implementation may be of concern and recommend leaving any code comments or additional details in the PR to pre-emptively answer these questions.

We define sub-optimal performance as anything that either unnecessarily delays a completed HTTP response or adds excess load or inefficiently uses web server resources, such as CPU or processing threads, to the server and its components. This type of review will also include the practice of caching for better execution alongside our multiple caching layers. Note: A performance code review is not intended to replace the usage of New Relic, other logs and historical data to profile and review actual site performance and identify opportunities. 

Common topics covered, but not limited to:

  • Query optimization for potential slow queries (e.g. meta, term, sorting, etc.)
  • Proper usage of WP functions (i.e. modifying roles)
  • Scalability concerns
  • Caching to protect the database and external services 
  • Queries in uncached responses (i.e. 404 pages)

Best Practices

We’ll review code for best practices in enterprise WordPress development to ensure it is structured in a way for easier maintenance and compatibility with both the platform and new releases of WordPress Core. Following best practices also help with quickly identifying any issues that may arise during and after development. We recommend checking out the best practices published in the WordPress handbook as a supplemental resource. It’s important to ensure that best practices are followed not only for code consistency but as well for reducing overall errors.

Common topics covered, but not limited to, include:

  • Codebase structure and practice of abstractions
  • Error checking
  • Formatting and clarity, comments, maintainability
  • Usage of filters and hooks
  • CLI script writing
  • Platform compatibility
  • Use of WP and VIP helper functions

Ready to get started?

Drop us a note.

No matter where you are in the planning process, we’re happy to help, and we’re actual humans here on the other side of the form. 👋 We’re here to discuss your challenges and plans, evaluate your existing resources or a potential partner, or even make some initial recommendations. And, of course, we’re here to help any time you’re in the market for some robust WordPress awesomeness.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.