Logger module

Learn more about the Logger module.

This module is useful for logging events related to products, orders, and charges. You can enable or disable logging directly from the Settings page WooCommerce->Settings->Payment(tab).

All the logs are written to the uploads/digitalriver/logs directory. View the logs from the Admin Dashboard by going to WooCommerce->Status->Logs.

Specifications

This module logs data for all the modules.

The log method will be triggered for the following API calls:

  • SKU–Product Sync API calls

  • Order–status and transaction API calls

  • Customer–read and created into Digital River API calls

  • Checkout–created and updated API calls

  • Tax calculation–API calls

All logs are written to specific folder-wise log files if logging is enabled from gateway settings. Find the settings in WooCommerce by selecting Settings and clicking the Payment tab under the Digital River Gateway section. The transaction details are displayed in a meta box on the Order Edit page.

The relationship between the WooCommerce order and the Digital River order is maintained by storing the Digital River order ID as order post_meta managed by the order sync module.

The Logger module will only fetch the dr_order_id meta value and display the logs of that order. A new log file will be created for each object.

Naming conventions

  • Order related log files will be stored in uploads/digitalriver/logs/orders/[order_id].log.

  • SKU related logs will go to the uploads/digitalriver/logs/products/[product_id].log log file.

  • Customer related logs will go to the uploads/digitalriver/logs/customers/[customer_id].log log file.

  • Checkout related logs will go to the uploads/digitalriver/logs/checkouts/[checkout_id].log log file.

  • Payment Source related logs will go to the uploads/digitalriver/logs/sources/[source_id].log log file.

  • Any other logs will go to the uploads/digitalriver/logs/default.log file.

  • Error logs will go to the uploads/digitalriver/logs/errors.log file.

How to log an object

Trigger the action digitalriver.api_success with the following three parameters:

  • Object

  • Event name

  • Action type (CREATE / UPDATE / DELETE)

    Example: do_action( 'digitalriver.api_success', $object, $event, $action )

Currently, the following objects are supported as a stand-alone. The remaining objects are handled by the GenericHandler.

  • Checkout

  • Customer

  • Order

  • SKU

  • Source

  • Throwable

Customize how to log an object

To customize how to log an object:

  1. Create a new object extending the GenericHandler.

  2. Modify the methods get_log_line and get_relative_path as per your requirements.

  3. Add a new method to the dr_log_handler hook.

  4. The method must check whether the classname matches the object of interest and then return the newly created Handler object.

Log an error

Trigger the action digitalriver.api_error with the error as a parameter. Example: do_action( 'digitalriver.api_error', $exception )

Logger methods

Logger class

This class listens to events and logs them by using different Handlers for logging data types.

Method

Args, Returns, and Descriptions

name

Arg: -

Return: string

Description: Returns the name of the module

init

Arg: -

Return: void

Description: Initializes the module

log

Arg: Object $data, String $event, String $action

Return: void

Description: Takes in the object, the event name, and the type of action (CREATE / UPDATE / DELETE) and logs the data to the appropriate log file

error_log

Arg: Throwable $exception

Return: void

Description: Takes in the Exception and logs the error message to the errors.log file

get_handler

Arg: Object $object

Return: void

Description: Takes in an object and returns an appropriate handler for logging the object

Logger Container class

This class acts as a Dependency Injection container for providing dependencies to classes present in the Logger module.

Method

Args, Returns, and Descriptions

__construct

Arg:PimpleContainer

Return: void

Description: Accepts a Dependency Injection Container as an argument and assigns it to a container attribute

define_services

Arg:-

Return: void

Description: Defines all the classes present within the module

Logger View class

This class takes care of adding a new tab where the digitalriver logs can be displayed in the WooCommerce Status Menu tab.

Method

Args, Returns, and Descriptions

init

Arg:-

Return: void

Description: Initializes the module

add_tab

Arg: array $tabs

Return: array

Description: Adds a new tab called Digital River Logs under WooCommerce->Status menu

render

Arg: -

Return: void

Description: Renders the content to be displayed on the Digital River Logs tab

get_logger_files

Arg: String $path

Return: array

Description: Receive a directory path as an argument and return all the log files present in it

remove

Arg: String $handle

Return: bool

Description: Removes the file passed in as an argument

get_log_file_handle

Arg: String $filename

Return: string

Description: Receives the filename as an argument and returns the log filehandle

delete_log

Arg: -

Return: void

Description: Receives the filehandle from $_REQUEST and delete the log file

delete_all_log

Arg: -

Return: void

Description: Deletes all the log files

Metabox class

This class adds a metabox to the Order Edit page to display the order-related logs. The logs are fetched from the log file.

Method

Args, Returns, and Descriptions

init

Arg:-

Return: void

Description: Registers callback to display the metabox by making a call to the order_logs_metabox()

order_logs_metabox

Arg:-

Return: void

Description: Adds the metabox to the order edit screen and registers content callback as order_logs_metabox_content()

order_logs_metabox_content

Arg:-

Return: void

Description: Displays order-related logs inside a Textarea HTML element within the metabox

Interfaces

The Logger module defines the Handler and ErrorHandler interfaces.

Handler interface

This interface declares a single method that must be implemented by all the Handlers. A new Handler class must be created for every object type.

Method

Args, Returns, and Descriptions

set_data

Arg: Object $data String $event String $action

Return: void

Description: Implements the data to the object's attributes

get_log_line

Arg: -

Return: String

Description: Returns a string to be logged

get_relative_path

Arg: -

Return: String

Description: Returns the path to which data must be logged

log

Arg: Object $data, String $event, String $action

Return: void

Description: Parses the object and logs it

Error Handler interface

This interface declares a single method that must be implemented by Error Handlers.

Method

Args, Returns, and Descriptions

set_data

Arg: Throwable $exception

Return: void

Description: Sets the data to the object's attributes

get_log_line

Arg: -

Return: String

Description: Returns a string to be logged

get_relative_path

Arg: -

Return: String

Description: Returns the path to which data must be logged

log

Arg: Throwable $exception

Return: void

Description: Parses the error object and logs it

Handler classes

The following table describes the Handler classes:

Handler class

Description

OrderHandler

Stores order related logs to orders/{order_id}.log

ProductHandler

Stores product-related logs to products/{product_id}.log

CheckoutHandler

Stores checkout-related logs to checkouts/{checkout_id}.log

CustomerHandler

Stores customer-related logs to customers/{customer_id}.log

SourceHandler

Stores source related logs to sources/{source_id}.log

GenericHandler

Acts as a fallback and logs all the objects that are not handled by any other Handlers and writes them to the default.log file

ErrorHandler

Logs any errors that arise to the errors.log file

Last updated