I'm currently working on a major site that needs some kind of a log-system for keeping track of things happening inside a custom post type.
I've customised a custom post type to allow visitors to submit their application (a new post) without being logged in. The applications received wary from 10 to 50 a day.
Administrator users can then view each application received from each visitor and from there make necessary changes to meet some requirements we have.
And this is where I want to add some logging / tracking to save when an application is updates, or some other changes has been done - like adding text to a custom meta-box inside the application.
If something happens to an application, it would be nice to be able to view a history of that application to see which user and what was done.
This doesn't have to be complex to start with, but I need to be able to extend what is logged in the future.
The question is:
What is the best way to go about this? (without using any activity plugin).
Would creating a custom post type for logging be too much?
John Cotton answers:
<blockquote>Would creating a custom post type for logging be too much?</blockquote>
You could create a custom table in the database with timestamp, user id, post id, activity fields and write to that on each update. You could make the activity field a serialized array if you wanted to store variable data for each different type of change, but maybe a simple string will be enough for your audit needs.
Thanks for your recommendation John.
Just to make sure I understand you correctly, do you recommend creating a custom table entry for each application (post) added, or for each application change/update?
Example: if application1 gets updated 10 times by different users, that would either be 10 row entries, or 1 row entry if we could store each update inside 1 row... but maybe that makes it too complicated for further use.
Lets say I want do display each activity entry for each application, and even display parts of that entry inside the application it belongs to (so other admin users can view what was done, by who).
Although I want to keep the log small at the beginning, I want to be able add more activity data as time goes by.
Example of activity data to start with might be:
- Application1 gets edited by user1
-- user1 adds note to application (custom metabox)
-- user1 updates the post
Not sure if that changes anything, but would be interested to know your thoughts around this.
John Cotton comments:
<blockquote>Although I want to keep the log small at the beginning, I want to be able add more activity data as time goes by.</blockquote>
What you store has to depend on what you want to report. So if you want to know precisely what was changed, then - clearly - you need to store that.
If you are only interested in post content, the enabling your custom post type to support revisions would be a good option (and upping the number of revisions stored to keep a longer history).
However, it appears that you are really interested in changes in meta data which won't get tracked by the built-in revisions functionality.
<blockquote>do you recommend creating a custom table entry for each application (post) added, or for each application change/update?</blockquote>
The latter. That way, you can use the timestamp to track changes over a period.
From the sound of it, you might even want to store multiple entries for each save so that different meta fields could be logged.
But you need to be absolutely clear about why you are storing things, as it could get quite complicated and be a performance hit on your app.
For example, if you only want to log changes, you are going to have to test each update in the postback against existing data to see if it really has been updated - either that or have some client side code that monitors changes and sets a flag.