Lesson 3: Understanding the WordPress Plugin Lifecycle
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
ABSPATHsecurity 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.
- ✓
ABSPATHexists 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.
