Andy Whalen

Creates a log file for network/multisite super admin actions.
The following actions are logged for Super Admin users. WordPress action names are listed in parenthesis:
<ul>
<li>change network settings (update_site_option)</li>
<li>grant super admin privileges (granted_super_admin)</li>
<li>revoke super admin privileges (revoked_super_admin)</li>
<li>upgrade blog (wpmu_upgrade_site)</li>
<li>add blog (wpmu_new_blog)</li>
<li>set blog archived (archive_blog/unarchive_blog)</li>
<li>set blog deleted (make_delete_blog/make_undelete_blog)</li>
<li>set blog mature (mature_blog/unmature_blog)</li>
<li>set blog spam (make_spam_blog/make_ham_blog)</li>
<li>delete blog (delete_blog)</li>
<li>delete user (wpmu_delete_user)</li>
<li>delete user (deleted_user)</li>
<li>change other user’s settings (edit_user_profile_update) [NOTE: doesn’t show diff]</li>
<li>change blog setting (updated_option) [NOTE: may occasionally log annoyingly large diffs]</li>
</ul>
The following actions are logged for ANY user:
<ul>
<li>login (wp_login)</li>
<li>logout (wp_logout)</li>
<li>new user (user_register)</li>
</ul>
Some actions that change data will show what the value was before and after.
Below is an example of a log entry when the user ‘smith’ has changed the Network site name from “WP Local Network” to “WP Local Networks”:
<pre><code>[Tue, 03 Sep 2013 13:45:49 +0000] [smith:1] [update_site_option] [1] [site_name] [(WP Local Network)->(WP Local Networks)] [127.0.0.1] </code></pre>
Each line in the log file will roughly follow the below example. Individual actions may log slightly different information, but the DATETIME, USERNAME, USER_ID, ACTION, and IP_ADDRESS sections should always be populated.
<pre><code>[DATETIME] [USERNAME:USER_ID] [ACTION] [AFFECTED_OBJECT_ID] [DATA_TITLE_OR_KEY] [(VALUE_BEFORE)->(VALUE_AFTER)] [IP_ADDRESS] </code></pre>

Observer

Creates a log file for network/multisite super admin actions.

psicosi448

End users can benefit from wp2syslog:
<ul>
<li>Log entries for core events help to keep track of the daily business, especially on multiuser blogs.</li>
<li>Log entries for core events can raise awareness for threats and problems, for example abuse attempts.</li>
<li>Log entries triggered by plugins allow the user to comprehend the functionality of the plugin.</li>
</ul>
Developers can benefit in two ways from wp2syslog:
<ul>
<li>At each point of the code, a log entry can be triggered. No need to print to the browser, just let wp2syslog put it in the database, and you can have a look later.</li>
<li>You can develop your plugins with support for wp2syslog. This will give your users the chance to better understand what your plugin is doing (see doc/specs.html).</li>
</ul>
<h3>Credits</h3>
This plugin is forked from first 0.2 version of http://www.ossec.net/wpsyslog2/ 
already forked from the wpsyslog plugin by Alex Guensche ( http://www.zirona.com/software/donate ).
The firts version of this plugin was developed during a project with the German “Menschen für Tierrechte” (Humans for Animal Rights). 
It is an organisation of activists who advocate animal rights and fight against abuse of animals. They generously decided to donate 
this work to the general public by letting Zirona put it under the GNU GPL and allowing us to promote and distribute it.
Please support the work of Humans for Animal Rights, e.g. by placing a link to <a href="http://www.tierrechte.de/" title="www.tierrechte.de" rel="nofollow ugc">Humans for Animal Rights</a> and 
spreading the word. Not (only) because of this plugin, but generally for a better treatment of the beings on this planet.

wp2syslog

wp2syslog -- Global logging facility for WordPress (WPsyslog revisited)

Observer vs wp2syslog