Holy Schema.org BreadcrumbList compliant JSON-LD breadcrumb trails Batman! Breadcrumb NavXT 5.7.0 introduces a new bcn_display_json_ld() function. Additionally, three bugs were fixed in this release.
On the bug fix front, the cause of PHP Errors when running the uninstaller from within WP CLI was fixed. Additionally, the cause of a PHP Warning in bcn_breadcrumb_trail::find_type() was resolved. Lastly, a typo in the settings page was fixed.
Looking Forward to 6.0.0
The next release of Breadcrumb NavXT will be 6.0.0. It is scheduled for mid-summer in celebration of 10 years of maintaining Breadcrumb NavXT (originally released as Breadcrumb Navigation XT). Be aware that 6.0.0 will drop the Max Title Length setting (already deprecated in favor of using CSS), along with the associated %ftitle% and %fhtitle% breadcrumb template tags.
If you would like to contribute to translating Breadcrumb NavXT, please visit the Breadcrumb NavXT Translation Project. A big thanks to all of the translators that have contributed to the translations in the past and continue to contribute.
As always, you can grab the latest version of Breadcrumb NavXT from the Breadcrumb NavXT page. If you experience any issues with this version of Breadcrumb NavXT, please leave a comment on this post detailing the issue.
Announcing the immediate availability of Breadcrumb NavXT WPML Extensions 1.3.0. This version fixes a compatibility issue with PHP7.1. Note this release temporarily breaks from semantic versioning due to a bug in 1.1.1 where the internal version was improperly set to 1.2.1.
Users with valid and activated license keys should receive an update notification within the WordPress dashboard and be able to use the update mechanism to update (just like with any plugin in the WordPress.org repository).
When dealing with login attacks against wp-login.php and xmlrpc.php, consider using an application firewall such as ModSecurity rather than a WordPress plugin. Why? ModSecurity runs before the request hits PHP. Thus, WordPress is not even run on these known to be bad requests.
Prior to enabling ModSecurity rules protecting wp-login.php and xmlrpc.php, these were the most popular files hit across all Weblogs.us WordPress installs. In December of 2016, wp-login.php was 23.48% of all hits, xmlrpc.php was 19.75%—A total of 43.23% all hits for what are really non-user facing pages. Similar behavior had been seen for the months prior as well.
After enabling ModSecurity rules punishing multiple bad login attempts for wp-login.php and xmlrpc.php, their total hits plummeted. In February, they accounted for only 3.78% of all hits. Did the robots go away? No, they were getting 403 errors, nearly 20% of hits resulted in a 403 error.
Implementing successive failed login attack mitigation rules is quite easy on Apache. Rather than repeat how to do this, see Mika’s post WordPress login protection using ModSecurity. Unfortunately, Nginx is a different story. While ModSecurity is available for Nginx, any rule that requires a locationmatch parameter will not work (locationmatch is Apache specific). Instead, a custom location rule for wp-login.php and xmlrpc.php can be generated with ModSecurity enabled and the extra rules applied. It isn’t terribly elegant, but appears to work.
Ease of implementation aside, the performance benefits from blocking malicious login traffic earlier makes using a ModSecurity based implementation worthwhile. At Weblog.us, we dramatically cut down on resource usage by implementing ModSecurity rules for blocking malicious wp-login.php and xmlrpc.php accesses.
After assembling my new home server, I ran into a bit of a heat issue. The Xeon-D SOC would get quite hot under load (80C), and was a little warmer than desired while idling (40C). Attempting to cool itself off, the motherboard kept the chassis fans spinning fast enough to be annoyingly loud. Since the heatsink installed on the motherboard was designed for 1U compatibility, and the case I’m using is 2U tall, it was not getting the airflow it was designed for.