Important: Read the full article to fully understand the logic behind the module log.

First off, make sure that error logging is activated in the module configuration. For an instruction on activating the module log, refer to the Activate Realtime Register WHMCS module log Knowledge Base article.

Once activated, follow the instruction below.

As you can see on the image above, numerous log entries are made when performing domain transfers and registrations through WHMCS using the Realtime Register domain module.

The image above actually show a successful registration and a failed registration. The successful registration was requested form the admin side of WHMCS, the unsuccessful registration was requested from the client side of WHMCS. We'll discuss these two situations below in order to explain the basics in extracting the correct module log entries.

Successful Registration logs

Let's start with the successful registration which was entered from the admin side on behalf of the client. To understand the return codes in the below image, you can refer to the short instruction below:

  • 200 return message refers to a successful Get info call
  • 201 return message refers to successful Post call

In the image above there are three steps;

  • The Get info call which extracts the requirements for the TLD you're registering;
  • The Post call to create the contact in your account with Realtime Register;
  • The Post call to register the domain you're registering.

To extract the correct module log entries for the domain there are a few parameters you can use to check the logs. They're explained below and high lighted in the image below.

  • Refer to the time when an order was executed (highlighted in red)
  • All calls our module makes start with an Get info call requesting all the metadata (highlighted in blue)

Basically this means that all log entries from the first Get info call until the next Get info call are necessary for us to debug errors in our WHMCS module. In the case we would request you to provide the logging of all relevant actions for the domain testmodulellog3.nl, you should provide us with the logging as detailed in orange on the image below.

Difference in logging when ordering from client side or from admin side.

Now that you've got the basics, let's explain the difference in log entries when ordering from the Client side and Admin side in WHMCS.

  • One Get info call is made when ordering from the admin side (highlighted in blue)
  • Three Get info calls are made if you request the registration through the client side of WHMCS (highlighted in red)

The reason why ordering from the client side results in more Get info calls is simple; each step on the client side triggers a Get info call. In our testing environment, we have three steps on the client side to successfully complete an order.

When we order through the admin side in our testing environment on behalf of one of our clients, only one step before accepting the order is necessary. Thus this logically results in only one Get info call.

Unsuccessful registration logs

And now for the unsuccessful registration which was entered from the client side of WHCMS. To understand the return codes in the below image, you can refer to the short instruction below:

  • 200 return message refers to a successful Get info call
  • 201 return message refers to successful Post call
  • 400 return message refers to a bad request to the Realtime Register API

Take note: Keep in mind we always need the request and the response when debugging errors.

We'll go over the different calls one by one, starting with the Get info call(s).

  • As shown below, we can immediately see that this order was placed from the client side with three Get info calls which resulted in a 200 return message.
  • In the first Post call a domain contact is successfully created with Realtime Register through API, this logically results in a 201 return call stating the contact was created
  • The second Post call requests the registration with Realtime Register, since necessary details are missing for the registration a 400 bad request error is returned.

In order for us to give you more information and determine what caused the 400 bad request error, you will need to provide the full error log. This means all 5 calls with their request and response.

In order to export the error logging and provide us with the complete module log regarding your error, you can open and copy all module log entries separately or in one go.

Separately:

  • Click on the date and time of a particular log entry to open the detailed page where each log entry can be viewed separately
  • Copy the date and time line, the request and the response into a TXT document. Keep in mind that you supply al log entries regarding any action in the module log.

In one go:

  • Simply place your mouse cursor next to the date/time for last log entry regarding an error, and drag your mouse cursor to the bottom right of the first response regarding the error you wish to report.
  • Copy the text into a TXT file and provide it to us for debugging. Keep in mind to provide all log entries regarding any action in the module. 

Did this answer your question?