Any connection to the “outside” made via the WordPress interface are collected by Snitch in the form of a table which is accessible to WordPress administrators. The plugin splits the properties of logged connections into sortable columns.
Columns with connection data
Internet address that has been called from WordPress.
Script file that has initiated the actual connection setup. Snitch places the affected line number after the double point to be able to start the search for the reference. Bonus: Snitch tries to assign the affected script file to a theme or plugin.
Current state of the connection: authorized or blocked. Snitch entries can be grouped by state in the selection box above the list.
Status code which was received as a response when the connection was established. The status code 200 means a successful connection. Incorrect connection attempts are signaled by Snitch using the status code -1.
Execution duration in seconds. Practical value for locating performance bottlenecks.
Time of logging.
If an outgoing connection is provided with POST variables, Snitch buffers these values and displays them by clicking on the button.
The Destination and File columns have a mouseover link to block future connections by pattern:
- Block this host Blocks all connections to selected domain
- Block this file Blocks all connections from the file
After clicking on one of the links, Snitch moves the domain or file into the internal blacklist and applies the updated rule to the next communication. By the way, Snitch marks all connections within the list in orange if they match the rules of the blacklist. Blocked connections are assigned a slightly red background.
Already rejected or connections that are only marked for blocking in orange-colored columns let their action invert, ie remove the rule from the blacklist again. The execution of this action also takes place via fadeable links. After the click, the column marker changes to green and means: Connection patterns are no longer recorded by the rules.
Snitch entries can be safely deleted via the plugin button Empty Protocol. This process has no effect on the functionality of the plugin: Created Snitch rules to blocked content (domains or files) remain and are active.
Snitch has an automatic cleanup process running. One a day old connection data will be deleted in order to keep your database clean. The number of the items spared by this process can be customized using the plugin filter snitch_cleanup_items.
Snitch can be downloaded from the official WordPress-Plugin-Page: Download
Alternatively, the installation can be done directly in WordPress in the “Plugins” administration area → “Adding plugins”: Search for Snitch, select, install.
After successfully activating the plugin, the connection overview is accessible via the side menu in the administration area. From this point on Snitch logs outgoing connections within WordPress and lists requests in the connection overview.
Snitch has no options.
Hooks allow the user to extend the functionality of a WordPress plugin. The following hooks are deposited in Snitch and can be addressed or controlled via code:
Controls the number of entries to be kept in the Snitch log. The daily clearing process considers this number when deleting old data.
Hosts to block from the user blacklist. Values are read and matched when checking the outgoing connections.
Files to block from the user blacklist. The values are read in and checked when the outgoing connections are checked.
Currently blocked connection with their properties (URL, status code, host, file, line, source, state=BLOCKED, POST data) which is stored as a Snitch entry.
Current assigned connection with their properties (URL, status code, execution time, host, file, line, source, status=AUTHORIZED, POST data) which is stored as a Snitch entry.
- Snitch only monitors the traffic that is handled through WordPress HTTP API. Other connection attempts are ignored.
- Blocking individual domains and/or files in Snitch can affect the functionality of the affected WordPress applications.
- Only blog administrators have permission to access the Snitch connection summary.
- WordPress constants WP_HTTP_BLOCK_EXTERNAL and WP_ACCESSIBLE_HOSTS can be used to completely deactivate or to release on a point-by-point basis Data traffic from WordPress.
The online manual didn’t answer all the questions? Perhaps the following answers to the frequently asked questions could help.
Snitch creates a lot of database entries
Snitch is designed to log any outgoing connection in WordPress. If the database fills fast, you should ask yourself as a blog operator: Why actually? Why does my WordPress and plugins communicate so often to the outside that the database table fills? Does everything go the right way and must this communication really be?
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:
DELETE FROM `wp_postmeta` WHERE `post_id` IN ( SELECT `ID` FROM `wp_posts` WHERE `post_type` = 'snitch' ) DELETE FROM `wp_posts` WHERE `post_type` = 'snitch'
Are connections monitored in the front end?
Snitch writes down 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:
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.
The fact that professional and passionate (further) development of a plugin is associated with (time) effort is needless to say and should be clear to every user.
Would you like to promote the development of Snitch?
The full english Changelog can be found here.