One of the biggest advantages of developing your own WordPress plugin is that you can continuously improve the user experience. In the previous lessons, the Flipnzee Auctions plugin was already creating transactions automatically after an auction ended and displaying them in a Transactions table. However, there was no way to inspect a transaction in detail.

In this lesson, a dedicated Transaction Details page was introduced. This page provides administrators with complete information about an individual auction transaction and lays the foundation for future features such as escrow management, payment verification, domain transfer tracking, and audit logs.

What We Built

Instead of only viewing a transaction inside a table, administrators can now click a View action to open a dedicated page displaying all transaction information.

Current information displayed includes:

• Transaction ID
• Auction ID
• Listing ID
• Seller ID
• Buyer ID
• Winning Bid
• Transaction Status
• Created Date
• Updated Date

This provides a much cleaner workflow compared to searching through database records manually.

Step 1 – Creating the Transaction Details Admin Page

A new admin class was created:

admin/class-admin-transaction-details.php

This class is responsible for rendering the Transaction Details screen inside the WordPress admin dashboard.

Initially, the page only displayed a placeholder message while the routing and menu registration were tested.

Step 2 – Registering the Admin Page

The new page was registered inside the plugin’s admin menu.

Unlike normal menu pages, this page is hidden from the sidebar because it is accessed directly from the Transactions table using a URL similar to:

admin.php?page=flipnzee-transaction-details&transaction_id=2

This keeps the admin menu clean while still allowing administrators to access detailed information.

Step 3 – Loading Transaction Data

Inside the render_page() method, the transaction ID is safely retrieved using:

$transaction_id = isset( $_GET['transaction_id'] )
	? absint( $_GET['transaction_id'] )
	: 0;

Using absint() ensures only valid numeric IDs are accepted.

The transaction is then retrieved from the custom database table using a prepared SQL query.

This protects the plugin against SQL injection while ensuring the correct transaction is loaded.

Step 4 – Handling Invalid Transactions

Good plugins never assume that data always exists.

If an invalid transaction ID is supplied, the plugin now displays an error message instead of generating PHP warnings or fatal errors.

Example:

Transaction not found.

This small validation greatly improves the robustness of the plugin.

Step 5 – Displaying Transaction Information

After confirming that the transaction exists, the placeholder content was replaced with a professional information table.

The page now displays:

This information is presented using a WordPress widefat striped table for a consistent admin experience.

Step 6 – Troubleshooting During Development

Like most real-world development sessions, implementation was not completely straightforward.

Several issues were encountered, including:

• PHP parse errors caused by misplaced braces.
• Accidental duplication of an if statement during copy-and-paste.
• Mixed HTML and PHP tags while replacing placeholder content.
• Leftover placeholder code causing unexpected output.
• Additional syntax validation before uploading the plugin.

Each issue was resolved by:

• Running PHP syntax checks:

php -l admin/class-admin-transaction-details.php

• Carefully reviewing opening and closing braces.
• Replacing only the affected code block instead of rewriting the entire file.
• Testing after every small change.

This incremental debugging approach made it much easier to locate and resolve problems.

Final Result

The Flipnzee Auctions plugin now includes a dedicated Transaction Details page.

Administrators can:

• Open a completed transaction
• View all important transaction information
• Verify buyer and seller IDs
• Review the winning bid
• Check the current transaction status
• See creation and update timestamps

The page is now ready for future enhancements without requiring any structural redesign.

Why This Matters

Although this page currently displays basic information, it establishes the foundation for a complete transaction management system.

Future lessons can build upon this page by adding:

• Buyer profile links
• Seller profile links
• Listing title instead of ID
• Auction title
• Escrow status
• Payment history
• Domain transfer progress
• Shipping information (for physical products)
• Internal administrator notes
• Activity timeline
• Email history
• Downloadable invoices

Because the framework is already in place, adding these features will be much easier.

Download Source Code

Download the starting version of the plugin before the lesson:

Download the completed version after this lesson:

Lessons Learned

During this implementation, several important development practices were reinforced:

• Build features incrementally rather than all at once.
• Validate user input before querying the database.
• Always use prepared SQL statements.
• Check for missing records gracefully.
• Run PHP syntax checks before uploading changes.
• Test every modification immediately to catch errors early.
• Use dedicated detail pages instead of overcrowding list tables.

Conclusion

Lesson 66 significantly improves the administrative experience of the Flipnzee Auctions plugin. Instead of viewing transactions only in a summary table, administrators can now inspect individual transactions on a dedicated page with all essential details.

More importantly, this page serves as the foundation for advanced transaction management features planned for future lessons, bringing the plugin another step closer to a production-ready auction platform.

After building the Transactions dashboard in the previous lesson, the next improvement was to make the transactions interactive. Instead of simply displaying transaction records, administrators should be able to manage the progress of each transaction as the auction moves through its post-sale lifecycle.

In this lesson, we implemented the foundation for transaction status management, allowing administrators to update transaction statuses securely from the WordPress admin area while recording every status change in the activity log.

Objective

The goal of this lesson was to transform the Transactions page from a read-only report into the beginning of a transaction management system.

Instead of every transaction remaining permanently in a Pending state, administrators can now move transactions through different stages.

Initial Workflow

Before this lesson, every completed auction produced a transaction like this:

Although transactions were stored correctly, there was no mechanism to update their progress.

Step 1 — Extend the Transaction Manager

The first task was adding a reusable method responsible for updating transaction status.

File modified:

includes/class-transaction-manager.php

Method added:

/**
 * Update a 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';

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

	if ( class_exists( 'Flipnzee_Activity_Log' ) ) {

		Flipnzee_Activity_Log::log(
			'transaction_status_updated',
			0,
			get_current_user_id(),
			sprintf(
				'Transaction #%d marked as %s.',
				$transaction_id,
				$status
			)
		);
	}

	return false !== $updated;
}

This method centralizes all transaction status updates in one location.

Step 2 — Register an Admin Action

To process status changes securely, a new WordPress admin action was registered.

File modified:

flipnzee-auctions.php

Code added:

add_action(
	'admin_post_flipnzee_update_transaction_status',
	array(
		'Flipnzee_Transaction_Manager',
		'handle_status_update',
	)
);

This allows WordPress to execute a custom handler whenever an administrator clicks a transaction action link.

Step 3 — Handle Status Updates Securely

Next, a dedicated handler method was implemented.

public static function handle_status_update() {

	if ( ! current_user_can( 'manage_options' ) ) {
		wp_die( 'Permission denied.' );
	}

	check_admin_referer(
		'flipnzee_update_transaction'
	);

	$transaction_id = isset( $_GET['transaction_id'] )
		? absint( $_GET['transaction_id'] )
		: 0;

	$status = isset( $_GET['status'] )
		? sanitize_text_field(
			wp_unslash( $_GET['status'] )
		)
		: '';

	if ( $transaction_id && $status ) {

		self::update_status(
			$transaction_id,
			$status
		);
	}

	wp_safe_redirect(
		admin_url(
			'admin.php?page=flipnzee-transactions'
		)
	);

	exit;
}

The handler performs several important tasks:

• verifies administrator permissions,
• validates the WordPress nonce,
• sanitizes user input,
• updates the transaction,
• redirects back to the Transactions page.

Step 4 — Add Status Action Links

The Transactions table was enhanced by creating a custom renderer for the Status column.

File modified:

admin/class-transactions-table.php

Method added:

public function column_status( $item ) {

	$status = esc_html( ucfirst( $item['status'] ) );

	$actions = array();

	if ( 'pending' === $item['status'] ) {

		$url = wp_nonce_url(
			admin_url(
				'admin-post.php?action=flipnzee_update_transaction_status'
				. '&transaction_id=' . $item['id']
				. '&status=paid'
			),
			'flipnzee_update_transaction'
		);

		$actions['paid'] =
			'<a href="' . esc_url( $url ) . '">Mark Paid</a>';

	} elseif ( 'paid' === $item['status'] ) {

		$url = wp_nonce_url(
			admin_url(
				'admin-post.php?action=flipnzee_update_transaction_status'
				. '&transaction_id=' . $item['id']
				. '&status=completed'
			),
			'flipnzee_update_transaction'
		);

		$actions['completed'] =
			'<a href="' . esc_url( $url ) . '">Mark Completed</a>';
	}

	return sprintf(
		'%1$s %2$s',
		$status,
		$this->row_actions( $actions )
	);
}

This introduces workflow-oriented actions directly into the Transactions page.

Step 5 — Testing the Workflow

After uploading the updated plugin, several scenarios were tested.

Successful observations included:

• Transaction status changed from Pending to Paid.
• The database updated correctly.
• The Activity Log recorded the status change.
• Administrators were redirected back to the Transactions page after the update.

This confirmed that the backend workflow was functioning as intended.

Challenges Encountered

During implementation, several issues arose that provided valuable learning opportunities.

Duplicate Methods

While extending the Transaction Manager, a duplicate update_status() method was accidentally created, resulting in a fatal PHP error. Removing the duplicate resolved the issue and reinforced the importance of keeping classes organized.

PHP Syntax Errors

While adding new methods, braces were temporarily misplaced, causing syntax errors. Incremental syntax checking with:

php -l includes/class-transaction-manager.php

helped identify and correct these mistakes before deployment.

Transactions Table Rendering

The custom Transactions table successfully displayed transaction data and action links. Status updates from Pending to Paid worked correctly, and the database reflected the changes. However, the “Mark Completed” action did not appear after a transaction entered the Paid state.

This did not affect the underlying transaction workflow or status updates, but highlighted a rendering issue within the current WP_List_Table implementation. Since the core transaction management functionality was already operational, further refinement of the table interface was deferred to a future lesson focused on polishing the admin experience.

Lessons Learned

This lesson demonstrated several important WordPress development practices:

• Separate business logic from user interface rendering.
• Protect administrative actions with nonces.
• Verify user capabilities before processing requests.
• Centralize database updates inside dedicated manager classes.
• Record important business events in an activity log.
• Test functionality incrementally after every major change.

Download Source Code

Download the starting version of the plugin before the lesson:

Download the completed version after this lesson:

Final Outcome

By the end of Lesson 65, the Flipnzee Auctions plugin evolved beyond simply storing transactions. Administrators can now begin managing the transaction lifecycle by updating statuses securely through the WordPress admin interface. Although some interface refinements remain for future lessons, the underlying architecture for transaction status management is now in place.

This implementation provides a solid foundation for the next phase of development, where transaction status changes will be connected to buyer and seller notifications, escrow integration, payment workflows, and ownership transfer processes, bringing the plugin closer to supporting real-world online auctions on Flipnzee.com.

After completing automatic transaction generation in Lesson 63, the next step was to allow administrators to view all completed auction transactions directly from the WordPress dashboard.

In this lesson, we created a dedicated Transactions admin page that displays every transaction stored in the plugin’s custom database table. This gives administrators a centralized place to monitor completed sales and lays the groundwork for future payment processing, invoices, commissions, refunds, and reporting.

What We Built

By the end of this lesson, the plugin includes:

• A new Transactions submenu
• A custom admin page
• A WP_List_Table based transactions table
• Automatic loading of transaction records
• Display of important transaction information
• Professional WordPress admin interface

Step 1 — Create the Transactions Table Class

Inside the admin folder create:

admin/class-admin-transactions.php

This file is responsible for:

• Loading the transactions page
• Creating the transactions table
• Displaying all stored transactions

Step 2 — Create the Transactions List Table

Inside the same file create a class extending WP_List_Table.

Example:

class Flipnzee_Transactions_Table extends WP_List_Table {

}

This gives us the familiar WordPress admin table interface.

Step 3 — Define Table Columns

Create the columns method.

public function get_columns() {

    return array(
        'id'          => 'ID',
        'auction_id'  => 'Auction',
        'listing_id'  => 'Listing',
        'seller_id'   => 'Seller',
        'buyer_id'    => 'Buyer',
        'winning_bid' => 'Winning Bid',
        'status'      => 'Status',
        'created_at'  => 'Created',
    );
}

These columns match the structure of the custom transactions database table.

Step 4 — Load Transactions From Database

Inside prepare_items() we queried the database.

global $wpdb;

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

$this->items = $wpdb->get_results(
    "SELECT * FROM {$table} ORDER BY id DESC",
    ARRAY_A
);

The newest transactions now appear first.

Step 5 — Configure Table Headers

Still inside prepare_items() we configured the table headers.

$this->_column_headers = array(
    $columns,
    array(),
    array(),
    'id',
);

This tells WordPress which columns should appear.

Step 6 — Display Column Values

Next we created the default column renderer.

public function column_default( $item, $column_name ) {

    return isset( $item[ $column_name ] )
        ? esc_html( $item[ $column_name ] )
        : '';
}

This automatically outputs the correct value for each column.

Step 7 — Register the Transactions Menu

Inside class-admin.php we added another submenu.

add_submenu_page(
    'flipnzee-auctions',
    'Transactions',
    'Transactions',
    'manage_options',
    'flipnzee-transactions',
    array( $this, 'transactions_page' )
);

The new menu now appears beneath Flipnzee Auctions.

Step 8 — Create the Page Callback

The callback loads and displays the table.

Example:

$table = new Flipnzee_Transactions_Table();

$table->prepare_items();

$table->display();

This is all that’s required for WordPress to render the table.

Step 9 — Load the New Admin File

Inside the main plugin file we loaded the new class.

require_once FLIPNZEE_AUCTION_PATH .
    'admin/class-admin-transactions.php';

Without this step the Transactions page would never load.

Step 10 — Test the Feature

After activating the updated plugin we verified everything worked correctly.

The Transactions page displayed:

• Transaction ID
• Auction ID
• Listing ID
• Seller
• Buyer
• Winning Bid
• Status
• Created Date

Every automatically generated transaction appeared successfully.

Result

The Flipnzee Auctions plugin now provides a dedicated Transactions dashboard for administrators.

When an auction ends and a winner is determined, the plugin now has the ability to:

• Store the transaction
• Display it inside WordPress
• Allow administrators to monitor completed sales

This transforms the plugin from simply tracking auctions into managing the entire auction lifecycle.

What We Learned

In this lesson we learned how to:

• Create a custom WordPress admin page
• Use WP_List_Table
• Display custom database records
• Load transaction history
• Register new admin submenu pages
• Build a professional backend interface

Challenges Faced

During implementation we encountered a few issues that are common when building WordPress admin tables:

• A misplaced method inside prepare_items() caused PHP syntax errors, which were resolved by moving get_table_classes() outside the method while keeping it inside the class.
• Initially, the Transactions menu did not appear because the new admin file had not been included in the main plugin file.
• After everything worked, an extra header row appeared at the bottom of the table. This is a cosmetic behavior of the simplified WP_List_Table implementation and does not affect functionality. It will be refined in a future lesson when we enhance sorting, pagination, and table styling.

Working through these issues reinforced the importance of careful class structure, proper file loading, and incremental testing during plugin development.

Download Source Code

Download the starting version of the plugin before the lesson:

Download the completed version after this lesson:

Final Outcome

By the end of Lesson 64, Flipnzee Auctions includes a fully functional Transactions management page that lists all automatically generated auction transactions. This provides administrators with immediate visibility into completed sales and establishes the foundation for future features such as payment integration, invoices, commissions, refunds, transaction status updates, and downloadable reports.