Overview

In Lesson 59, the Flipnzee Auctions plugin gained a dedicated Activity Log page that displays the contents of the log file. While functional, presenting raw log entries inside a text area isn’t ideal for administrators managing a busy auction marketplace.

In this lesson, we’ll redesign the Activity Log page by displaying each log entry in a clean WordPress-style table with separate columns for the timestamp, event, auction ID, user ID, and details.

What You Will Learn

• Read and parse log entries from a text file.
• Convert plain text into structured PHP arrays.
• Build a professional HTML table using WordPress admin styling.
• Improve readability for administrators.
• Lay the foundation for future features like search, filtering, pagination, CSV export, and log deletion.

Current Output

Recent auction activity recorded by the plugin.

[2026-07-05 19:19:14] Event: auction_auto_closed | Auction: 0 | User: 0 | Details: 1 auction(s) automatically closed.

New Output

Why This Improvement Matters

Displaying logs as structured data makes them much easier to:

• scan quickly
• troubleshoot auction problems
• identify system events
• prepare for future search and filtering

It also gives the plugin a much more polished and professional appearance.

Implementation Roadmap

Step 1

Read the activity log file.

Step 2

Split the file into individual log entries.

Step 3

Extract:

• timestamp
• event
• auction ID
• user ID
• details

using PHP string functions or regular expressions.

Step 4

Store each entry in an array.

Step 5

Generate a WordPress admin table.

Step 6

Handle empty or missing log files gracefully.

Step 7

Test with multiple log entries.

Skills Covered

• File parsing
• String manipulation
• Arrays
• Regular expressions
• WordPress admin UI
• HTML tables
• Defensive programming

Expected Outcome

By the end of this lesson, the Flipnzee Auctions plugin will feature a professional Activity Log dashboard where every event is neatly organized into columns, making monitoring and troubleshooting significantly easier.

I think this is a strong progression from Lesson 59 because it builds directly on the feature you just implemented while introducing practical PHP skills such as file parsing and structured data handling. It also creates a solid foundation for future lessons like searching logs (Lesson 61), clearing logs (Lesson 62), or exporting logs to CSV (Lesson 63).

Difficulty

Intermediate

What You’ll Learn

In this lesson, you’ll build the first administrative interface for the new logging system.

Instead of opening activity.log via File Manager or FTP, administrators will be able to read recent plugin activity directly from the WordPress dashboard.

By the end of this lesson, your plugin will:

• Read the activity log file
• Display recent entries inside wp-admin
• Handle missing log files gracefully
• Limit the number of displayed entries
• Escape output securely
• Prepare the foundation for future filtering and search

Why This Matters

Professional plugins don’t require developers to inspect server files.

They provide useful diagnostics directly inside WordPress.

This lesson transforms the logging system from a developer-only feature into an administrator-friendly tool.

What We’ll Build

A new admin page similar to:

Flipnzee Auctions
│
├── Dashboard
├── Auctions
├── Activity Log   ← NEW
└── Settings

The page will display something like:

Recent Activity

[2026-07-05 19:19:14]
Auction automatically closed

------------------------------------

[2026-07-05 18:42:03]
Bid placed

------------------------------------

[2026-07-05 17:58:10]
Auction created

Implementation Roadmap

Step 1

Create a new admin page:

Activity Log

Step 2

Locate

wp-content/uploads/
flipnzee-logs/activity.log

Step 3

Read the log safely using WordPress filesystem functions.

Step 4

Display only the most recent entries (for example, last 100 lines).

Step 5

Escape all output using:

esc_html()

Step 6

Show a friendly message if the log file doesn’t exist:

No activity has been recorded yet.

Step 7

Add basic styling for readability.

Best Practices You’ll Learn

• Reading files safely
• Preventing XSS with escaped output
• Building admin pages
• Working with plugin-generated files
• Preparing data for future search/filter features

Files We’ll Modify

admin/class-admin.php

admin/class-admin-activity-log.php   (new)

assets/admin.css   (optional)

Skills You’ll Gain

After this lesson, you’ll know how to:

• Create professional admin tools
• Display plugin-generated files
• Build diagnostic pages
• Improve administrator experience
• Extend your plugin without touching the frontend

What Comes Next

After completing this lesson, we’ll continue with:

Lesson 60 – Add a “Clear Activity Log” Button with WordPress Nonce Protection

In that lesson, administrators will be able to safely clear the activity log from the dashboard, while learning secure form handling and nonce verification.

This sequence will gradually turn Flipnzee Auctions into a production-quality WordPress plugin with professional monitoring and maintenance features.

When developing the Flipnzee Auctions plugin, a valuable architectural issue emerged during testing. Because the same listing was used repeatedly, multiple auction records were created for a single listing. Although this was acceptable during development, it exposed an important design flaw.

A marketplace listing should normally have only one auction associated with it. If multiple auction records exist for the same listing, the frontend may display an older auction instead of the latest one, leading to incorrect bid history, current bid values, and auction status.

In this lesson, the plugin will be improved to enforce a one-listing-one-auction relationship, ensuring cleaner data and more predictable behaviour.

What Problem Are We Solving?

During testing, several auction records existed for the same listing:

Listing ID 491

├── Auction #25
├── Auction #26
├── Auction #27
├── Auction #30
└── Auction #31

Although Auction #31 contained the latest bids, the frontend displayed Auction #25 because it appeared first in the query results.

The correct design should always be:

Listing ID 491
        │
        ▼
     Auction #31

One listing should always reference one auction.

Objectives

By the end of this lesson, the plugin will:

• Prevent multiple auction records for the same listing.
• Detect when an auction already exists.
• Update the existing auction instead of creating another.
• Keep auction history clean.
• Ensure the frontend always displays the correct auction.

Implementation Plan

The implementation will include the following improvements:

Step 1

Check whether an auction already exists for the selected listing before inserting a new record.

Step 2

If an auction already exists:

• Update its prices.
• Update auction dates.
• Update reserve price.
• Update Buy Now price.
• Preserve the same auction ID.

Step 3

Only create a new auction if no auction exists for that listing.

Step 4

Display an admin notice such as:

An auction already exists for this listing. The existing auction has been updated instead of creating a duplicate.

This makes the behaviour clear to administrators.

Step 5

Verify that frontend shortcodes always display the latest auction because only one auction record exists.

Expected Benefits

After completing this lesson:

• Cleaner database structure.
• No duplicate auctions.
• Correct bid history.
• Correct highest bidder.
• Correct current bid.
• Easier maintenance.
• Better user experience.

What You Will Learn

This lesson introduces an important database design principle:

Enforce data integrity at the application level rather than relying on users to avoid mistakes.

Instead of allowing duplicate auction records and trying to handle them later, the plugin will proactively prevent them from being created.

This small architectural improvement will make the Flipnzee Auctions plugin significantly more reliable as development continues.

Coming Up Next

In the next implementation lesson, we will modify the auction creation logic so that every listing can have only one associated auction, automatically updating the existing auction whenever the administrator edits its settings instead of creating duplicate records.

I would revise Lesson 51 rather than discard it. The feature you implemented is still useful, but the title and objective should reflect what it actually does.

Revised Lesson 51

Lesson 51: Automatically Close Auctions After the End Time

What This Lesson Covers

In this lesson, we’ll make the auction system automatically recognize when an auction has reached its end time.

Instead of requiring an administrator to manually close auctions, the plugin will automatically update the auction status to closed whenever a visitor interacts with the auction after its scheduled end.

This prevents late bids from being accepted and ensures auctions finish at the correct time.

What We Implement

✔ Compare the current UTC time with the auction end time.

✔ Automatically change the auction status from active to closed.

✔ Prevent any future bids from being accepted.

✔ Keep the auction data intact for later display.

Why This Matters

Without automatic closure:

• Auctions could remain active indefinitely.
• Users might continue placing bids after the deadline.
• Administrators would have to close every auction manually.

With this improvement:

• Auctions close themselves automatically.
• The database always reflects the correct status.
• The bidding system becomes much more reliable.

What We Did

Inside the bid validation process, we checked whether the auction had already expired.

If the current UTC time is greater than or equal to the auction end time, we immediately update the auction status.

Example:

if ( strtotime( gmdate( 'Y-m-d H:i:s' ) ) >= strtotime( $auction->auction_end ) ) {

    $wpdb->update(
        $auction_table,
        array(
            'status' => 'closed',
        ),
        array(
            'id' => $auction_id,
        ),
        array(
            '%s',
        ),
        array(
            '%d',
        )
    );

    return false;
}

What Happens Now

If a visitor attempts to place a bid after the auction has ended:

1. The plugin checks the auction end time.
2. The auction status is automatically updated to closed.
3. The bid is rejected.
4. Future visitors will also see the auction as closed.

Current Limitation

At this stage, a closed auction is no longer displayed by the frontend shortcode.

While this successfully prevents further bidding, it also hides the auction from visitors.

We’ll improve this behavior in the next lesson.

Next Lesson

Lesson 52: Display Closed Auctions with Winner Information

Instead of hiding completed auctions, we’ll:

• Display an Auction Closed badge.
• Show the winning bidder.
• Display the winning bid.
• Keep the bid history visible.
• Hide only the bidding form.
• Create a permanent auction record for visitors.