Documentation

Functions

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

  • Destination
    Internet address that has been called from WordPress.
  • File
    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.
  • State
    Current state of the connection: authorized or blocked. Snitch entries can be grouped by state in the selection box above the list.
  • Code
    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.
  • Duration
    Execution duration in seconds. Practical value for locating performance bottlenecks.
  • Time
    Time of logging.
  • Data
    If an outgoing connection is provided with POST variables, Snitch buffers these values and displays them by clicking on the button.

Block connections

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.

Release connections

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.

Delete connections

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.

Installation

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

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:

snitch_cleanup_items

Controls the number of entries to be kept in the Snitch log. The daily clearing process considers this number when deleting old data.

Type: Integer

snitch_inspect_request_hosts

Hosts to block from the user blacklist. Values are read and matched when checking the outgoing connections.

Type: Array

snitch_inspect_request_files

Files to block from the user blacklist. The values are read in and checked when the outgoing connections are checked.

Type: Array

snitch_inspect_request_insert_post

Currently blocked connection with their properties (URL, status code, host, file, line, source, state=BLOCKED, POST data) which is stored as a Snitch entry.

Type: Array

snitch_log_response_insert_post

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.

Type: Array

Notes

  • 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.

FAQ

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:

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.

Changelog

The full english Changelog can be found here.