An extensible tool for recording WordPress events to a system log.
Jeepers Peepers provides an extensible interface for recording WordPress events — user logins, file uploads, post deletions, etc. — to a standard system log.
The resulting audit trail can then be incorporated into powerful log-monitoring tools like OSSEC for pre-emptive protection and, in the unfortunate event of a hack, used as a vital reference in the post-mortem investigation.
The following events are automatically logged:
wp_die()
triggered;Each log entry records:
127.0.0.1
if automated);It will look something like this:
WordPressAudit 2017-05-24 16:35:45 [warning] yourdomain.com 68.256.55.123 "tiffany" "Deactivated plugin: look-see-security-scanner"
Please note: it is not safe to run WordPress atop a version of PHP that has reached its End of Life. Future releases of this plugin might, out of necessity, drop support for old, unmaintained versions of PHP. To ensure you continue to receive plugin updates, bug fixes, and new features, just make sure PHP is kept up-to-date. 🙂
Jeepers Peepers records CMS events such as post and plugin changes to a standard system log for security and audit purposes. Where possible, these entries include the public IP address and/or WordPress username of the individual responsible.
This plugin does not send any of this information to remote locations or third parties.
Please note: Jeepers Peepers DOES NOT integrate with any WordPress GDPR “Personal Data” features. (Selective erasure of audit logs would undermine the very purpose of this plugin! Haha.)
Nothing fancy! You can use the built-in installer on the Plugins page or extract and upload the jeepers-peepers
folder to your plugins directory via FTP.
To install this plugin as Must-Use, download, extract, and upload the jeepers-peepers
folder to your mu-plugins directory via FTP. Please note: MU Plugins are removed from the usual update-checking process, so you will need to handle future updates manually.
Sorry, no. This plugin can only be added to standard (single-site) WordPress installations.
/var/log/wordpress/{YOUR_SITE_DOMAIN}.log
, but this can be overridden by defining a constant in your wp-config.php
file (see the relevant FAQ section below).open_basedir
restrictions, this means whitelisting the path to the log file. If the hosting environment is chrooted or jailed, the log location will need to be within the same boundaries.By default, the log is written to /var/log/wordpress/{YOUR_SITE_DOMAIN}.log
. If this path exists and works for you, then no, logging will happen without any intervention.
To modify the default behavior, you will need to define a couple constants in your wp-config.php
file. See the relevant FAQ section below.
The following constants can be defined in your wp-config.php
file to override the default behaviors.
www.
subdomain./var/log/wordpress/{YOUR_SITE_DOMAIN}.log
When using a custom log location, please choose one that is outside the web root. You don’t want just anybody looking at it. 🙂
The plugin includes action callbacks you can trigger in your code to record a custom event.
// In order of severity... do_action('syslog_debug', $message, $internal); do_action('syslog_notice', $message, $internal); do_action('syslog_info', $message, $internal); do_action('syslog_warning', $message, $internal); do_action('syslog_error', $message, $internal); do_action('syslog_critical', $message, $internal);
All actions accept the following:
@
to mark it as “internal”. Default: FALSE