Introduction

After creating the Watchlist database table and integrating it into the database migration framework in the previous lesson, the next logical step was to implement the backend component responsible for interacting with that table.

In this lesson, I developed a dedicated Watchlist Manager class that centralizes all watchlist-related database operations. Rather than scattering SQL queries throughout the plugin, all watchlist functionality is now encapsulated in a single class, following a modular and maintainable architecture.

---

Objectives

The primary objectives of this lesson were:

• Create a dedicated Watchlist Manager class.
• Load the new class into the plugin.
• Initialize database resources efficiently.
• Add auctions to a user’s watchlist.
• Prevent duplicate watchlist entries.
• Remove auctions from the watchlist.
• Retrieve all watchlisted auctions for a user.
• Count how many users are watching an auction.
• Follow WordPress database API best practices.

---

Files Modified

includes/class-watchlist-manager.php

flipnzee-auctions.php

---

Step 1: Created the Watchlist Manager Class

A new class was introduced to isolate all watchlist-related functionality.

class Flipnzee_Watchlist_Manager {

}

This provides a dedicated location for all future watchlist business logic and keeps responsibilities clearly separated from other plugin components.

---

Step 2: Loaded the Class

The new class was registered in the plugin bootstrap so it is automatically available throughout the plugin.

require_once FLIPNZEE_AUCTION_PATH .
    'includes/class-watchlist-manager.php';

This follows the same loading approach used by the rest of the plugin.

---

Step 3: Added Initialization Logic

Instead of repeatedly accessing the database connection and table name throughout every method, an initialization method was implemented.

public static function init() {

    global $wpdb;

    self::$wpdb = $wpdb;

    self::$table = $wpdb->prefix . 'flipnzee_watchlist';

}

This reduces code duplication and centralizes the database configuration.

---

Step 4: Implemented add_to_watchlist()

The first functional method inserts an auction into a user’s watchlist.

public static function add_to_watchlist(
    $auction_id,
    $user_id
)

Before inserting a new record, the method verifies that the auction has not already been added by the same user.

The insertion uses WordPress’s database API:

self::$wpdb->insert()

instead of manually writing SQL.

---

Step 5: Implemented is_in_watchlist()

To prevent duplicate records, a lookup method was added.

public static function is_in_watchlist(
    $auction_id,
    $user_id
)

The method executes a prepared SQL query and returns a boolean value indicating whether a matching watchlist entry already exists.

Prepared statements ensure the query is secure against SQL injection.

---

Step 6: Implemented remove_from_watchlist()

Removing a watchlist entry is now handled by a dedicated method.

public static function remove_from_watchlist(
    $auction_id,
    $user_id
)

The implementation uses:

self::$wpdb->delete()

which follows WordPress coding standards and safely deletes matching records.

---

Step 7: Implemented get_user_watchlist()

A retrieval method was added to fetch all auctions saved by a particular user.

public static function get_user_watchlist(
    $user_id
)

The query returns an associative array ordered by the date the auctions were added to the watchlist.

This method will later power the My Watchlist page and shortcode.

---

Step 8: Implemented count_watchers()

The final method counts how many users are watching a particular auction.

public static function count_watchers(
    $auction_id
)

This functionality will later be used to display auction popularity and provide additional engagement metrics.

---

Security Considerations

Throughout the implementation, WordPress database best practices were followed.

These include:

• Using $wpdb->prepare() for dynamic SQL queries.
• Sanitizing IDs with absint().
• Using $wpdb->insert() instead of raw INSERT statements.
• Using $wpdb->delete() instead of raw DELETE statements.
• Returning consistent boolean or integer values.

These practices improve both security and maintainability.

---

Class Structure

By the end of the lesson, the Watchlist Manager contains the following methods:

Flipnzee_Watchlist_Manager
│
├── init()
├── add_to_watchlist()
├── is_in_watchlist()
├── remove_from_watchlist()
├── get_user_watchlist()
└── count_watchers()

This centralized architecture keeps all watchlist logic in one place and makes future enhancements significantly easier.

---

Testing Performed

The implementation was validated by:

• Creating the new manager class.
• Successfully loading the class into the plugin.
• Verifying PHP syntax after each development step.
• Ensuring the class initialized correctly.
• Confirming all database helper methods compiled successfully.
• Reviewing each database query for correctness.
• Ensuring all SQL operations use WordPress database APIs.

---

Challenges Encountered

During development, careful attention was given to designing a reusable architecture rather than embedding SQL throughout the plugin.

Several design decisions were made to improve long-term maintainability:

• Centralizing database access in a single class.
• Avoiding duplicate watchlist entries.
• Using prepared statements for all SELECT queries.
• Leveraging WordPress helper methods for INSERT and DELETE operations.
• Keeping each method focused on a single responsibility.

This approach makes future debugging and feature development much easier.

---

Lessons Learned

This lesson reinforced several important WordPress development principles:

• Business logic should be separated from presentation logic.
• Database operations are easier to maintain when encapsulated in dedicated manager classes.
• WordPress database helper methods improve readability and security.
• Reusable methods reduce duplication and simplify future development.
• Designing extensible backend components early provides a strong foundation for upcoming AJAX and frontend features.

Download Source Code

Download the starting version of the plugin before the lesson:

Download the completed version after this lesson:

---

Outcome

At the end of this lesson, the Flipnzee Auctions plugin now includes a fully functional Watchlist Manager responsible for all backend watchlist operations. The class provides secure, reusable methods for adding, removing, retrieving, and counting watchlist entries while keeping the plugin architecture clean and modular.

This backend service establishes the foundation for the next phase of development, where the watchlist functionality will be connected to AJAX endpoints and integrated into the user interface for a seamless user experience.

Introduction

With the Watchlist database table successfully added in the previous lesson, the next step is to build the business logic that interacts with it. Rather than allowing different parts of the plugin to access the database directly, we will create a dedicated Watchlist Manager class responsible for handling all watchlist-related operations.

This approach follows the plugin’s modular architecture, keeping database queries centralized, reusable, and easier to maintain.

---

What You Will Learn

In this lesson, you will learn how to:

• Create a dedicated Watchlist Manager class.
• Organize watchlist-related database operations.
• Add and remove auctions from a user’s watchlist.
• Check whether an auction is already in a watchlist.
• Retrieve a user’s watchlisted auctions.
• Follow WordPress database best practices using $wpdb.
• Keep business logic separate from presentation code.

---

Why This Lesson Matters

Although the Watchlist table now exists, it currently has no way to interact with the rest of the plugin.

Instead of writing SQL queries throughout the plugin, we’ll encapsulate all watchlist functionality inside a single class.

This provides several advantages:

• Cleaner code organization
• Easier debugging
• Better code reuse
• Improved security
• Easier future maintenance

---

Planned Features

By the end of this lesson, the new manager class will support methods such as:

add_to_watchlist()

remove_from_watchlist()

is_in_watchlist()

get_user_watchlist()

count_watchers()

Each method will perform one specific task, making the class simple and easy to extend.

---

Proposed File Structure

A new file will be introduced:

includes/
├── class-watchlist-manager.php

The loader will also be updated so the class is automatically available throughout the plugin.

---

Planned Class Structure

Flipnzee_Watchlist_Manager
│
├── add_to_watchlist()
├── remove_from_watchlist()
├── is_in_watchlist()
├── get_user_watchlist()
└── count_watchers()

---

Expected Workflow

When a user clicks Add to Watchlist, the flow will eventually become:

User clicks "Add to Watchlist"
            │
            ▼
Watchlist Manager
            │
            ▼
Validate User
            │
            ▼
Check Duplicate Entry
            │
            ▼
Insert into Database
            │
            ▼
Return Success

Likewise, removing an auction will simply delete the corresponding database record while maintaining data integrity.

---

Best Practices Covered

Throughout this lesson, we’ll follow several WordPress development best practices:

• Use prepared SQL statements.
• Sanitize all user input.
• Prevent duplicate watchlist entries.
• Return consistent boolean or array results.
• Keep database logic inside one dedicated class.
• Maintain compatibility with future AJAX and REST API integrations.

---

Outcome

At the end of this lesson, the Flipnzee Auctions plugin will have a fully functional Watchlist Manager class capable of handling all watchlist database operations. This will provide the core backend functionality needed before implementing the user interface, AJAX interactions, and frontend watchlist features in the upcoming lessons.