Welcome to Lesson 104 of our Flipnzee Auctions plugin development series. In the previous lessons, we successfully implemented winner determination, automatic transaction creation, and transfer record generation after an auction was closed manually.

One limitation still remained: auctions depended on an administrator to change their status from Active to Closed. In a real auction marketplace, this process should happen automatically. In this lesson, we introduce an automated auction lifecycle that allows the plugin to activate scheduled auctions, close expired auctions, determine winners, and update the frontend without manual intervention.

Why Automatic Auction Processing Matters

An auction marketplace should continue functioning even when no administrator is logged into WordPress.

The plugin should automatically:

• Activate auctions when their scheduled start time arrives.
• Close auctions after the end time.
• Determine the winning bidder.
• Begin the post-auction workflow.
• Prevent additional bids after the auction ends.

This automation makes the marketplace significantly more reliable and scalable.

Objectives

By the end of this lesson, the plugin will:

• Automatically activate scheduled auctions.
• Automatically close expired auctions.
• Determine winners for automatically closed auctions.
• Log auction lifecycle events.
• Fire WordPress hooks for future integrations.
• Hide the bidding form after the auction ends.
• Display a professional “Auction Closed” message to visitors.

Scheduling the Maintenance Process

The plugin already registered a scheduled maintenance event using WordPress Cron.

During activation, the maintenance event is scheduled:

if ( ! wp_next_scheduled( 'flipnzee_auction_maintenance' ) ) {

    wp_schedule_event(
        time(),
        'hourly',
        'flipnzee_auction_maintenance'
    );

}

During plugin deactivation, the scheduled event is removed:

$timestamp = wp_next_scheduled(
    'flipnzee_auction_maintenance'
);

if ( $timestamp ) {

    wp_unschedule_event(
        $timestamp,
        'flipnzee_auction_maintenance'
    );

}

This prevents orphaned scheduled events from remaining in WordPress.

Registering the Maintenance Hook

The scheduled event must execute plugin code.

We connected the cron event to the Auction Manager:

add_action(
    'flipnzee_auction_maintenance',
    array(
        'Flipnzee_Auction_Manager',
        'run_scheduled_maintenance',
    )
);

Whenever WordPress runs the scheduled event, the auction maintenance routine is executed automatically.

Creating the Maintenance Method

Inside the Auction Manager we created a dedicated method responsible for all automated auction lifecycle operations.

public static function run_scheduled_maintenance() {

    self::activate_scheduled_auctions();

    self::update_expired_auctions();

}

This creates a clean orchestration layer that can easily be expanded later.

Future maintenance tasks can simply be added here.

Automatically Closing Expired Auctions

The plugin searches for all auctions that:

• are still Active
• have an end date earlier than the current time

SELECT id
FROM wp_flipnzee_auctions
WHERE status='active'
AND auction_end < current_time()

The matching auctions are then updated to:

Status = Closed

without administrator intervention.

Automatically Determining Winners

Before updating the auction status, the plugin stores the list of expired auction IDs.

After closing them, each auction is processed individually:

foreach ( $expired_auctions as $auction_id ) {

    Flipnzee_Bid_Manager::determine_winner(
        (int) $auction_id
    );

}

This guarantees every closed auction immediately receives a winner.

Logging Automatic Closures

Whenever one or more auctions are automatically closed, an activity log entry is created.

Example:

3 auction(s) automatically closed.

This gives administrators a historical record of automated maintenance.

Introducing a New Action Hook

After processing expired auctions we introduced a brand-new action hook:

do_action(
    'flipnzee_auctions_expired_processed',
    $updated_count
);

This hook allows future extensions to respond whenever auction maintenance finishes.

Possible integrations include:

• Analytics updates
• Email notifications
• Cache invalidation
• Third-party marketplace integrations
• Custom reporting

Following WordPress hook architecture keeps the plugin modular and extensible.

Updating the Frontend

One remaining issue existed.

Although auctions were closed successfully, buyers could still see:

• Bid amount field
• Place Bid button

Obviously, no additional bids should be accepted.

We solved this by displaying the bidding interface only when the auction status is Active.

if ( 'active' === $auction['status'] ) {

    // Display bidding form.

}

Otherwise, visitors now see an auction summary.

Showing the Auction Closed Message

Instead of the bidding form, the plugin now displays:

🏆 Auction Closed

Winning Bid:
$10.00

If no bids were placed, the interface displays:

No bids were placed.

This provides a much clearer experience for buyers.

Final Result

After completing this lesson, the auction lifecycle now works as follows:

Auction Created
        │
        ▼
Scheduled Start
        │
        ▼
Auction Automatically Activated
        │
        ▼
Users Place Bids
        │
        ▼
Highest Bid Tracked
        │
        ▼
Auction Automatically Closed
        │
        ▼
Winner Determined
        │
        ▼
Transaction Created
        │
        ▼
Transfer Record Created
        │
        ▼
Auction Closed Message Displayed

The entire process now requires virtually no manual intervention after an auction has been created.

What We Learned

In this lesson we learned how to:

• Schedule recurring plugin maintenance using WordPress Cron.
• Register custom cron actions.
• Build a centralized maintenance routine.
• Automatically close expired auctions.
• Automatically determine auction winners.
• Record automated activity logs.
• Introduce extensible WordPress action hooks.
• Improve the frontend after auction completion.
• Hide bidding controls once an auction has ended.

Download Source Code

Download the starting version of the plugin before the lesson:

Download the completed version after this lesson:

Conclusion

Lesson 104 marks an important milestone in the Flipnzee Auctions plugin. With automatic auction lifecycle management in place, the marketplace now behaves much more like a production-ready auction platform. Auctions can activate, expire, determine winners, create transactions, initiate transfer workflows, and update the user interface without requiring continuous administrator oversight.

In the next lesson, we will continue refining the marketplace by introducing additional automation and administrative improvements that build upon this fully automated auction lifecycle.

After several lessons of building the Flipnzee Auctions plugin, Lesson 103 represents one of the most significant milestones in the project. With this implementation, the auction lifecycle now extends beyond simply determining the winning bidder. Once an auction is closed, the plugin automatically creates the necessary transaction and transfer records that will be used throughout the payment and website transfer process.

This lesson transforms the plugin from an auction system into a complete marketplace workflow.

Objective

The primary goal of this lesson was to automate the actions that occur immediately after an auction closes.

The desired workflow was:

Auction Closed
        ↓
Determine Winner
        ↓
Create Transaction
        ↓
Create Transfer Status
        ↓
Ready for Payment & Website Transfer

Until now, the winning bidder was identified, but the remaining steps had to be handled manually or were not created at all.

Previous Behaviour

Before Lesson 103, when an administrator changed an auction status to Closed, only the auction status was updated.

Although a winning bidder could be determined, there was no automatic creation of:

• Transaction record
• Transfer record
• Payment workflow

As a result, the marketplace process stopped immediately after the auction ended.

New Workflow

The auction lifecycle now continues automatically.

Administrator closes auction
        ↓
Auction updated
        ↓
Winning bidder determined
        ↓
winner_user_id stored
        ↓
Transaction record created
        ↓
Transfer status record created

No manual database operations are required.

Winner Determination

The existing winner determination method was integrated directly into the auction closing workflow.

The method:

• Finds the highest bid
• Uses earliest bid as the tiebreaker
• Updates the auction record
• Stores:
• winner_user_id
• current_bid

Finally it fires the custom action:

do_action(
    'flipnzee_auction_winner_determined',
    $auction_id,
    $winner
);

This makes the winner determination process reusable throughout the plugin.

Automatic Transaction Creation

Once the winner is determined, the Transaction Manager now automatically creates a transaction.

Each transaction stores:

• Auction ID
• Listing ID
• Seller ID
• Buyer ID
• Winning bid
• Initial payment status

Duplicate transactions are prevented by checking whether a transaction already exists for the auction before inserting a new record.

Automatic Transfer Creation

Immediately after creating the transaction, the plugin now creates the corresponding transfer status record.

The transfer contains individual workflow stages including:

• Payment Status
• Website Files
• Database
• Domain
• Buyer Confirmation
• Administrator Notes

This lays the foundation for tracking the complete ownership transfer process.

Improved Logging

During implementation extensive debugging logs were added to trace the execution flow.

Examples included:

Auction was closed.
Looking for winner.

Winner determined.

Transaction created.

Transfer created.

These logs proved invaluable while diagnosing execution order, missing callbacks, and event flow during development.

Once the implementation is fully tested, most temporary debug logs can be removed to keep production logs clean.

Problems Encountered

Several issues were discovered during implementation.

Missing Transaction Creation

Initially, closing an auction only updated the auction record.

No transaction was created because the transaction workflow was never triggered.

Incorrect Method Call

An earlier implementation attempted to call:

Flipnzee_Bid_Manager::get_highest_bid()

The method no longer existed.

It was replaced with the existing:

Flipnzee_Bid_Manager::determine_winner()

which already contained the required business logic.

Undefined Variables

During testing, undefined variables prevented the transaction manager from receiving the correct auction information.

These variables were corrected before invoking the transaction creation process.

Duplicate Protection

The transaction manager now verifies whether a transaction already exists for the auction before creating another one.

This prevents accidental duplicate transactions if an auction is processed more than once.

Database Verification

Testing confirmed that all related tables are updated correctly.

Auction Table

The auction now stores:

• Winner User ID
• Current Winning Bid
• Closed Status

Transactions Table

A new transaction record is created containing:

• Auction ID
• Listing ID
• Seller ID
• Buyer ID
• Winning Bid
• Pending Status

Transfer Status Table

A matching transfer record is automatically created with:

• Payment Completed
• Files Pending
• Database Pending
• Domain Pending
• Buyer Pending

This confirmed the entire workflow executed successfully from start to finish.

Current Auction Lifecycle

The Flipnzee Auctions plugin now performs the following complete backend workflow:

Create Auction
        ↓
Place Bids
        ↓
Determine Winner
        ↓
Store Winner
        ↓
Create Transaction
        ↓
Create Transfer Status
        ↓
Ready for Payment Workflow

This represents one of the largest functional improvements since development of the plugin began.

Download Source Code

Download the starting version of the plugin before the lesson:

Download the completed version after this lesson:

Lessons Learned

Lesson 103 reinforced several important development principles:

• Reuse existing business logic instead of creating duplicate methods.
• Trigger downstream processes through well-defined events.
• Validate database changes through direct inspection.
• Protect against duplicate record creation.
• Use detailed logging while developing complex workflows.
• Verify every stage of a multi-step process independently.

Conclusion

Lesson 103 completes one of the most important backend milestones of the Flipnzee Auctions plugin. The auction engine no longer stops after identifying a winner. Instead, it automatically generates the transaction and transfer records required for the remainder of the marketplace lifecycle.

With this implementation in place, the plugin now supports a seamless transition from bidding to payment preparation and website transfer management. Future lessons can build upon this solid foundation by adding payment gateway integration, automated notifications, transfer progress tracking, and enhanced post-auction administration.