The csv2post_log table was added 4th March 2013 and replaces log files. The log table is a multi-purpose table with the different purposes sharing the same columns but for totally different reasons. The column named “type” must be used to group rows by the type value. The reason for the multi-purpose approach is to reduce the number of tables installed by CSV 2 POST and because each purpose in play could have its own table but would probably still require logging i.e. if an item such as a post was being flagged it would also be logged as having being flagged. Instead we can do a single INSERT query and in many cases use the data in a row as if it was one type or the other i.e. all flags could be treated as logs and listed on the interface along with rows with the “log” type.
Columns
Types include ‘log’ as a default which treats the table as the initial log table it was designed to be, ‘error’ for failures which will lead to the author being notified, ‘flag’ which creates admin actions to be performed or warns user, ‘schedule’ this will allow us to queue scheduled actions of specific types. The log table requires many columns so its purpose is easily adapted. Also the other uses it has would require logging anyway so by doing it in one table we reduce installation requirement and can perform better queries.
Holds unique numberic ID.
This holds a boolean value of 0 or 1. It tells us the overall outcome of a procedure or user action with zero being a negative outcome, possibly failure.
This holds a numeric value which can be converted to the current date and time.
This categorizes log entries. Categories include schedule, posts, data, project, forms, useractions, automation and we can add more if required. The category simply allows us to query logs for a specific area of the plugin (also referred to as systems) including users actions so we can trace someones steps.
The line number for a related code, usually set using __LINE__.
The involved function name usually set using __FUNCTION__.
If the log is related to a database query and the result does not hold sensitive data then we can dump the result in this table.
If the log is regarding a query or returned results we can dump the query in this column.
Capture errors from MySQL and store them here.
Wordpress has its own error reporting and we can store the output here.
Beta testers can submit screenshots on a form displayed inside error notices.
Beta testers can submit a comment for a notice displayed i.e. they could suggest the notice text changed or report a fault where incorect outcome has happened.
This is the plugin page name as seen in the plugins menu in WordPress dashboard. This is for debugging and this value is set automatically. We can use this to easily get to the location of a fault or user action.
Version of the plugin or extension. This can be used to ignore log entries for older versions especially when debugging.
This is recorded automatically especially when a user submits a form in a panel. This allows us to trace users steps.
The panel name cannot currently be established using panel ID as there is no array of panels. There may be eventually and this column will no longer be required. Until then we store panel name. This is used to trace users actions.
The ID of the tab screen. Storing this allows us to trace users steps.
Name of the tab where log comes from or where form was submitted from. Allowing us to trace users steps.
IP address if user, can help us with front-end logging.
This is the WordPress user ID. Can be important for logging admin user actions.
This column can be used for anything. A beta tester can have the entire source code of their screen dumped here allowing us to debug using the source code generated at the point where a fault occurred.
This is used when logging notices. If a user reports a specific notice we can use this to determine when they reported it and what they were doing before the notice was displayed. What they done after it was displayed and hopefully far more related data will be at hand. All in the effort of providing support and figuring out reported problems quickly.
Developer comment. We can add our own comment, could be a reminder about ongoing debugging or even a note regarding ongoing work that involves the notice in question.
This is mainly for errors however on a very busy website it will apply to other type’s of log entries such as flags. Priorities include “low”, “normal”, “high”, “critical”. Critical is intended for very rare use and is used to grab attention to something serious.
The action is a short text which indicates something that was done. The text is human readable rather than a sort of code as stored in other columns i.e. “Post Created”, “Post Updated”, “Post Creation Failed”, “Duplicate Post Detected”. The action will be a commonly displayed on history screens as general users can make more sense of log entries with it.
Some of the columns used for logging allow us to trace users steps but they are also part of our user experience program. The data allows us to build statistics regarding what screens are visited and what panels are used.