What is my techstack? Here are the details how I built WordPress websites with code examples.

The purpose of this article is to introduce you with both my skills and my limits. Click here to go back to projects list.

1. Tooling

I tend to keep dependencies at the minimum, but these tools are essential to my work (links are pointing to GitHub repository of real-life project where you can review file structure and code):

• Composer - for managing theme back-end dependencies and autoloading custom classes encapsulated in Namespaces.
• Timber - for separating template markup from code logic using Twig template engine.
• NPM - for managing theme front-end and dev dependencies.
• Webpack - for modern theme assets transpilation and optimization.
• ACF - for customizing dashboard UI and UX.

2. Tech-stack

• ES6 syntax for javascript files compiled by Babel.
• React for front-end components that communicate with WP Rest asynchronously.
• SCSS syntax with BEM methodology for stylesheet files processed by SASS.

If there are no requirements I try not no rely on additional libraries or frameworks like Tailwind, Fontawesome, Bootstrap or jQuery, especially on small and medium projects to avoid bloat.

3. Theme files structure

To keep theme structure as clean as possible and avoid spaghettification of functions.php file, all custom logic (such as theme's functions, hooks, settings, shortcodes, global variables, etc.) and theme's setup (Post Types, Taxonomies, Options, Endpoints, plugin customizations i.e. ACF and Timber, etc.) is separated into individual files. This is the middle ground between introducing more elaborate theme setup system (i.e. based on autoloaded classes) and keeping things instantly understandable for other developers familiar with WordPress terminology.

Examples of customization.

1. Custom Post Types and Custom Taxonomies

Custom Post Types are the heart of most of my WordPress projects. Be it products, services, events, employees etc. - CPT are the way to go. Each Custom Post Type is registered manually for better control (without any additional plugins to avoid complexity) in a separate file. Additional code related with each registered Type is handled via custom Classes to decouple WordPress' register_post_type process from any custom logic, which is my preference.

Custom Taxonomies' are structured similarily to CPT's: each Custom Taxonomy is registered individually and manually.

2. Custom Queries

Customizations of Main Query is handled via dedicated hooks for best performance. Different Post Types have different order, orderby and posts_per_page settings, and simple manipulation logic via URL parameters for Custom Taxonomies is introduced in order to allow users filter content directly in theme.

3. Custom Rest Endpoints

Most of the secondary queries (i.e. related posts on Single Posts or to display some custom data as a side content) are handled asynchronously via WP Rest to reduce initial server load. This is not always necessary, but for this particular project I didn't have control over post development caching strategy and decided that it will help with optimization, especially for logged in users knowing, that most Cache plugins (like WP Super Cache) don't work well with login feature. There are separate files for both custom and default endpoints to either register or modify response accordingly.

4. Custom Classes

Most of the custom logic related to theme templates is encapsulated in namespaced Classes which are autoloaded via Composer. This is fast and easy way to extend theme functionality without the need to develop extra plugins or to clutter functions.php or template files with additional code. Each Class' name corresponds with its purpose (i.e. connecting with external API or generating Breadcrumbs data for templates) or WordPress Entity (i.e. Custom Post Type or Custom Taxonomy) thus providing clean file structure and easy way to discover custom code for other developers without the need to study hundreds of lines in functions.php file.