Introduction

Today’s training focused on some of the most important developer-level areas of WordPress:

• How a theme is structured internally
• How themes behave in Multisite environments
• How to quickly test and extend the REST API
• How to automate site management using WP-CLI

I already have hands-on experience building custom WordPress themes. In fact, this very website you’re reading this on runs on a custom WordPress theme I developed from scratch. Still, revisiting the fundamentals helped me connect every layer of the WordPress stack.

---

1. Understanding WordPress Theme Structure

A WordPress theme includes both design files and PHP templates that control how content is displayed.
Typical files you’ll see inside any theme directory:

• style.css – theme info & global styles
• functions.php – adds features, hooks, scripts
• index.php – main template
• single.php, page.php, archive.php, 404.php – specific page templates
• screenshot.png – theme preview image
• For block themes: theme.json, /templates/, /parts/ folders

Docs: Theme Handbook

Minimal example

style.css

/*
Theme Name: Riffaz Me
Theme URI: http://riffaz.me
Author: Riffaz Aman
Author URI: http://riffaz.me
Description: A custom portfolio theme with a blog for showcasing your work.
Version: 1.0
License: GNU General Public License v2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html
Tags: portfolio, blog, responsive, bootstrap
Text Domain: rif
*/

index.php

<?php get_header(); ?>


<div class="container">
    <?php if (have_posts()) : while (have_posts()) : the_post(); ?>
        <h2><a href="<?php the_permalink(); ?>"><?php the_title(); ?></a></h2>
        <div class="entry">
            <?php the_content(); ?>
        </div>
    <?php endwhile; endif; ?>
</div>

<?php get_footer(); ?>

2. WordPress Multisite – How Themes Work Differently

In a Multisite Network, themes aren’t installed individually per site.
They are installed once at the Network Admin level and then enabled for each site.

Key points:

• Only the network admin can install or delete themes.
• A theme must be network-enabled before sites can activate it.
• Site admins can activate any enabled theme, but can’t upload new ones.

Docs: WordPress Multisite Overview

In a Multisite network, themes are centrally managed install once, enable globally, then activate per site.

2.1 Creating and Using a Child Theme

A Child Theme is a lightweight theme that inherits all templates and functionality from another theme, known as the Parent Theme.
It lets you customize or extend your site without touching the parent’s code, so your changes remain safe when the parent theme updates.

---

When to Use a Child Theme

• You’re customizing a downloaded or premium theme
• You want to override specific templates or styles
• You plan to add functions or modify layouts without editing the main theme files

---

Basic Child Theme Structure

/wp-content/themes/
   ├── parent-theme/
   └── my-child-theme/
        ├── style.css
        └── functions.php

---

Example: style.css

/*
 Theme Name: Riffazme Child
 Template: riffazme
 Version: 1.0.0
 Description: Child theme for the Riffazme theme.
 Author: Riffaz
*/

Template must match the folder name of the parent theme exactly

functions.php

<?php
// Enqueue parent + child styles
add_action('wp_enqueue_scripts', function () {
    // Parent stylesheet
    wp_enqueue_style(
        'riffazme-parent',
        get_template_directory_uri() . '/style.css',
        [],
        wp_get_theme(get_template())->get('Version')
    );

    // Child stylesheet
    wp_enqueue_style(
        'riffazme-child',
        get_stylesheet_uri(),
        ['riffazme-parent'],
        wp_get_theme()->get('Version')
    );
}, 20);

---

Activating the Child Theme

1. Zip your child theme folder (or upload via FTP).
2. Go to Appearance → Themes → Activate “My Child Theme.”
3. WordPress will automatically use templates from the child if they exist, otherwise fall back to the parent.

---

Key Benefit

You can safely update the parent theme anytime your customizations stay intact.

---

Docs: Official Child Theme Guide

---

3. REST API – Modern Access to WordPress Data

The REST API lets external apps, mobile clients, or even your own JavaScript communicate with your site data in JSON format.

Try these sample GET requests:

• Posts: /wp-json/wp/v2/posts
• Pages: /wp-json/wp/v2/pages
• Users: /wp-json/wp/v2/users

Add a quick custom endpoint

add_action('rest_api_init', function () {
  register_rest_route('my/v1', '/ping', [
    'methods'  => 'GET',
    'callback' => fn() => ['ok' => true, 'time' => time()],
    'permission_callback' => '__return_true',
  ]);
});

Visit /wp-json/my/v1/ping – We sould see the above custom JSON response.

Docs: REST API Handbook

---

4. WP-CLI – Command Line Power for WordPress

WP-CLI allows developers to manage WordPress installations directly from the command line, perfect for automation, debugging, and deployments.

Essential commands to try

wp --info
wp core version
wp plugin list
wp theme list
wp cache flush
wp user list
wp post list --post_type=page --fields=ID,post_title,post_status --format=table

Docs: WP-CLI Command List

Introduction

Today’s focus was on debugging WordPress effectively and understanding the core parts of WordPress development that every support engineer must know.

I began by learning how to turn on debugging safely using constants in wp-config.php, and then explored three powerful helper plugins, Query Monitor, WP Crontrol, and User Switching to track performance issues, manage cron events, and reproduce user-specific bugs.

After mastering debugging, I moved into core WordPress development:

• creating a small plugin,
• basic concept of creating plugins
• custom post types
• custom taxonomies
• wp_query

This day tied everything together showing how WordPress works under the hood, and how to quickly troubleshoot, extend, and optimize any site with professional-level tools.

---

01. Defining Debugging Constants in WordPress

When working as a support engineer or developer, debugging is your best friend — but it should always be enabled safely. WordPress allows you to control what errors appear and where they’re stored using a few simple constants inside wp-config.php.

Add the following lines above the comment /* That's all, stop editing! Happy publishing. */:

define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true ); // WP 5.2 +: show real fatal errors while developing 

define( 'WP_DEBUG', true ); // turn on WordPress debug mode 

define( 'WP_DEBUG_DISPLAY', false ); // hide errors from the browser 

define( 'WP_DEBUG_LOG', true ); // log all errors to /wp-content/debug.log 

define( 'SCRIPT_DEBUG', true ); // load unminified core CSS and JS files

What Each Constant Does

Constant	Purpose
WP_DISABLE_FATAL_ERROR_HANDLER	Disables WordPress’ built-in “white screen protection,” so you can view actual fatal errors while developing. (Only use this on local or staging environments.)
WP_DEBUG	Enables all PHP notices, warnings, and errors for WordPress and plugins.
WP_DEBUG_DISPLAY	Hides errors from the frontend or admin area to avoid breaking layouts.
WP_DEBUG_LOG	Saves all errors to /wp-content/debug.log, which can be opened in any text editor.
SCRIPT_DEBUG	Forces WordPress to use non-minified core files, making it easier to trace JS and CSS issues.

Where to View the Log

Open the file:
example.com/wp-content/debug.log

You can also use a plugin such as Log Viewer or Error Log Monitor to read this log directly from the dashboard.

02. Helper Plugins for Debugging in WordPress

There are certain WordPress plugins that make it much easier to debug PHP errors, actions, filters, enqueued scripts and stylesheets, and even HTTP requests.
In this section, we’ll go over three essential ones Query Monitor, WP Crontrol, and User Switching and see how each helps during development and troubleshooting.

Plugin	Purpose	How I Used It
Query Monitor	Shows PHP errors, database queries, HTTP requests, hooks & actions, scripts, and performance bottlenecks.	Checked for slow database queries and heavy hooks on page load.
WP Crontrol	Lets you view and manage cron events and scheduled tasks.	Disabled duplicate or unnecessary cron jobs during testing.
User Switching	Quickly switch between users without logging out/in.	Reproduced role-specific bugs (Subscriber vs Admin) safely.

Query Monitor

Query Monitor adds a complete developer tools panel inside WordPress.
It lets you inspect almost everything happening behind the scenes:

• Database queries (with execution time and source)
• PHP errors and notices
• Hooks and actions currently running
• Enqueued scripts and styles
• REST API and Ajax calls
• HTTP API requests and responses
• Block Editor blocks and capability checks

The plugin automatically adds a toolbar entry in the WordPress admin bar; click it to open detailed tabs for each section.

Why it’s useful
Query Monitor instantly shows slow database queries or heavy hooks, helping identify performance bottlenecks. It’s a must-have in every development or staging site.

Here’s a brief introduction about the plugin and what information it displays and where:

You can learn more on the plugin’s page

💡 Idea to Explore → Using Query Monitor to Identify Performance Bottlenecks

If your WordPress site feels slow or inconsistent, Query Monitor can help you see what exactly is taking time:

1. Activate the plugin, open any front-end page, and then open the admin bar → “Query Monitor.”
2. Go to the Queries tab:
   • Sort by Time to find the slowest SQL queries.
   • Look for repeating queries or ones touching custom tables.
   • Note the calling function (helps find which plugin/theme is responsible).
3. Check Hooks & Actions → shows how many callbacks each hook has. Too many actions on init or wp_head can slow down loading.
4. HTTP Requests tab → see external API calls that may delay page rendering.
5. Scripts & Styles tab → identify plugins enqueueing large CSS/JS files on every page.
6. Summary panel → total queries, peak memory usage, PHP execution time.

Goal:

• Anything consistently over 0.05 seconds per query or memory use above 64 MB on simple pages is worth optimizing.

Example

“If a plugin is making 40 duplicate queries per page. Disabling it cut load time from 2.5 s to 1.3 s.”

WP Crontrol

WP Crontrol allows you to view, manage, and debug WordPress Cron events directly from the admin area.
From its interface you can:

• View all cron events with their hooks, arguments, recurrence, and next-run time
• Edit, delete, or immediately run any event
• Add custom cron events or custom schedules
• Bulk-delete unwanted events
• Export cron events to a CSV file

Why it‘s useful
This plugin helps verify whether scheduled tasks (like emails, imports, or backups) are running properly. A common cause of “nothing happens” issues in WordPress.

You can read more about WP Crontrol on its plugin page.

User Switching

User Switching lets you instantly swap between user accounts without logging out and back in.
Normally, testing as a specific user means resetting passwords and logging in manually; this plugin saves all that time.

Helpful when:

• An issue appears only for specific users or roles (e.g., “Subscriber can’t see button”)
• You need to test restricted content, membership, or checkout flows for different roles

Just click Switch To under any user in Users → All Users, and you’ll be logged in as them instantly. A single click restores your original admin session.

You can check more details on the User Switching plugin page.

I also went through (quickly) xDebug and JavaScript with Chrome DevTool for language specific debugging

---

After completing the debugging and helper plugins session, I took a short lunch break.
Once back, I moved on to the Basic Plugin Development module starting with how plugins are structured, how to register them properly, and how WordPress hooks (actions and filters) connect everything behind the scenes.

---

03. Basic Plugin Development – Quick Start

Before diving into the deeper APIs, I focused today on understanding how plugins are structured and how hooks connect everything inside WordPress.

I began with a quick hands-on experiment using an MU-plugin to understand how WordPress executes hooks, and then gradually explored how actions and filters form the core of every plugin.

---

Understanding Hooks with an MU-Plugin

Before building a regular plugin, I tested how WordPress triggers hooks internally by creating a small MU-plugin (Must-Use Plugin).
MU-plugins load automatically on every request, making them perfect for experiments and debugging.

Steps followed:

1. Created a new folder: wp-content/mu-plugins/
2. Added a file: wp-content/mu-plugins/hook-watcher.php

hook-watcher.php

<?php 
/** 
* Plugin Name: Hook Watcher (MU) 
* Description: Logs every hook that fires — for learning purposes only. 
*/ 

if ( ! defined( 'ABSPATH' ) ) exit; 

// Extremely noisy — use only on local environment 
add_action( 'all', function ( $hook ) { 
 error_log( $hook ); } 
);

With WP_DEBUG_LOG enabled, this script records every WordPress hook into /wp-content/debug.log.

What I Observed

Opening the log showed a long list of hook names like:

---

🧩 3. Hooks – Actions and Filters

Hooks are the backbone of WordPress extensibility. They allow plugins, themes, and even core to “talk” to each other.

Type	What It Does	Example
Action Hook	Runs custom code at a specific point.	add_action( 'init', 'my_function' );
Filter Hook	Modifies data before it’s displayed or saved.	add_filter( 'the_content', 'my_filter' );

🟢 Actions → “Do something.”
🟢 Filters → “Change something.”

---

Testing a Global Filter

To understand how powerful filters are, I tried adding this inside my MU-plugin:

add_filter( 'render_block', function( $block ){ 
  return '<img src="https://picsum.photos/' . rand(200,400) . '" />'; 
});

Effect:
This replaces every rendered block on the site with a random image from Picsum.
It clearly shows how a filter can intercept and modify the final output before display.
(And yes, remove this after testing 😄)

---

💡 Ideas to Explore

1️⃣ What is the purpose of add_action() and how is it implemented?
add_action() attaches your custom function to a hook so it runs at a specific moment.

add_action( 'init', 'register_custom_post_type' );

Use when you want to run code (register a CPT, enqueue scripts, schedule tasks, etc.).

---

2️⃣ How does add_filter() work, and when would you use it?
add_filter() modifies or formats data before it’s output or saved.

add_filter( 'the_title', 'prefix_modify_title' ); 
  function prefix_modify_title( $title ) { 
  return '👉 ' . $title; 
}

Use when you need to alter text, markup, or data dynamically.

---

3️⃣ What’s the difference between do_action() and apply_filters()?

Function	Purpose	Example
do_action()	Executes all callbacks added with add_action()	do_action( 'init' );
apply_filters()	Passes a value through all add_filter() callbacks and returns it	$title = apply_filters( 'the_title', $title );

• add_action() ↔ do_action() = execute code.
• add_filter() ↔ apply_filters() = modify and return data.

---

4️⃣ How can you prioritize Actions or Filters?
Both accept a priority number (default is 10).
Lower numbers run earlier; higher numbers run later.

add_action( 'init', 'early_function', 5 ); 
add_action( 'init', 'late_function', 20 );

Use priority to control the order when multiple functions are attached to the same hook.

---

✅ Summary

• MU-plugins are great for quick experiments and debugging.
• add_action() runs your code at a specific point.
• add_filter() modifies data before it appears.
• do_action() and apply_filters() are what actually fire those hooks.
• Priority lets you decide the order of execution.

Together, these form the core foundation of how every WordPress plugin works.

04. Custom Post Types and Taxonomies – Quick Run

With limited time left in the day, I did a short but practical run on Custom Post Types (CPTs) and Custom Taxonomies. Two features that make WordPress flexible beyond posts and pages.

---

1. Custom Post Types

A Custom Post Type lets you create new types of content. For example, Books, Projects, or Reviews, each with its own editor and structure.

You register a CPT using the register_post_type() function, usually inside a plugin or in functions.php.

Example:

function create_books_cpt() {
    $labels = array(
        'name'          => 'Books',
        'singular_name' => 'Book',
        'add_new_item'  => 'Add New Book',
        'edit_item'     => 'Edit Book',
        'menu_name'     => 'Books',
    );

    $args = array(
        'public'        => true,
        'has_archive'   => true,
        'rewrite'       => array( 'slug' => 'books' ),
        'supports'      => array( 'title', 'editor', 'thumbnail', 'excerpt' ),
        'show_in_rest'  => true, // enables Gutenberg & REST API
        'labels'        => $labels,
        'menu_icon'     => 'dashicons-book-alt',
    );

    register_post_type( 'book', $args );
}
add_action( 'init', 'create_books_cpt' );

---

Key Arguments and Labels in register_post_type()

Parameter	Purpose
labels	Defines all text displayed in the admin for this CPT (name, add new, edit, etc.).
public	Makes it visible on the frontend and admin menu.
has_archive	Creates an archive page like /books/.
rewrite	Defines custom URL slug for the CPT.
supports	Enables features like title, editor, thumbnail, etc.
show_in_rest	Enables block editor and REST API support.
menu_icon	Sets a custom icon in the dashboard menu.

👉 In short: labels control the text users see; args control how the post type behaves.

---

2. Custom Taxonomies

A taxonomy groups related posts together. For example, genres for books or skills for projects.
WordPress includes two default taxonomies: Categories and Tags, but you can create your own.

Example:

function create_book_genre_taxonomy() {
    register_taxonomy(
        'genre',
        'book',
        array(
            'label'        => 'Genres',
            'rewrite'      => array( 'slug' => 'genre' ),
            'hierarchical' => true, // true = like categories, false = like tags
            'show_in_rest' => true,
        )
    );
}
add_action( 'init', 'create_book_genre_taxonomy' );

---

When to Create a Custom Taxonomy

Create a custom taxonomy when you need to organize or filter a custom post type beyond the default categories or tags.
Examples:

• Book Genres for “Books”
• Project Types for “Portfolio”
• Locations for “Events”

---

✅ Summary

• Custom Post Types let you add new content types (Books, Projects, etc.).
• Key arguments: labels, public, supports, rewrite, show_in_rest, has_archive.
• Custom Taxonomies group content within those post types.
• Use them when default categories/tags don’t fit your structure.

05. WP_Query – Custom Queries in WordPress

I also did a quick review of WP_Query, the main class that controls how WordPress retrieves posts from the database.

What is WP_Query?

WP_Query is the core query class that WordPress uses to fetch posts, pages, or custom post types based on specific conditions — for example, only posts from a certain category, author, or date range.

It gives developers complete control over which posts are displayed and in what order.

Example:

$query = new WP_Query( array(
    'post_type'      => 'book',
    'posts_per_page' => 5,
    'orderby'        => 'date',
    'order'          => 'DESC',
) );

if ( $query->have_posts() ) {
    while ( $query->have_posts() ) {
        $query->the_post();
        the_title( '<h3>', '</h3>' );
    }
    wp_reset_postdata();
}

---

How WP_Query Differs from get_posts() and query_posts()

Function	Description	When to Use
WP_Query	The main, flexible class for custom queries. Returns a query object you can loop through safely.	Use in custom templates, plugins, or shortcodes.
get_posts()	A simplified wrapper for WP_Query that just returns an array of posts (not the full query object).	Use when you only need raw post data and won’t run a loop.
query_posts()	A deprecated approach that modifies the main query directly (can break pagination or global query).	Avoid using this. Prefer pre_get_posts or a custom WP_Query.

---

✅ Summary

• WP_Query = the main and most flexible query class in WordPress.
• get_posts() = lightweight shortcut, returns post arrays only.
• query_posts() = modifies the main query and should generally be avoided.

In short:

Use WP_Query when you want full control, get_posts() when you just need data, and skip query_posts() entirely.

And then I scrolled through (Core APIs):

• Metadata API
• Shortcode API
• Administration Menus
• Settings & Options API

If you are up to learn deep plugin development you can learn them from WordPress codex.

Then I created a plugin folder structure using the WordPress Plugin Boilerplate Generator which was suggested in the assignment section.

With that I completed the quiz as well.

Introduction

As part of my WordPress Technical Support Engineer Training, after completing the environment setup on Day 1, today’s focus was to install and configure a full-fledged Integrated Development Environment (IDE) using Visual Studio Code, set up Z Shell (Oh My Zsh) for a faster command-line workflow, and explore the basics of Git and SVN.

Tools Installed & Configured

• Visual Studio Code
• WordPress Playground Extension
• Z Shell + Oh My Zsh
• Git & SVN

1. Installing Visual Studio Code

1️⃣ Downloaded and installed VS Code from https://code.visualstudio.com.

2️⃣ Installed essential extensions for WordPress development: https://marketplace.visualstudio.com/items?itemName=WordPressPlayground.wordpress-playground

• WordPress Playground (launch WordPress instantly inside VS Code)

We can install the following extensions too if we need:

• PHP Intelephense
• Prettier – Code Formatter
• GitLens – Git super-charged
• ESLint
• Markdown All in One
• Live Server

3️⃣ Verified installation via terminal:

code --version

4️⃣ Opened the local project folder directly in VS Code:

code .

2. Using WordPress Playground Extension

The WordPress Playground extension lets you spin up a full WordPress site inside VS Code without installing PHP or MySQL.

Steps:

1️⃣ Open VS Code → Extensions → Search WordPress Playground → Install.
2️⃣ Click the WordPress icon in the Activity Bar.
3️⃣ Select Start WordPress Server.
4️⃣ It opens your project in a browser with a live WP environment. This is perfect for quick plugin or theme testing.

” If the extension doesn’t start on Windows, keep LocalWP as a fallback that we created in day 1.

3. Setting Up Z Shell (Zsh) and Oh My Zsh

To improve terminal speed and readability, I installed Zsh and configured Oh My Zsh for plugins and themes.

Installation commands:

sudo apt install zsh -y chsh -s $(which zsh)

Install Oh My Zsh:

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

For windows:

Zsh is does not natively support Windows. Instead, we can try Oh My Posh.

In short:

• 🧩 Zsh & Oh My Zsh → Need Linux/macOS or WSL.
• ⚙️ Oh My Posh → Windows-friendly equivalent with similar benefits.

winget install JanDeDobbeleer.OhMyPosh -s winget

Recommended plugins (I did not try these but good if you want to explore a bit):

• git
• z
• autojump
• zsh-autosuggestions
• zsh-syntax-highlighting

Feature / Aspect	Zsh (Z Shell)	Oh My Zsh
Type	Command-line shell (replacement for Bash)	Framework / configuration manager for Zsh
Purpose	Provides an enhanced shell environment	Simplifies managing Zsh configuration, themes, and plugins
Installation	Installed as a standalone shell using package manager (sudo apt install zsh)	Installed after Zsh via a curl or wget script
Default Features	Basic improvements over Bash: better tab completion, spelling correction, globbing	Ships with 100+ themes and 200+ plugins pre-configured
Configuration File	Uses ~/.zshrc (manual editing needed)	Also uses ~/.zshrc, but auto-populated with friendly defaults
Customization	Fully manual (you add aliases, prompt styles, functions yourself)	Managed via simple edits — enable/disable plugins and themes easily
Themes	None by default (plain prompt)	Comes with many built-in themes like robbyrussell, agnoster, powerlevel10k
Plugins	Must install and configure manually	Includes plugin system — just add names in plugins=(git z ...)
Ease of Use	Requires manual setup and knowledge of config syntax	Ready-to-use immediately after install; beginner-friendly
Performance	Slightly faster since it loads fewer scripts	Slightly slower at startup because of extra plugins and themes
Best For	Power users who want full control	Developers who want a quick, beautiful, and feature-rich shell
Example Installation	sudo apt install zsh	sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

4. Introduction to Git and SVN

I explored how Git and SVN work, focusing on core commands.
I already covered Git and Git CLI installation yesterday here

Git basics:

git init

git clone <repo-url>

git add .

git commit -m "Initial commit"

git branch feature

git checkout feature

git merge feature

git push origin main

SVN overview: SVN is centralized version control, while Git is distributed.
Understanding this helps when working with older WordPress plugin repositories that still use SVN for releases.

---

A real-world onboarding journey showing what engineers actually do and learn, step by step, from setup to debugging.

---

Introduction

Day 1 marks the start of the technical phase of this onboarding journey. Today’s focus was on building a consistent development environment, the foundation that every support engineer needs before working on real-world issues.

Even after years of experience in WordPress support and plugin development, I found this phase refreshing. It reminded me that structured setup and common tooling standards are what make a team’s debugging and deployment workflow faster and more predictable.

This post documents how I aligned my own environment with the agency (I joined) recommended stack from installing NVM and Composer to configuring Z Shell and LocalWP in a hybrid style that shares both steps and real-world insights.

Tools Installed & Configured

1. NVM & Node.js (v22.11.0)

• Installed Node v22.11.0 using NVM for version control.
  • I followed this tutorial to install NVM first: https://www.freecodecamp.org/news/node-version-manager-nvm-install-guide/ (NMV Windows)
• Verified installation with node -v and npm -v.

I ran into an interesting error when I tried to install Node js. The error was

'node' is not recognized as an internal or external command

After the succesful Node installation when I ran

node -v

Fixing NVM setup on Windows

I realised I ran into activation errors due to spaces in my user folder name (C:\Users\Cyber Action).

To fix it, I:

1. Created new folders:

C:\nvm4w
C:\nvm4w\nodejs

2. Updated settings.txt at C:\Users\Cyber Action\AppData\Local\nvm\settings.txt to:

root: C:\nvm4w
path: C:\nvm4w\nodejs

3. Deleted the physical C:\nvm4w\nodejs folder, then re-ran:

nvm install 22.11.0
nvm use 22.11.0

4. Verified everything with:

node -v
npm -v
where node
where npm

Output confirmed Node 22.11.0 + NPM 10.9.0 working under C:\nvm4w\nodejs\.

• Benefit → Keeps global packages clean and allows easy switching between versions for different projects.

2. Composer

• Installed the latest Composer globally. Followed this: https://getcomposer.org/
• Tested setup with composer -V.
• Confirmed autoloading paths work with WordPress plugin structures.

3. WGET

Installing wget on Windows

I installed wget using:

winget install wget

This will install the wget regardless your region’s Microsoft Store source.

After installation, I restarted the terminal to refresh the PATH variable.
Verified it with:

wget --version

Further readings: https://formulae.brew.sh/formula/wget

4. Git & GitHub CLI

Version control is a key part of any technical or support workflow.
Even if we don’t write production-level code daily, knowing Git helps us clone customer sites, test fixes, and push changes when collaborating with development teams.

---

Installing Git

Start by installing Git for Windows from git-scm.com/download/win.
During installation, keep the default settings but make sure to select:

“Git from the command line and also from 3rd-party software.“

After setup, confirm Git works:

git --version

Expected output:

git version 2.46.0.windows.1

Installing & Linking GitHub CLI

Next, install GitHub CLI from cli.github.com.
This command-line tool helps manage repositories, pull requests, and issues directly. Ideal for plugin or theme support workflows.

After installing, verify it:

gh --version

Then run:

gh auth login

Follow the prompts:

1. Choose GitHub.com
2. Select HTTPS
3. Choose Yes for Git authentication
4. Pick Login with a web browser

Your terminal will show a short code like 2C15-A532 and open a page asking you to confirm the login.
Enter that code and authorize access.

You’ll see:

✓ Authentication complete. Logged in as riffaz

However, if you see this message:

unable to find git executable in PATH; please install Git for Windows before retrying

It simply means GitHub CLI detected no Git installation.
Just install Git from git-scm.com as shown above, then re-run:

gh auth status

It should now confirm:

✓ Logged in to github.com as riffaz

✓ Git operations for github.com configured to use https protocol.

Why this matters

This combination of Git and GitHub CLI allows technical engineers to:

• Clone or fork repositories for debugging.
• Reproduce or verify issues reported by customers.
• Track commits, branches, and pull requests directly from the terminal.

Together, they form the foundation for collaborative, code-aware technical support.

5. Setting up Local Development Environment

For a WordPress Technical Support Engineer, having a local development environment is essential. It lets you reproduce client issues safely, test fixes before deploying them, and experiment with plugins or code without affecting live sites.

You can set up a local environment using tools like LocalWP, Lando, or wp-env.
Since I’m on Windows, I used LocalWP, which is the simplest and most stable option for WordPress development.

---

🔧 Step 1 – Install LocalWP

• Go to https://localwp.com
• Download the Windows version and install with default settings.
• No special configuration is needed — just launch the app after installation.

---

⚙️ Step 2 – Create Your First Test Site

Once installed:

1. Open LocalWP
2. Click “Create a New Site”
3. Name it something like test1 (I used this name for my setup)
4. Choose Preferred Environment (PHP 8+, MySQL 8+, Nginx or Apache — defaults are fine)
5. Set up your WordPress admin credentials (for test use, I used admin / admin)
6. Once setup completes, click “Open Site”

Your new WordPress site should now open at something like:
http://test1.local

🧠 Step 3 – Verify Everything Works

LocalWP automatically installs PHP, MySQL, and WP-CLI.

After creating your site in LocalWP, you’ll see it listed in the left sidebar.
Click on your site name (for example, Test1). This opens the site overview screen.

At the top of this screen, right below the site name, you’ll find two links:

Site folder | Site shell

Click “Site shell” — it will open a terminal window (Command Prompt or PowerShell) connected directly to your local WordPress environment.

From there, you can run commands like:

wp --info

to confirm WP-CLI is working and properly connected to your site.

🧩 Step 4 – Optional: Install a Test Plugin

To confirm everything is working smoothly, I installed Query Monitor, a debugging plugin often used in support:

wp plugin install query-monitor --activate

Then I logged into wp-admin and confirmed it appeared under “Plugins.”

Everything worked perfectly on the first run.

Real-World Onboarding Series (Day 0) by an experienced WordPress technical support engineer

---

I recently joined a leading WordPress agency that provides structured onboarding for Support Engineers. These posts are inspired by the training steps from that process.

---

Why this series?

I’ve worked with WordPress for 10+ years as an engineer and support specialist.
I’m starting a focused, 14-day series to document how a professional WordPress Technical Support Engineer works from local setup and debugging to coding standards, security, and communication with clients.

It’s a real-world workflow you can follow to prepare for agency work, plugin/theme support roles, or high-quality freelance support.

Who is it for?

• Developers moving into technical support
• Support engineers who want a clean, repeatable workflow
• Agencies onboarding new team members
• Freelancers who handle WooCommerce / plugin conflicts and performance issues

What you’ll learn (14-day roadmap)

Day 1 – Setting up a reliable local environment and using debugging tools (WP-CLI, Query Monitor, logs)
Day 2 – WPCS & PHPCS: clean, review-ready code
Day 3 – Security basics: sanitizing, escaping, nonces, safe queries
Day 4 – WordPress Core overview: hooks, filters, plugin/theme loading order
Day 5 – WP_Query & request lifecycle: tracing issues the right way
Day 6 – Gutenberg & FSE: block troubleshooting, patterns, theme.json basics
Day 7 – Gutenberg deep-dive: common editor bugs & fixes
Day 8 – WordPress.com vs self-hosted: hosting realities, staging, backups
Day 9 – Performance mindset: caching, images, asset loading, Core Web Vitals
Day 10 – Top 10 support cases & how to triage fast (plugins, themes, PHP versions)
Day 11 – Communication & tickets: reproducible steps, summaries, hand-offs
Day 12 – Week 1 recap: what to keep, what to automate
Day 13 – Week 2 recap: block editor, performance, workflows
Day 14 – Final checklist & resources to keep improving

How to use this series

• Read a day, apply it on a test site, and keep short notes.
• Save commands and snippets into your own knowledge base.
• Share with teammates, this doubles as a mini onboarding guide.

What you’ll need

• A local WordPress install (Local, DevKinsta, or similar)
• Basic Git knowledge (optional)
• A text editor (I use Notepad++ )
• Access to a staging site (optional but helpful)

My promise

I’ll keep each day short, practical, and written in simple English.
You’ll get clear steps, tools, and checklists that you can reuse in real client work.

Next post: Day 1 – Setting Up a WordPress Support Environment & Debugging Like a Pro.