Dev4Press No Script

How Activity Logging Works

Plugin logging core doesn’t log any events on its own. Plugin has multiple components that are loaded and active, and each component hooks into various WordPress actions and filters to detect changes or activities to log. When monitored activity happens, component will gather data for every event, prepare the data for logging and pass it to the coreActivity logging core to log into database.

Data for Each Entry

For each active event supported by the coreActivity plugin, plugin captures required and optional data, dependent on the event. Every event happens during the website request that can comes from web browser, from the CLI, REST API or AJAX.

Required Data

Minimal set of data required to log the event includes:

  • Blog ID: if the website is multisite network, blog ID will be included, otherwise, this value will be always 1.
  • Event ID: this identifies the logged event. This ID links to the Events database table where each event has been registered.
  • User ID: if the event is logged during page session where the user is logged in, that user ID will be stored, otherwise, this value will be 0.
  • Logged: this is GMT datetime when the event has happened.
  • IP: if the event comes from the web based request, that request IP will be logged. Plugin will attempt to determine the real request IP based on various factors (use of proxies).
  • Context: all request can come as normal web requests (content is not logged), or via REST API, AJAX, CRON Job or CLI.
  • Method: each HTTP request has a request method set, and that is always logged. This can be GET, POST, DELETE, PUT…
  • Protocol: each HTTP request has HTTP protocol set. This value is not of a big value, especially if the website is hidden behind reverse proxy, but depending on the server setup, this can be useful value.
  • Request: full request URL with the website base URL removed to save some space.
  • Object Type: each event can be linked to a specific object in WordPress: post, comment, term, user… or to an object that is not identified by ID: plugin, theme, notification…
  • Object ID: if the object type has numerical ID, that ID is stored in the Object ID column.
  • Object Name: if the object type has non-numerical ID, that ID is stored in the Object Name column.
  • Country Code: this is optional value, stored only if the GEO location is enabled.

All these are stored in the main Log database table as a single record for each logged event entry.

Optional Data

Depending on the plugin settings, there are other data store by the plugin. All these are stored as metadata in the Meta table, and linked to the main entry in the Logs table.

  • User Agent: each web based request comes with the User Agent value used to identify the software making the request. This is used to identify source device. User Agent value can be faked by the software making the request.
  • Referrer: if the request comes from some other page, that can be included as a referrer value for the request.
  • Device Detection: plugin can detect the request source software/device from the User Agent, and this can be stored to speed up the log review later.
  • GEO Location: this can be detailed information about GEO located information from the request IP.

Event Specific Meta Data

Each event usually has one or more event specific data that will be stored as metadata in the Meta table.

Storing data in Database

Entry record that goes into Log table, needs all required data. For some of the data, empty or default values can be stored. And, if some of the required data is not provided by the event handler, plugin will populate this data automatically based on the request processing.

Optional and event specific data is all stored in Meta table. If the data is simple (scalar) value, it will be stored as plain text. More complex data (arrays and object) will be serialized and stored. If the optional entry has empty value, it will not be stored!

Rate this article

You are not allowed to rate this post.

Leave a Comment