Introduction
Welcome to the XWP Engineering Best Practices. Many engineers before you have started on this same page and gone on to do the best work of their careers.
The XWP Engineering Best Practices are not intended to teach anyone to become an engineer. Rather, it is our aim to illustrate how to engineer the WordPress enterprise way. Therefore, these best practices are intended for capable engineers that need to get up to speed quickly on how we do engineering at XWP.
As a company, we strive to provide websites and components that yield a top-notch user experience. In order to improve efficiency, we need to standardize what we use and how we use it. Standardizing our tools, frameworks, libraries, style, version control, and even languages will allow us to better understand the inner workings of someone else's project and produce better solutions ourselves.
As such, our engineers should follow these best practices in all their work. Our best practices are not meant to be restrictive or comprehensive; we value your creativity. The aim is for these documents to provide a strong guidance, not an authoritative direction. It's our hope that these best practices will not only influence our engineers but community members as well.
At the very heart of XWP is content publishing, or user experience. WordPress, we firmly believe, is the best starting point to achieve this. We design and build custom publishing experiences for major companies and brands around the world. Our publishing experiences or websites are tailor-made for our clients and their specific needs.
As such, the content management experience cannot be made to be generic. We don't cut corners when it comes to user experience and interface. We don't take shortcuts that compromise the end experience for the user. We don't distribute pre-packaged, auto-generated user interfaces or components.
While our solutions are complex, we want our code, tools, processes, systems, and practices to be as simple as possible. Simplicity facilitates collaboration as there is a lower barrier of entry. This goes for things like PHP design patterns as well as workflows. We discourage practices such as writing extra levels of code abstraction (wrapping existing API's) as they complicate debugging and add another component that needs to be maintained.
We are constantly challenging ourselves and learning. Knowledge gives everyone a competitive edge. We must all continue to grow and if we stop growing individually or collectively and stop challenging ourselves to improve, we fall behind. For that reason, these documents are not set in stone and will change. Evolving these best practices through contributions is incredibly important to us.
Please contribute via pull requests on GitHub or if you're a member of the team you can also draft changes to the GitBook directly. This documentation was originally forked from 10up in 2015 and modified for XWP and then in 2019 was updated and converted to a GitBook. We want to thank those, both at 10up and previous XWP alum, that put the effort into creating these best practices — starting all the way back in 2011. Reinventing the wheel is not our goal, while diverging and maintaining our own set of best practices is. To those that came before us, we salute you 🖖.
