System logging facility for WordPress
Current version: 0.1
Want to keep track of the system events in your blog? Need a reliable logger for your development? WPsyslog is such a facility, and it will give you a new perspective on your WordPress installation.
Unix/Linux administrators love the availability of the syslog facility which gathers information from the system, allowing the admin to analyze the state of his system. With WPsyslog, WordPress now also has a system logger.
The default purpose is to track core events, such as users writing posts, changing profiles etc. It is also easy to use WPsyslog in other plugins — for the developer as debugging tool, and for communicating events to the end-users.
All data will be collected in the background, in a separate database table. You can view the logged data on the WPsyslog page. There is also is an advanced filter available to find exactly the pieces of interest.
The WPsyslog plugin is Free Software available under the GNU GPL. WPsyslog derived from a project with the German NGO “Menschen für Tierrechte” (Humans for Animal Rights), who generously agreed to making this work available to the public. It was extended by Zirona with tons of additional features to serve as versatile tool for all kinds of WordPress administrators.
Pages
How does it work?
WPsyslog uses the API hooks of WordPress to keep track of events. When an event is triggered, WPsyslog creates an entry in the WPsyslog database table. By default, WPsyslog keeps track of core events only, but it can also be used in plugins very easily (see download for more info). Used in plugins, it serves two purposes: (a) during development, it can be used to log debug messages. In production use, it can provide information to the end user or admin.
Installation
Download
- as .tar.bz2 archive (27.5 kB)
- as .tar.gz archive (30.1 kB)
- as .7z archive (26.0 kB)
- as .zip archive (40.2 kB)
Please consider coming back for a donation. You’ll support our efforts and receive a backlink.
Have problems unpacking archives? Try the latest 7zip.
- Download it.
- Unpack it and upload it into your WordPress plugins folder.
- Activate the plugin in your admin panel.
- Go to
WPsyslog » WPsyslog optionsand tune your log options.
Features:
- Logs time, user (or IP) who triggered the event, severity level, module (core or a plugin),
- Intelligent output with frontend for complex database queries (no more
grep
), - multilanguage support, English and German already included,
- Core events to trigger can be selected separately,
- Special roles for additional users to read logs and set options (in cooperation with role-manager)
Screenshots
Note: Click on the images below to obtain a full-size view.
Screenshot 1: The log data table with colorized output.
Screenshot 2: The search panel.
Screenshot 3: Upper part of the settings screen.
Translations
This plugin has full multilinguality support. Included/available languages are:
- English (default)
- German (de_DE, included)
- Italian (it_IT, download as po and mo), kindly translated by Paolo Tresso
Translators for other languages are very welcome! Please contact us, if you want to do a translation.
Credits
This plugin has been developed with the German NGO “Menschen für Tierrechte” (Humans for Animal Rights), who generously agreed to making this work available to the public.
What else?
If you like this plugin and have an idea to improve it, please leave a comment below. If you have tested it successfully, please do also leave a comment (maybe with some specs about your environment). If you hate it for some reason, you shouldn’t keep that secret, too.
That’s it! Have a lot of fun with the WPsyslog plugin!
In case you need individual, advanced support: Zirona also provides professional support for this software and its integration on your website (as well as WordPress support in general). Please don’t hesitate to contact us and ask about our services.
Anne on July 31, 2007 at 16:07 #
I just downloaded the .zip archive; the .7z archive doesn’t work (I get a 403 error).
Alex Günsche on July 31, 2007 at 16:31 #
Thanks for the hint. For some reason, my 7z packer sets permissions to 0600, and I forgot to change it in the upload. Fixed now.
Max on August 10, 2007 at 16:44 #
Thanks for the great plugin.
Is it possible to log when wordpress ping?
Alex Günsche on August 11, 2007 at 14:40 #
Max, it might be possible. I’ll try to find out if there are usable event triggers for it and maybe implement it in the next version.
Paveo on September 15, 2007 at 17:45 #
This is a really good tool.
happy on September 30, 2007 at 12:26 #
WordPress database error: [Table ‘happy_wrdp1.wp_wpsyslog’ doesn’t exist]
SELECT * FROM wp_wpsyslog WHERE ( ( ( (`time` > ‘2007-09-30 00:00:00′ AND `time`
Alex Günsche on October 1, 2007 at 10:09 #
Did you delete the table? Can you see it in your WP database?
happy on October 3, 2007 at 19:54 #
Yes, I can go and delete table inside WP database… which one?
Marc on November 7, 2007 at 00:46 #
Thanks, this is really a good working plugin for syslogs, i have it now in production.
Rob on December 10, 2007 at 10:22 #
Works great, really the best logtool i know for WP!
Peter on December 18, 2007 at 20:09 #
Just downloaded the Zip file twice, it doesn’t work. When I try to unzip the system says that the downloaded folder is damaged.
Kenneth on December 19, 2007 at 20:21 #
Thanks, this sounds promising, but unfortunately I can’t see any activity!
Entering the WPsyslog tab I only see the Show filter options button, the header of the table and one line saying “No results.”
Checking directly in the database, shows all the expected entries in the wp_wpsyslog table.
I tried switching back to the default theme with the same result.
I’m using WP 2.3.1 in a hosted environment running the following os and software:
Apache/1.3.33 (Debian GNU/Linux) mod_ssl/2.8.22 OpenSSL/0.9.7e mod_python/2.7.10 Python/2.3.4 PHP/4.4.7-0.dotdeb.0 with Suhosin-Patch mod_perl/1.29
Please advice how I can debug this for more information.
TIA
Kenneth
Alex Günsche on December 19, 2007 at 21:05 #
Hi Kenneth,
this seems to be the very issue I realized on a blog of mine. I don’t know what’s causing this, but it seems the default date range is being miscalculated. If you enter a valid range in the filter options, you should see the logs. I will look deeper into this when I’ll work on the next version (which won’t be too soon, as there are other plugins more urgently to be released), but if you have a clue what the bug is and how to fix it, I’d be very happy to hear about it.
Kenneth on December 20, 2007 at 13:12 #
Thanks for the workaround Alex!
My php-skills are rather rusty for now, so I doubt I’ll be able to locate the bug, but I’ll let you know if something strikes me here during the hollidays…;-)
But, for a skilled php-developer it should be an easy fix - so let that be my christmas wish for now…
Regards
Kenneth
admc on November 2, 2008 at 13:01 #
Hello,
the problem mentioned above is in the wpsyslog_admin_data.php, near the line 70, when the default values for $timeStart and $timeEnd are calculated.
Your code supposes that when no data is submitted via POST, $timeStart and $timeEnd are taking values out of the interval of the cca. 30-40 years around. However, when strtotime() gets the empty value, it considers it as the current date, and not 0-date, which would be the Unix Epoch.
A possible solution that was used by me: after converting $timeStart and $timeEnd using strotime(), if I notice that they are equal (i.e. the time interval is empty), I set the both values to 0. So the next condition will recognise them as invalid values, and enter the default ones instead.
Best Regards,
Adam