Network monitor for WordPress. Connection overview for monitoring and controlling outgoing data traffic.
|Author:||pluginkollektiv (profile at wordpress.org)|
|WordPress version required:||3.8|
|WordPress version tested:||4.9.6|
|Added to WordPress repository:||12-02-2013|
|Total downloads:||29 150|
|Active installs:||1 000+|
Click to start download
- If you don’t know how to install a plugin for WordPress, here’s how.
Snitch creates a lot of database entries
Snitch is designed to log any outgoing connection in WordPress. If the database fills fast, you should look up the cause. Why does your WordPress and plugins communicate so often to the outside that the database table fills? Is this communication really necessary?
As a reminder: Snitch is designed to help you improve your WordPress performance by detecting and displaying connections as bottleneck. The task for the blog administrator is to eliminate the source of the cause (plugin, theme, etc.).
Snitch automatically ensures that there are not more than 200 entries are kept in the database. If it is nevertheless necessary to remove Snitch entries from the database manually, two smart database commands could help:
sql DELETE FROM wp_postmeta` WHERE `post_id` IN ( SELECT `ID` FROM `wp_posts` WHERE `post_type` = 'snitch' )
post_type = ‘snitch’
Are connections monitored in the front end?
Snitch catches any connection that leaves the blog via WordPress HTTP API (internal WordPress interface for data communication). This affects both the back-end and the front-end of a WordPress installation.
Why does Snitch list WordPress cronjobs?
WordPress calls internal Cronjobs via WordPress HTTP API – exactly this interface is monitored by Snitch and also records Cronjob accesses accordingly.
If cronjobs are listed too often, something possibly isn’t correct. Therefore, it is recommend to check the list of scheduled cronjob jobs.
The following code snippet in the WordPress configuration file
wp-config.php switches off the logging of the internal WordPress queries:
php define('SNITCH_IGNORE_INTERNAL_REQUESTS', true);
Why are Snitch entries indexed by Google?
Snitch stores its entries as WordPress Custom Post Types. Important step: By a WordPress attribute Snitch marks all log entries as private, therefore not public. So far, the ideology with private and inaccessible entries would work if there were not WordPress plugins that would carry all – including private – Custom Post Types into the world and communicate with search engines. With fatal consequences for the blogger.
And so it quickly happens that Google suddenly hits Snitch entries (as blog pages) which are not intended for public access. For example, because Snitch entries appear in the sitemap XML of the blog, as a sitemap XML plugin is of the opinion that it is also necessary to add private entries and to have them released for indexing. There is also no help to block via
robots.txt because the
robots.txt file does not prevent the indexing of the pages.
Automatic Shares go crazily
The fact that every new Snitch entry automatically sends a message to Facebook and/or Twitter, is clearly not due to Snitch. Rather, the cause is to be found in the inserted Auto-Tweet-Facebook-Plugin, which faulty triggers an automatic event at every – also non-public – WordPress Custom Post Type. And that’s wrong. The usage of such Plugins should be reconsidered.
A complete documentation is available in the GitHub repository Wiki.
- Updated README
- Improved user interface
- Support for WordPress 4.9
- Updated README
- Updated plugin authors
1.1.5 / 06.05.2015
- Support for WordPress 4.2
- Nice to have:
- Support for WordPress 4.1
- Feature: english translation for the readme file
- Feature: russian translation for plugin files
- Feature: status code “-1” for failing connections
- Feature: execution time as metric (thanks Matthias Kilian for the idea)
For the complete changelog, check out our GitHub repository.