As the Flipnzee Auctions plugin continues to evolve into a complete online auction marketplace, it becomes increasingly important to organize the code into well-defined components. After completing automatic winner determination in the previous lesson, the next step was to introduce a dedicated Transaction Manager.

Instead of embedding transaction logic directly inside the Auction Manager, this lesson focuses on building the architectural foundation that will eventually support escrow integration, payment processing, ownership transfer, and transaction history.

In this implementation, no visible changes are introduced to the plugin interface. However, significant backend improvements prepare the plugin for future marketplace features.

---

Why a Transaction Manager?

When an auction ends successfully, several business processes may follow:

• Creating an escrow transaction
• Recording payment information
• Sending buyer and seller notifications
• Tracking ownership transfer
• Marking the transaction as completed

Rather than placing all of these responsibilities inside the Auction Manager, it is better to create a dedicated class responsible only for transactions.

This follows the Single Responsibility Principle (SRP) and makes the plugin easier to maintain and extend.

---

Step 1: Create the Transactions Database Table

The first task was extending the database installer to create a new table.

File modified:

includes/class-database.php

A new table was added:

wp_flipnzee_transactions

using dbDelta().

/*
 * Create transactions table.
 */
$transaction_table = $wpdb->prefix . 'flipnzee_transactions';

$sql = "CREATE TABLE {$transaction_table} (

	id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,

	auction_id BIGINT UNSIGNED NOT NULL,

	listing_id BIGINT UNSIGNED NOT NULL,

	seller_id BIGINT UNSIGNED NOT NULL,

	buyer_id BIGINT UNSIGNED NOT NULL,

	winning_bid DECIMAL(12,2) NOT NULL,

	status VARCHAR(30) DEFAULT 'pending',

	created_at DATETIME DEFAULT CURRENT_TIMESTAMP,

	updated_at DATETIME DEFAULT CURRENT_TIMESTAMP,

	PRIMARY KEY (id),

	KEY auction_id (auction_id),

	KEY buyer_id (buyer_id),

	KEY seller_id (seller_id),

	KEY status (status)

) {$charset_collate};";

dbDelta( $sql );

After reactivating the plugin, the new database table appeared successfully in phpMyAdmin.

---

Step 2: Create the Transaction Manager

A brand-new class was introduced.

New file:

includes/class-transaction-manager.php

Initial class structure:

<?php
/**
 * Transaction Manager.
 *
 * @package Flipnzee_Auctions
 */

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

class Flipnzee_Transaction_Manager {

}

This dedicated class will manage all transaction-related functionality in future lessons.

---

Step 3: Load the New Class

The main plugin loader was updated to include the new class.

File modified:

flipnzee-auctions.php

Code added:

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

This ensures the Transaction Manager is available throughout the plugin.

---

Step 4: Create Transactions Programmatically

The first functional method was added.

/**
 * Create a transaction.
 *
 * @param array $data Transaction data.
 * @return int|false
 */
public static function create_transaction( $data ) {

	global $wpdb;

	$table = $wpdb->prefix . 'flipnzee_transactions';

	$result = $wpdb->insert(
		$table,
		array(
			'auction_id'  => $data['auction_id'],
			'listing_id'  => $data['listing_id'],
			'seller_id'   => $data['seller_id'],
			'buyer_id'    => $data['buyer_id'],
			'winning_bid' => $data['winning_bid'],
			'status'      => 'pending',
		),
		array(
			'%d',
			'%d',
			'%d',
			'%d',
			'%f',
			'%s',
		)
	);

	if ( false === $result ) {
		return false;
	}

	return $wpdb->insert_id;
}

Although not yet connected to auction completion, this method provides the core functionality for creating marketplace transactions.

---

Step 5: Retrieve a Transaction

A second method was implemented for retrieving transaction details.

/**
 * Get a transaction.
 *
 * @param int $transaction_id Transaction ID.
 * @return object|null
 */
public static function get_transaction( $transaction_id ) {

	global $wpdb;

	$table = $wpdb->prefix . 'flipnzee_transactions';

	return $wpdb->get_row(
		$wpdb->prepare(
			"SELECT * FROM {$table} WHERE id = %d",
			$transaction_id
		)
	);
}

Keeping database queries inside the Transaction Manager avoids repeating SQL throughout the plugin.

---

Step 6: Update Transaction Status

Finally, a method was added for updating transaction status.

/**
 * Update transaction status.
 *
 * @param int    $transaction_id Transaction ID.
 * @param string $status         New status.
 * @return bool
 */
public static function update_status(
	$transaction_id,
	$status
) {

	global $wpdb;

	$table = $wpdb->prefix . 'flipnzee_transactions';

	$result = $wpdb->update(
		$table,
		array(
			'status' => sanitize_text_field( $status ),
		),
		array(
			'id' => absint( $transaction_id ),
		),
		array(
			'%s',
		),
		array(
			'%d',
		)
	);

	return false !== $result;
}

This method will later allow the plugin to move transactions through stages such as:

• Pending
• Escrow Started
• Payment Received
• Ownership Transferred
• Completed
• Cancelled

---

Testing the Implementation

After completing the changes:

• The plugin activated successfully.
• No PHP syntax errors were reported.
• The wp_flipnzee_transactions table was successfully created.
• The new Transaction Manager loaded correctly.
• Existing auction functionality remained unaffected.

This confirmed that the new architecture had been integrated without breaking existing features.

Download Source Code

Download the starting version of the plugin before the lesson:

Download the completed version after this lesson:

---

Lessons Learned

This lesson demonstrates an important software engineering principle:

Build the architecture before building the features.

Although users cannot yet create or view transactions, introducing a dedicated Transaction Manager now will make future development much cleaner.

Future features such as escrow integration, payment gateways, notifications, and transaction history can all be implemented within this class without increasing the complexity of the Auction Manager.

---

Final Thoughts

Lesson 62 marks an important milestone in the Flipnzee Auctions project. Rather than focusing on user-facing functionality, this lesson strengthens the plugin’s internal architecture by introducing a dedicated Transaction Manager and transaction database table.

As the plugin grows into a full-featured auction marketplace, this modular design will make future enhancements significantly easier to implement, maintain, and extend.

In the next lesson, we will connect the Auction Manager and the Transaction Manager using WordPress action hooks so that a transaction is created automatically whenever an auction winner is determined. This event-driven approach will further improve the plugin’s flexibility and maintainability.

During the previous lesson, the Flipnzee Auctions plugin gained the ability to record important events such as automatically closing expired auctions. While the log file was successfully written to the server, administrators still needed to open the file manually through the hosting control panel to view it.

In this lesson, the plugin was enhanced with a dedicated Activity Log page inside the WordPress admin dashboard, allowing administrators to view recent activity directly from WordPress.

---

What We Wanted to Achieve

Instead of navigating to:

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

using a file manager, the goal was to provide an easy-to-access interface under the plugin’s own admin menu.

The desired workflow became:

Flipnzee Auctions
    ├── Dashboard
    ├── Add Auction
    ├── Activity Log
    ├── All Auctions
    └── Edit Auction

Selecting Activity Log would display the contents of the log file inside the WordPress dashboard.

---

Step 1 – Create a New Admin Page Class

A new file was created:

admin/class-admin-activity-log.php

This class is responsible for:

• locating the activity log file
• reading its contents
• displaying the information inside the WordPress admin area

Separating this functionality into its own class keeps the plugin modular and easier to maintain.

---

Step 2 – Register the New Class

The new class file was loaded inside the main plugin file.

A conditional require_once statement was added so the class is only included when the file exists.

This follows the same loading pattern used throughout the plugin.

---

Step 3 – Add a New Submenu

A new submenu was registered inside the existing Flipnzee Auctions menu.

Administrators can now access the log from:

Flipnzee Auctions
→ Activity Log

No additional permissions were required because the page already uses the existing administrator capability.

---

Step 4 – Create the Page Callback

Inside the admin class, a new callback method was added.

Its only responsibility is to call the renderer from the Activity Log class.

Keeping the controller small makes future maintenance much easier.

---

Step 5 – Display the Log File

The Activity Log page checks whether the following file exists:

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

If found, the contents are displayed inside a large read-only text area.

If the file does not yet exist, a friendly message is shown instead.

---

Step 6 – Test the Feature

An auction was allowed to expire automatically.

The maintenance task successfully recorded:

Event: auction_auto_closed

along with the number of auctions processed.

Opening the Activity Log page immediately displayed the newly written entry.

This confirmed that:

• the scheduled maintenance worked
• logging worked
• the admin page successfully read the log file

---

A Real Debugging Lesson

During implementation, the plugin initially failed to activate.

The server reported:

PHP Parse error:
unexpected token "public"

The problem turned out to be a missing closing brace (}) inside the register_menu() method.

Because the method never ended, PHP interpreted the next function declaration as being inside another function.

After inserting the missing brace:

}

the plugin activated normally.

This was an excellent reminder that many “fatal plugin errors” are caused by simple structural mistakes.

---

Verifying Syntax Before Uploading

Before uploading the updated plugin, syntax was checked locally using PHP’s built-in linter:

php -l admin/class-admin.php

The result:

No syntax errors detected

Performing this quick validation can save significant debugging time.

---

Final Result

The plugin now includes a fully integrated Activity Log viewer inside WordPress.

Administrators no longer need to browse server folders or download log files manually.

Recent auction activity is available directly from the dashboard with a single click.

Download Source Code

Download the starting version of the plugin before the lesson:

Download the completed version after this lesson:

---

What We Learned

In this lesson we learned how to:

• create a dedicated WordPress admin page
• organize admin functionality into separate classes
• register submenu pages
• display server-generated log files
• safely include new PHP classes
• diagnose plugin activation failures
• use PHP’s syntax checker before deployment
• integrate logging with an administrator-friendly interface

---

Tips

• Keep logging logic separate from display logic.
• Always validate PHP syntax before uploading a plugin update.
• Read server error logs whenever a plugin fails to activate.
• Organize admin pages into dedicated classes instead of placing all code in one file.
• Simple logging features become invaluable when troubleshooting production websites.

---

Outcome: The Flipnzee Auctions plugin now provides a built-in Activity Log page that lets administrators monitor important auction events directly from the WordPress dashboard, making debugging and maintenance much more convenient.

One of the biggest strengths of WordPress is its hook system. Actions and filters allow plugins to communicate with each other without becoming tightly coupled.

In Lesson 56, I took another important architectural step in the development of Flipnzee Auctions by introducing the plugin’s first public lifecycle hook.

Although this lesson adds no visible frontend features, it lays the foundation for future integrations with Flipnzee Analytics and other Flipnzee plugins.

---

Why This Lesson Was Needed

In Lesson 55, I implemented Automatic Auction Lifecycle Management.

Whenever active auctions are retrieved, the plugin now automatically checks for expired auctions and updates their status from Active to Closed.

The feature worked perfectly.

However, there was one limitation.

Only the Auction Manager knew that an auction had been closed.

No other plugin had any way of knowing that an important event had just occurred.

As the Flipnzee ecosystem grows, this would become a problem.

---

Thinking Beyond a Single Plugin

Although Flipnzee Auctions and Flipnzee Analytics are separate plugins, they have always been designed to complement each other.

For example, when an auction closes, future versions of Flipnzee Analytics might want to:

• Update marketplace statistics.
• Refresh dashboard widgets.
• Record lifecycle events.
• Generate reports.
• Trigger conversion tracking.

Without a proper communication mechanism, Analytics would have to modify the Auctions plugin directly.

That isn’t good software architecture.

Instead, the Auctions plugin should simply announce that something has happened and allow any interested plugin to respond.

This is exactly what WordPress Actions were designed to do.

---

Understanding WordPress Actions

A WordPress Action works like an announcement.

Instead of calling another plugin directly, the Auctions plugin simply says:

“I’ve finished processing expired auctions.”

Any plugin that is interested can choose to listen.

If no plugin is listening, nothing happens.

This keeps every plugin independent while still allowing them to work together.

---

Creating the First Flipnzee Lifecycle Event

Inside the update_expired_auctions() method, I first stored the update result in a variable.

$updated_count = ( false === $result ) ? 0 : (int) $result;

Rather than immediately returning the value, I introduced the plugin’s first public action.

do_action(
    'flipnzee_auctions_expired_processed',
    $updated_count
);

Finally, the method returns the number of auctions that were updated.

return $updated_count;

This small change transformed the method from simply updating the database into publishing an event that other plugins can respond to.

---

Why Use an Intermediate Variable?

Previously, the method ended like this:

return ( false === $result ) ? 0 : (int) $result;

That worked perfectly.

However, since the update count now needs to be passed to the action, storing it in a variable makes the code much clearer.

The same value is now:

• passed to the WordPress Action
• returned to the calling method

without repeating the calculation.

---

Improving the Documentation

Since this hook is intended for other developers, I also expanded its documentation.

Instead of simply stating that expired auctions had been processed, the comment now explains:

• why the hook exists
• when it fires
• the parameter it passes
• examples of how future plugins might use it

Good documentation is especially important for public hooks because they become part of the plugin’s public API.

---

An Architectural Decision

During implementation, we briefly considered adding a listener inside the Auctions plugin itself using:

add_action(
    'flipnzee_auctions_expired_processed',
    ...
);

The purpose would have been to demonstrate how the hook worked.

After reviewing the architecture, however, we decided against it.

Adding a listener that only writes to the error log would introduce demonstration code into the production plugin without providing any real functionality.

Instead, we chose to keep the plugin clean.

The hook now exists and is fully documented.

Future plugins can use it whenever they genuinely need to respond to the auction lifecycle.

I believe this results in a much cleaner and more professional design.

---

Preparing the Flipnzee Ecosystem

One of the goals of the Flipnzee Platform is allowing independent plugins to work together without directly depending on each other.

This hook is the first step toward that vision.

Future plugins may simply register their own listeners.

For example:

add_action(
    'flipnzee_auctions_expired_processed',
    'my_custom_function'
);

The Auctions plugin doesn’t need to know anything about that plugin.

Likewise, the Analytics plugin doesn’t need to modify the Auctions plugin.

Each plugin remains independent while communicating through WordPress itself.

---

Testing the Implementation

Since this lesson focused on architecture rather than frontend functionality, testing was straightforward.

After implementing the new hook:

• The plugin passed PHP syntax validation.
• Automatic auction expiry continued to function exactly as before.
• Existing functionality remained unaffected.
• The new lifecycle event is now available for future integrations.

Because no listeners are currently registered, introducing the hook does not change the behaviour of the plugin.

Instead, it quietly prepares the foundation for future development.

---

Lessons Learned

This lesson reminded me that professional software development isn’t always about adding visible features.

Sometimes the most valuable improvements are architectural.

By introducing a public lifecycle event, the plugin has become significantly more extensible without increasing complexity.

Future features such as analytics updates, email notifications, activity logging, and marketplace statistics can all be built on top of this single hook.

---

Looking Ahead

With the first lifecycle event now in place, the plugin is ready for even greater automation.

The next logical step is to ensure auction maintenance happens automatically in the background using WordPress scheduling, rather than only when visitors load auction pages.

That will allow the lifecycle events introduced in this lesson to fire regardless of whether anyone is currently browsing the website.

Download Source Code

Download the starting version of the plugin before the lesson:

Download the completed version after this lesson:

---

Conclusion

Lesson 56 introduced the first public WordPress Action in Flipnzee Auctions.

Although visitors won’t notice any visual changes, this small addition represents an important architectural milestone.

The plugin now follows a more event-driven design, making it easier for Flipnzee Analytics and future plugins to integrate cleanly without modifying the core Auctions plugin.

As the Flipnzee Platform continues to grow, these well-documented hooks will become the foundation that allows multiple plugins to work together while remaining independent, maintainable, and true to WordPress development best practices.

While developing the Flipnzee Auctions plugin, an interesting edge case was discovered. Auctions that were manually marked as Closed from the admin dashboard continued to display a live countdown timer on the frontend. Although bidding was no longer possible, visitors still saw that the auction had many days remaining.

In this lesson, the auction display was updated so that manually closed auctions are presented consistently throughout the website.

---

The Problem

Initially, the auction countdown relied only on the auction end date.

The logic was similar to this:

$current_time >= strtotime( $auction['auction_end'] )

This worked perfectly when an auction naturally expired, but it ignored the auction status stored in the database.

As a result:

• the auction card displayed a red Auction Ended badge,
• the bidding form was disabled,
• yet the countdown still showed something like:

Auction Ends In

41d 2h 53m

This created conflicting information for visitors.

---

Understanding the Cause

Each auction stores a status in the database.

Typical values include:

• draft
• active
• closed

When an administrator manually closes an auction, the status changes to:

closed

However, the auction end date remains unchanged because the scheduled end date is still stored for historical purposes.

Therefore, relying only on the end date was not enough.

---

Updating the Auction Logic

The auction is now considered closed if either of the following conditions is true:

• the auction status is closed, or
• the scheduled end date has already passed.

The logic now looks like this:

$auction_closed =
(
    'closed' === $auction['status']
)
||
(
    current_time( 'timestamp' ) >=
    strtotime( $auction['auction_end'] )
);

This allows the plugin to distinguish between an auction that is still active and one that has been manually closed.

---

Improving the Frontend Display

Previously, every auction displayed the countdown row.

Auction Ends In
Loading...

This has now been replaced with conditional output.

For manually closed auctions the visitor now sees:

Auction Status
Auction Ended

For active auctions the countdown remains unchanged.

Auction Ends In
12d 05h 18m

This makes the interface much clearer.

---

Preserving Winner Information

During implementation another issue was discovered.

While testing, the code responsible for retrieving the winning bid had accidentally been commented out.

Because of that:

• the Winner section disappeared,
• the plugin incorrectly displayed “No bids were placed.” even when several bids existed.

Restoring the following code resolved the problem:

$winning_bid = Flipnzee_Bid_Manager::get_winning_bid(
    $auction['id']
);

After restoring it:

• Winner information appeared correctly.
• Winning bid amount was displayed.
• Bid history continued to work.
• Closed auctions correctly showed their final results.

---

Final Behaviour

The auction system now behaves consistently.

Active Auction

• Live countdown displayed
• Bidding enabled
• Highest bidder shown
• Bid history available

Naturally Expired Auction

• Auction Ended shown
• Winner displayed
• Winning bid displayed
• No further bids accepted

Manually Closed Auction

• Auction Status → Auction Ended
• Winner displayed (if bids exist)
• Winning bid displayed
• Bid history preserved
• No misleading countdown shown

---

Lessons Learned

This implementation highlighted an important development principle.

A date alone should not always determine the state of an application. When a dedicated status field exists in the database, both the status and the timestamp should be considered before deciding how information is presented to users.

Handling these edge cases makes the auction system more reliable and provides a better experience for both buyers and sellers.

---

Download Source Code

Download the starting version of the plugin before the lesson:

Download the completed version after this lesson:

---

Conclusion

With this improvement, Flipnzee Auctions now correctly handles manually closed auctions while preserving auction history, winner information, and bid history. Visitors receive clear and accurate information regardless of whether an auction ended naturally or was closed early by an administrator, making the plugin more robust and professional.