Upgrading from WP fail2ban

This guide outlines the constants used in WP fail2ban, and what changes are necessary. Some constants have no replacement, and others are merged under on filter. Make careful note of these changes to continue smooth operation.

WP_FAIL2BAN_AUTH_LOG

This constant has been replaced by the wp_fail2ban_redux_openlog_facility filter. This filter is passed a second parameter with the action being taken.

WP_FAIL2BAN_SYSLOG_SHORT_TAG and WP_FAIL2BAN_HTTP_HOST

These two constants are used by WP fail2ban to create a tag for the system log (something like wordpress(example.com)). The short tag is now enforced, and two constants are merged into one filter, wp_fail2ban_redux_openlog_indent. This filter will receive a value like wp(example.com).

WP_FAIL2BAN_PROXIES

There is no replacement for this constant. You should fix this in nginx/Apache, or by resetting the $_SERVER['REMOTE_ADDR'] in your wp-config.php. See https://core.trac.wordpress.org/ticket/9235.

WP_FAIL2BAN_BLOCKED_USERS

This constant has been replaced by the wp_fail2ban_redux_blocked_users filter. This filter expects an array of usernames, rather than a regular expression pattern. Not only does this make it easier for a wider audience to use, it's also significantly faster than using a regular expression.

WP_FAIL2BAN_BLOCK_USER_ENUMERATION

This constant has been replace by the wp_fail2ban_redux_block_user_enumeration filter. Just like the constant it replaces, this filter expects a value of true or false, and defaults to false.

WP_FAIL2BAN_LOG_PINGBACKS

This constant has been replaced by the wp_fail2ban_redux_log_pingbacks filter. Just like the constant it replaces, this filter expects a value of true or false, and defaults to false.

There are also a number of other filters, with lots of documentation, available to make your wildest dreams come true.