In the previous lesson, we successfully installed and activated the Flipnzee Auctions plugin on our WordPress website. Even though the plugin doesn’t yet display any visible functionality, WordPress already recognizes it as a valid plugin and executes its code whenever appropriate.

But have you ever wondered what actually happens behind the scenes?

How does WordPress discover plugins?

When does it read the plugin header?

Why does the ABSPATH constant already exist?

When are activation hooks executed?

And why do they run only once?

Understanding these questions is one of the biggest differences between simply copying WordPress code and becoming a confident WordPress plugin developer.

In this lesson, we’ll follow the complete journey of our plugin—from the moment a visitor requests a page until our code is executed.

---

Learning Objectives

By the end of this lesson, you’ll understand:

• How WordPress discovers installed plugins.
• What happens during plugin activation.
• What happens during every page request.
• Why the ABSPATH security check works.
• When your plugin code executes.
• The purpose of activation and deactivation hooks.
• Why understanding the plugin lifecycle makes debugging easier.

---

Why This Matters

Many beginners think WordPress “magically” loads plugins.

It doesn’t.

There is a very specific sequence of events.

Once you understand that sequence, many concepts become much easier:

• Hooks
• Filters
• AJAX
• REST APIs
• Database creation
• Custom Post Types
• Scheduled tasks

Almost every advanced WordPress feature depends on understanding when your code runs.

---

The Journey Begins

Imagine someone visits:

https://flipnzee.com

The browser sends a request to the web server.

The web server loads WordPress.

WordPress then begins its own startup process.

Eventually it reaches the point where it starts loading plugins.

---

Step 1 — WordPress Finds Active Plugins

WordPress stores the list of active plugins in its database.

During startup it reads that list.

If your plugin is active:

Flipnzee Auctions

WordPress prepares to load:

flipnzee-auctions/flipnzee-auctions.php

This is why the main plugin file is so important.

---

Step 2 — WordPress Reads the Plugin Header

Before executing the plugin, WordPress reads the comment block at the top of the file.

/**
 * Plugin Name: Flipnzee Auctions
 * Version: 1.0.0
 * ...
 */

This information is displayed on:

Plugins → Installed Plugins

Notice something interesting.

The plugin header is metadata.

PHP ignores it.

WordPress reads it.

---

Step 3 — PHP Begins Executing Your File

Now PHP starts reading your code.

The very first executable line is:

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

At this point WordPress has already defined:

ABSPATH

So the condition evaluates to:

false

The plugin continues loading.

If someone tried opening the PHP file directly in a browser:

https://example.com/wp-content/plugins/flipnzee-auctions/flipnzee-auctions.php

ABSPATH wouldn’t exist.

The plugin would immediately exit.

That’s why this simple security check is so important.

---

Step 4 — Constants Are Defined

Next WordPress executes:

define('FLIPNZEE_AUCTION_VERSION', '1.0.0');

Then

define('FLIPNZEE_AUCTION_PATH', ...);

Then

define('FLIPNZEE_AUCTION_URL', ...);

These constants remain available throughout the rest of the request.

---

Step 5 — Activation Hooks Are Registered

WordPress encounters:

register_activation_hook(...)

Notice the wording carefully.

We are registering the activation hook.

We are not executing it.

This often confuses beginners.

WordPress simply remembers:

“If this plugin is activated in the future, run this function.”

---

Step 6 — Additional Files Are Loaded

Next we load:

includes/class-loader.php

PHP reads the file.

The class becomes available.

Then we create:

new Flipnzee_Auction_Loader();

Its constructor executes immediately.

Right now the constructor is empty.

Later it will register all our actions, filters, REST routes, AJAX handlers, database classes, auction engine, payment system, and more.

---

The Complete Lifecycle

Here’s the entire process.

Browser Request
        │
        ▼
Web Server
        │
        ▼
WordPress Starts
        │
        ▼
Find Active Plugins
        │
        ▼
Read Plugin Header
        │
        ▼
Execute PHP
        │
        ▼
Security Check
        │
        ▼
Define Constants
        │
        ▼
Register Hooks
        │
        ▼
Load Classes
        │
        ▼
Plugin Ready

Every page request follows this sequence.

---

What Happens During Activation?

Activation is different.

It occurs only when you click:

Activate Plugin

WordPress performs:

Load Plugin

↓

Execute Activation Function

↓

Return Control

Your activation function currently contains:

flush_rewrite_rules();

Later we’ll expand it to:

• Create database tables.
• Create default settings.
• Set plugin version.
• Prepare the auction system.

---

What Happens During Deactivation?

When you deactivate the plugin:

WordPress executes:

flipnzee_auction_deactivate()

Currently it refreshes rewrite rules.

Later we’ll also:

• Remove scheduled tasks.
• Clear caches.
• Perform cleanup.

Notice that we won’t delete auction data during deactivation.

Users expect their data to remain if they reactivate the plugin later.

---

Understanding One Important Difference

Many beginners think:

Activation happens every time a page loads.

It doesn’t.

Activation occurs once.

Normal plugin loading occurs on every request.

Understanding this distinction prevents many common mistakes.

---

Improving Our Development Workflow

As our project grows, we’ll start generating temporary files such as plugin ZIP archives.

Rather than storing these generated files in Git, professional developers use a .gitignore file to tell Git which files should be ignored.

In the next lesson, we’ll create our first .gitignore file and begin adopting even more professional development practices.

---

Lesson Summary

In this lesson, we explored the complete lifecycle of a WordPress plugin. We learned how WordPress discovers plugins, reads plugin headers, executes PHP code, registers hooks, and loads classes. We also distinguished between activation, deactivation, and the normal loading process that occurs on every page request.

Understanding this lifecycle gives us a strong conceptual foundation for every feature we’ll build in the remaining lessons.

---

Key Takeaways

• ✓ WordPress loads active plugins during every request.
• ✓ Plugin headers are read by WordPress, not PHP.
• ✓ ABSPATH exists because WordPress has already started.
• ✓ Activation hooks are registered during loading but execute only during activation.
• ✓ Classes are loaded only after the main plugin file executes.
• ✓ Understanding the plugin lifecycle makes debugging much easier.

---

Common Mistakes

• Assuming activation hooks run on every page load.
• Placing expensive operations outside hooks, causing them to execute on every request.
• Removing user data during plugin deactivation.
• Confusing plugin registration with plugin execution.

---

Git Commands Used

git add .

git commit -m "Lesson 3: Understand the WordPress plugin lifecycle"

git push

---

Project Status

✅ Development environment

✅ Plugin skeleton

✅ Plugin installation

✅ Plugin lifecycle

⬜ .gitignore

⬜ Database tables

⬜ Auction data model

⬜ Bidding engine

⬜ Escrow

⬜ Payment gateways

⬜ Website transfer

⬜ Version 1.0

---

Developer’s Notebook

One of the biggest milestones in becoming a professional WordPress developer is realizing that your code doesn’t run in isolation. Every plugin participates in WordPress’s startup process. The better you understand that process, the easier it becomes to write efficient, secure, and maintainable plugins. Throughout the remainder of this series, we’ll continue referring back to the plugin lifecycle as we introduce hooks, database tables, AJAX, REST APIs, and background tasks.

---

Looking Ahead

In Lesson 4, we’ll create our first .gitignore file and begin preparing the project for long-term development. We’ll also discuss which files belong in Git, which should never be committed, and why professional developers treat generated files differently from source code.

Welcome to Lesson 1 of the Building Flipnzee Auctions series.

In the previous lesson, we created our GitHub repository, launched GitHub Codespaces, organized our project, and learned the basics of version control.

Now it’s time to write our first PHP code.

By the end of this lesson, you’ll have a WordPress plugin that appears in the Plugins page of your WordPress website and can be activated just like any other plugin.

Although the plugin won’t do anything yet, this is an exciting milestone because we’re laying the foundation for everything that follows.

---

What You’ll Learn

In this lesson you’ll learn how to:

• Create the WordPress plugin folder
• Create the main plugin file
• Understand the plugin header
• Protect your plugin from direct access
• Define reusable plugin constants
• Register activation and deactivation hooks
• Create a simple loader class
• Commit your changes to GitHub

---

Step 1: Enter the Plugin Folder

Open the integrated terminal in GitHub Codespaces.

Navigate into the plugin folder:

cd flipnzee-auctions

Confirm your location:

pwd

You should see something similar to:

/workspaces/flipnzee-auctions/flipnzee-auctions

From now on, everything we create belongs inside this folder.

---

Step 2: Create the Main Plugin File

Create the plugin’s main PHP file.

GUI Method

Click New File in the Explorer.

Create:

flipnzee-auctions.php

Terminal Method

touch flipnzee-auctions.php

Open it:

code flipnzee-auctions.php

---

Step 3: Add the Plugin Header

Copy the following code into the file.

<?php
/**
 * Plugin Name: Flipnzee Auctions
 * Plugin URI: https://flipnzee.com
 * Description: Professional website auction platform for Flipnzee.
 * Version: 1.0.0
 * Author: Splendid Digital Solutions
 * Author URI: https://flipnzee.com
 * License: GPL v2 or later
 * Text Domain: flipnzee-auctions
 * Domain Path: /languages
 * Requires at least: 6.5
 * Requires PHP: 8.1
 */

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

Save the file.

Congratulations!

You’ve just created the smallest possible WordPress plugin.

---

Understanding the Plugin Header

Everything inside the comment block is called the Plugin Header.

When WordPress scans the plugins directory, it looks for these special comments.

Let’s understand each line.

Plugin Name

Plugin Name: Flipnzee Auctions

This is the name displayed on the Installed Plugins page.

---

Plugin URI

Plugin URI: https://flipnzee.com

This points users to the official plugin website.

---

Description

Description: Professional website auction platform for Flipnzee.

A short explanation shown beneath the plugin name.

---

Version

Version: 1.0.0

Every release should have a version number.

Later we’ll learn about semantic versioning.

---

Author

Author: Splendid Digital Solutions

Displays the plugin developer.

---

Author URI

Author URI: https://flipnzee.com

Links to your website.

---

Text Domain

Used for translating the plugin into different languages.

---

Requires PHP

Requires PHP: 8.1

Prevents installation on servers running older PHP versions.

---

Step 4: Protect Against Direct Access

Immediately below the plugin header we added:

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

Why?

Imagine someone tries to visit:

https://example.com/wp-content/plugins/flipnzee-auctions/flipnzee-auctions.php

directly in their browser.

Without this check, PHP would execute the file outside of WordPress.

By checking whether ABSPATH exists, we ensure the file only runs when WordPress has already been loaded.

This is one of the simplest and most important WordPress security practices.

---

Step 5: Define Plugin Constants

Below the security check add:

define('FLIPNZEE_AUCTION_VERSION', '1.0.0');

define('FLIPNZEE_AUCTION_PATH', plugin_dir_path(__FILE__));

define('FLIPNZEE_AUCTION_URL', plugin_dir_url(__FILE__));

Constants allow us to define values once and reuse them throughout the plugin.

For example:

FLIPNZEE_AUCTION_PATH

is much cleaner than repeatedly writing:

plugin_dir_path(__FILE__)

---

Step 6: Register the Activation Hook

Add:

function flipnzee_auction_activate() {

    flush_rewrite_rules();

}

register_activation_hook(__FILE__, 'flipnzee_auction_activate');

This function runs automatically when the plugin is activated.

Today it only refreshes WordPress rewrite rules.

Later it will also create our database tables.

---

Step 7: Register the Deactivation Hook

Add:

function flipnzee_auction_deactivate() {

    flush_rewrite_rules();

}

register_deactivation_hook(__FILE__, 'flipnzee_auction_deactivate');

This runs whenever the plugin is deactivated.

---

Step 8: Create the Includes Folder

Professional plugins avoid placing thousands of lines inside one file.

Create a folder named:

includes

Inside it, create a new file:

class-loader.php

---

Step 9: Load the Loader Class

Back in flipnzee-auctions.php, add:

if (file_exists(FLIPNZEE_AUCTION_PATH . 'includes/class-loader.php')) {
    require_once FLIPNZEE_AUCTION_PATH . 'includes/class-loader.php';
}

This prepares the plugin for modular development.

---

Step 10: Create the Loader Class

Open:

includes/class-loader.php

Add:

<?php

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

class Flipnzee_Auction_Loader
{

    public function __construct()
    {

    }

}

new Flipnzee_Auction_Loader();

Although the class is currently empty, it will eventually load every component of our plugin, including auctions, bids, payments, reports, APIs, and notifications.

---

Folder Structure After Lesson 1

flipnzee-auctions/

│
├── flipnzee-auctions.php
│
└── includes/
      └── class-loader.php

---

Commit Your Changes

Open Source Control.

Use the commit message:

Lesson 1: Create plugin skeleton

Commit your changes.

Then click Sync Changes.

Your plugin skeleton is now safely stored in GitHub.

---

Summary

Congratulations!

You’ve officially written your first WordPress plugin.

Although it doesn’t yet contain any auction functionality, you’ve created the foundation that every future lesson will build upon.

Lesson Summary

In this lesson, we built the foundation of the Flipnzee Auctions plugin using GitHub Codespaces. We created the main plugin file, added the WordPress plugin header, protected the plugin from direct access, defined reusable constants, registered activation and deactivation hooks, and introduced a loader class to prepare for a modular architecture.

Although the plugin is still in its early stages, we’ve established a professional project structure that will allow us to add features in a clean and maintainable manner as the series progresses.

---

Key Takeaways

• ✓ Every WordPress plugin begins with a properly formatted plugin header.
• ✓ WordPress automatically discovers plugins by reading their headers.
• ✓ The ABSPATH check prevents direct access to plugin files.
• ✓ Plugin constants reduce repetition and improve maintainability.
• ✓ Activation and deactivation hooks allow WordPress to execute code at important points in the plugin lifecycle.
• ✓ A loader class helps organize larger plugins into smaller, reusable components.

---

Common Mistakes

When completing this lesson, beginners often encounter one or more of the following issues:

• Creating files in the GitHub repository root instead of the flipnzee-auctions plugin folder.
• Forgetting to save files before committing changes.
• Omitting the opening <?php tag.
• Misspelling one of the required plugin header fields.
• Creating the includes folder in the wrong location.
• Forgetting to commit and sync changes to GitHub.

If your plugin does not appear in the WordPress Plugins page, review each of these items before moving on.

---

Git Commands Used

During this lesson, we used the following Git and terminal commands:

cd flipnzee-auctions

touch flipnzee-auctions.php

mkdir includes

touch includes/class-loader.php

git add .

git commit -m "Lesson 1: Create plugin skeleton"

git push

---

Project Status

✅ Development environment ready

✅ GitHub repository created

✅ GitHub Codespaces configured

✅ Plugin skeleton completed

⬜ Database installation

⬜ Auction engine

⬜ Bidding system

⬜ Escrow workflow

⬜ Payment gateways

⬜ Website transfer

⬜ Reports & Analytics

⬜ REST API

⬜ Version 1.0 Release

---

Source Code

The complete source code for this project is maintained in the official GitHub repository.

Rather than embedding the full source code in every lesson, the GitHub repository serves as the single source of truth and always contains the latest version of the project. This allows the tutorial series to focus on explaining concepts and design decisions while ensuring readers have access to the most up-to-date implementation.

(Insert your GitHub repository link here.)

---

Developer’s Notebook

One of the biggest mistakes new developers make is trying to build an entire application before creating a solid foundation.

Professional software projects evolve incrementally. We start with a minimal but well-structured plugin, verify that it works, and then add one feature at a time. This approach makes debugging easier, keeps the codebase organized, and reduces the likelihood of introducing difficult-to-find bugs.

Throughout this series, you’ll see the Flipnzee Auctions plugin grow from a simple plugin skeleton into a fully featured website auction platform. By following this step-by-step approach, you’ll not only build a working plugin but also gain insight into how experienced WordPress developers approach large software projects.

---

Looking Ahead

In Lesson 2, we’ll package our plugin into a ZIP file, install it on a WordPress website, activate it, and verify that WordPress recognizes it as a valid plugin. This will be the first time we see the Flipnzee Auctions plugin running inside WordPress.

---