Logging
Siteframe 5.x has two internal tables for logging. The first is the audit log; this is always functional and records any major changes to data. The purpose of this log is to track changes to the system; for example, if a large number of objects are deleted from the site, you can use this log to find what event or user initiated the deletion.
The second log is called the user log and records information about every page view on the site. Because of the overhead involved in writing to a database table for every page view, this log is disabled by default (though the table is still created, it will be emptry) and must be enabled by the site administrator to be functional.
Audit Log
The audit log is stored in the table <prefix>audit_log, where <prefix> is set in siteframe.ini (usually this is "bpt_" but can be changed). This table includes the following columns:
- log_id: an automatically-incremented primary key value
- log_time: the date/time stamp of the event
- log_user: the ID of the user performing the operation (if any)
- log_ip: the IP address of the client performing the operation
- log_module: the base name of the script
- log_message: an arbitrary message assigned by the software
Under the administrator's menu (http://site-name/admin/), you can view or clear the contents of the audit log.
User Log
The user log contains a record for every site page view. Because of the overhead involved in writing a record to a database table with every log view, user logging is disabled by default; to activate it, set user_log_enable=On in siteframe.ini. The user log table is named <prefix>user_log_raw, where <prefix> is the table prefix set in siteframe.ini. This is a "raw" table because it contains only raw data without indexing or other optimizations for query performance. The data is stored in a MyISAM table to further optimize SQL INSERT speed. Because of these enhancements, this table is not very suitable for direct querying, and no administrative functions are provided that directly query this table. This table, for the most part, replicates information found in a typical Apache web log, and the web log is recommended if you have it available, since there are a multitude of commercial and open-source tools for reporting on it. If, however, you don't mind the overhead associated with logging, or you don't have access to the Apache log files, you can use this mechanism for logging page views.
The columns in this table are:
- log_user_id: the user ID of the user viewing the page. This is only available if a registered user is logged in.
- log_b_cookie: the "beaumont" cookie. This is a special cookie that is set for every client and which never expires. If the client has cookies enabled, then this cookie provides a mechanism of uniquely identifying each visitor to your site (ok, if the user visits the site with multiple browsers, then each browser session will appear as a unique user. Close enough).
- log_created: The date and time the record was inserted.
- log_script: The name of the script that the user is viewing.
- log_server_protocol: The server protocol; this is usually either "HTTP/1.0" or "HTTP/1.1". It's rare to have anything else here.
- log_request_method: The HTTP mechanism used to retrieve the page: GET, POST, HEAD, etc.
- log_referer: The URI/URL of the referer to the current page. This can be used to track which sites are sending traffic to your site.
- log_user_agent: The user agent string that identifies the client.
- log_remote_addr: The IP address of the remote client.
- log_remote_host: The host name of the remote client; this is only available if the web server performs reverse DNS lookups on the IP address. Since these checks are very resource-intensive, it's rare to find a server that has this value available.
- log_request_uri: The complete URI of the request issued by the client.
Depending upon the number of page views your site receives, this log can grow quite large and should be monitored and cleaned occasionally.
By default, the user log table is created with a MySQL engine = MyISAM. If your MySQL installation has the optional ARCHIVE engine available (and this is quite common), then set db_archive=On in siteframe.ini will create the table using the ARCHIVE engine. The ARCHIVE engine is a high-performance method for adding large amounts of compressed, unindexed data to a table, which is exactly what happens with the user log. The ARCHIVE engine can only be used for INSERT and SELECT statements, so any further log processing must take place in a different table (this is a good idea anyway, for performance reasons).
About log_script and log_request_uri - these two fields help identify how people are accessing your site. log_script is the actual name of the PHP script that's currently executing during the request; for example, page.php or folder.php. log_request_uri is the actual URI sent by the client. For example, the client might request /p/some_page_name (log_request_uri); this would have log_script = page.php.
