Audit Trail Plugin
Audit Trail is a plugin to keep track of what is going on inside your blog. It does this by recording certain actions (such as who logged in and when) and storing this information in the form of a log. Not only that but it records the full contents of posts (and pages) and allows you to restore a post to a previous version at any time.
To summarize:
- Log of user actions inside your blog - useful for finding out who did what in a multi-user system
- Post/page revisions and restorations - every change to a post or page is recorded and can be instantly restored to a previous version
- Differences are shown graphically
- Extensible, allowing other plugins the ability to add and display items in the Audit Trail
- Ability to track registered user page visits
- Fully localized
Version History
- 1.0.10 - Only include prototype on AT pages
- 1.0.9 - WP 2.5 compatability
- 1.0.8 - Show log items according to blog timezone offset
- 1.0.7 - Fix favicon.ico logs, ignore certain users, track failed login attempts
- 1.0.6 - Fix warning, allow searching by username
Installation
The plugin is simple to install:
- Download audit-trail.zip
- Unzip
- Upload
audit-traildirectory to your/wp-content/pluginsdirectory - Go to the plugin management page and enable the plugin
You can find full details of installing a plugin on the plugin installation page.
NOTE: If you are upgrading from a pre 1.0 version please de-activate and then re-activate the plugin. This will upgrade your database tables (unfortunately any existing Audit Trail data will be lost).
Usage
Once the plugin is installed then your actions are already being recorded. You can view the Audit Trail log from the Manage/Audit Trail page.
Note that some entries in the log can be clicked and will expand to show more details.
Post & Page history
The Audit Trail plugin records the entire post everytime it is changed. This can then be used to provide a version history along with the capability of restoring a post to a previous version through this interface which appears on appropriate posts:
Usage is simple. Select the version you wish to view, click the 'view' button and examine the contents of the post. From here you choose to restore this version, delete it, or close the contents.
Restoring a post to a previous version will be recorded in the Audit Trail logs just like any other change. If you decide you don't like the restored version you can always restore back to another version.
NOTE: Installing the Audit Trail plugin in a blog with existing posts will mean that you have no revision history until a post has been changed at least twice (there is no log before the plugin, and there is little point allowing a restoration to the same version as is currently live)
Options
From the options page you can configure exactly what actions are audited. Any plugins that support Audit Trail will also display themself here.
Permissions
Users with the 'edit_plugins' or 'audit_trail' capability can view and administer the Audit Trail plugin. The 'audit_trail' capability can be added with the Role Manager plugin.
Support
Please direct all support questions to the Audit Trail support forum. Any support questions left on this page may not be answered.
Bugs & New Features
A full list of all bugs can be found in the Audit Trail issue tracker.
A full list of all requested features can be found in the Audit Trail feature tracker.
Comments (page 3 of 10)
May 22, 2007 7:30 am
thanks for the great plugin!!! I have a small problem: the search on top of the page does not seem to work. I am typing a user name, which is listed and got 'no results', same with the IP. Am I missing something?
Also, are you thinking to implement the ability to filter the results (like excluding the actions of the admin for example)
May 21, 2007 11:17 pm
Manne, I can't reproduce the problem you are seeing with external files. Audit Trail should not be able to log access to these files as they happen outside of WordPress. If they are appearing in Audit Trail then it means that something on your site (whether a plugin or theme) is forcing them to go through WordPress, and so be picked up by Audit Trail. Does the problem only occur on the xinha plugin?
I've added an option to reverse the order of edits.
May 21, 2007 12:55 pm
Thanks for your reply John. The order of the edits is no biggie but I still would have preferred it the other way.
If I turn off the "register page views" option then no post views will be audited I guess? All I want is to block file views that are not actually page views but rather files used by plugins (like javascript etc). Any way to do that?
May 21, 2007 12:35 am
Fabrice: Are you using Windows?
Manne: The order of posts is intentionally reversed. This makes your most recent edit appear first, and the older ones appearing further down the list. This seems to reflect what would be the most likely usage. As for the other issue, Audit Trail has an option to log 'registered page views'. When you are editing a page the preview area will cause a page view to be registered. If you don't want this then disable the page view option from the Audit Trail options.
Moogle: Thanks for the note. You are correct in both instances and the typos have been fixed in 1.0.2
May 17, 2007 7:18 am
Just upgraded from 0.3 to 1.0.1, and thought I'd share a few issues I had.
In summary, everything worked fine except that all IP's were being logged as 0.0.0.0. I had to edit models/audit.php, and change $data['REMOTE_ADDR'] to $_SERVER['REMOTE_ADDR']. Once this was done, I also had to modify the wp_audit_trail table - the column for IP was signed by default, and thus any address above 127.255.255.255 wouldn't get logged properly. Changed the IP column to unsigned, and now everything works as expected.
This was with WP2.2, Mysql 5.0.23 and PHP 5.2.0.
May 16, 2007 9:40 am
hello again, another question: the version numbers (when editing a post) seems to bee in reverse order, i.e. the oldest post is no longer number 1. Can I change this back to the more conventional way?
May 16, 2007 6:34 am
Thanks for a great plugin!
After updating Audit trail now monitors a lot of thinks that it didn't do before. For example everytime I edit och update a post, there is a page view registered for things like:
/wordpress/wp-content/plugins/xinha4wp/xinha_core/plugins/Abbreviation/lang/sv.js
/wordpress/wp-content/plugins/xinha4wp/xinha_core/plugins/SpellChecker/lang/sv.js
/wordpress/wp-content/plugins/xinha4wp/xinha_core/plugins/SuperClean/lang/sv.js
Other files used by different plugins are also monitored. How can I exclude these types of page loads from showing up in the trail?
May 15, 2007 3:14 am
Sorry to the delay, but I am not a specialist and I have a dsl connection only 2 days per week at work. I have opened the main audit-trail php file. You have addresses that use both /\ slashes. I have modified the slash so that only / are used and then the csv link now work. Supposed to explain all problems ?
> The plugin is already using the same box interface as trackbacks
Strange. There is no way to minimize or extend or move the box like the others... All other installed sidebox modules work fine so I do not know.
May 3, 2007 3:48 am
Fabrice, both those features work fine for me. Can you provide more details about your setup? Is the plugin inside the '/wp-content/plugins/audit-trail' directory? The plugin is already using the same box interface as trackbacks
Apr 30, 2007 11:52 pm
Really nice plugin.
Currently does not function.
Manage/Audit trail/
--> A "Csv" links appear above the Audit trail title. This link does not work.
Write/post/
--> The menu is ok. The "view" button does not work.
Only one comment. I would like that Audit tray use the same box interface as the trakbacks, custom fields... Is nicer and practical to move or closed the box to obtain a cleaner interface... There are a lot of modules that add their own block under the edit area and the rendering is progressively unaesthetic and unpractical.
Leave a comment