WordPress Plugin Development

Everyone can contribute to the global and official WordPress repository. There is a contribution form that requires a plugin name, a brief description, and a link to the plugin. The plugin review team conducts a code review and approves the plugin within days if everything works smoothly.

Some candidates may also be involved in WordPress Core development. At DevriX, we have 9+ WordPress Core contributors who have successfully received their commit props while working with us.

Usually GitHub, Bitbucket, GitLab, or another open repository where we can review sample plugins and their development over time. All VCS allow for browsing iterative commits and analyzing how someone thinks and applies changes over time (which many people forget).

There is a fairly detailed list of WordPress APIs available and most developers have utilized at least a dozen of these. Asking for code snippets and practical projects utilizing them as well as details about how they work or what options do they provide, where is data stored, and what sort of sanitization is required or included out of the box helps out.

Given that a WordPress website may be built and launched without coding experience at all, programming experience with PHP outside of WordPress is also important to us.

WordPress developers often don’t need to deal with database management and creating their own schemas, create admin panels and deal with user sessions, build templating engines with routing and rewrite components, or even implement basic features that are mandatory for custom projects.

There are public Coding Standards for WordPress projects focusing on PHP, HTML, CSS, and JavaScript. There’s an accepted set of development best practices and coding conventions that should be followed by plugin developers in order to be backward compatible and maintainable as a project grows.

WordPress plugin development is usually a part of building an ongoing application that depends on other aspects. Aside from other programming languages interacting within and with the website, there are hosting specifics and server configuration arguments that developers should know about viable tools like WP-CLI, and a rough understanding of how the WordPress project grows and develops over time.

Staying in touch with the WordPress community and the make/org websites means that the developer is keeping up with the latest trends and is aware of what changes would be required for the project over time. We’ve declined project offers for components that were scheduled for the next 2 versions of the WordPress Core itself as it makes no sense to build a replica of something that would be available to tens of millions of site owners in 6 months from now.

We don’t care about graduates. Most of our technical staff have graduated successfully (although some of us tried). But there’s a lot going on beneath the surface.

WordPress is a CMS built with PHP and JavaScript handling data in a MySQL database. Programming knowledge is required, as well as algorithms, data structures, and ensuring code readability, stability, security, and performance.

The CMS works on top of a web server (Apache or nginx) through mod_php or php-fpm. Understanding how web servers work and process request and all stability and data management strategies is important.

All of that runs on an operating system coordinating and interacting with the computer hardware. Understanding the impact of CPU spikes, maxing out RAM storage, hitting the server with heavy I/O and best practices for optimization, caching, offloading resources, and denormalizing databases are certainly beneficial.

Then there’s the networking aspect and sending resources over, the TCP/IP protocol and all. In-depth knowledge isn’t required but simply writing code without any clue what’s going on down there is simply unprofessional.

During the interview, we go over all of the steps above. On top of that, we discuss accomplishments and complex problems that have been solved both from a business and technical standpoint. If an applicant says that they’ve created a page template with 2 input fields as the biggest accomplishment, that’s definitely a blocker.

We may also touch on some of the WordPress APIs and discuss what experience candidates have or what do they think those components actually do. Good examples are the Options API, Settings API, or Transients API in terms of data management and processing. Adding custom post types or taxonomies is doable within 20 lines of code or so, but it does so much more underneath that matters for data governance and ongoing maintenance.

We ask candidates to fill out an interview form asking various questions about PHP, WordPress, JavaScript, and SQL. Most of those are fairly basic (such as “what’s the difference between a single-dimensional and multidimensional array” or “how to retrieve the count of elements in an array”) yet some candidates fail to respond these.

We ask them to build a fairly simple project that could be developed within 2–3 hours by a plugin developer with a year of programming experience. That’s usually a simple plugin that registers a post type (say, Events), and a corresponding category (Event Types), registers a metabox with a couple of fields (such as Start Date and End Date) and does a couple more minor things.

We even provide our Plugin Development Framework with 6 pages of detailed documentation for each common API and how it actually works that some candidates can use as a starting ground.