Changelog — JPKCom Hide Login
Versionsverlauf des WordPress-Plugins JPKCom Hide Login.
Versionsverlauf von jpkcom-hide-login. Die Einträge stammen unverändert aus der README des Projekts. Eine ausführliche Anleitung mit Tipps findest du im Projekt-Guide.
1.2.9
- Changed: the update manifest generator now defaults a missing
Network:header to false instead of true, matching WordPress' own default. No change for this plugin, which declaresNetwork: trueexplicitly - CI: the lint and guard workflow now also runs on pushes to
main. It only covered pull requests, so a direct push with bypass rights skipped every check - Changed: comments, workflow step names and CI output across the repository are now English throughout, and the developer notes in
CLAUDE.mdwere translated and trimmed. No effect on the shipped plugin
1.2.8
- Changed:
Tested up toraised to WordPress 7.1 - Changed: the bundled updater's runtime floor now matches the plugin's own minimum. It bailed out below WordPress 6.8 while the plugin header has required 6.9 for several releases, so the check could never fire on a supported installation
- Docs: the remaining "WordPress 6.8" requirement statements now say 6.9, matching the plugin header
- CI: the release manifest's fallback values for
requiresandtestednow say 6.9 and 7.1. They only apply when the README metadata cannot be read, but a stale fallback would have published a minimum the plugin no longer supports
1.2.7
- Fixed: a block renewed itself for as long as anyone kept trying. A rejected attempt still fired
wp_login_failed, so the counter grew andblock_ip()was called again with a fresh full duration — the "try again in N minutes" message was untrue and a locked-out administrator hitting reload never got back in. Attempts from an already blocked IP are no longer counted - Added: the settings screen now warns when the detected client address is a loopback, private or link-local address and no trusted proxy is configured — the case where every visitor shares one address (five wrong passwords lock out everybody) or, if that address is whitelisted, where the protection is silently off altogether. The notice names the
JPKCOM_HIDE_LOGIN_TRUSTED_PROXIESline to add - Changed: the runtime check now requires WordPress 6.9, matching the
Requires at leastheader, which demanded 6.9 while the check still let 6.8 through. Both are driven byJPKCOM_HIDE_LOGIN_MIN_WP/JPKCOM_HIDE_LOGIN_MIN_PHPso they cannot drift apart again - Changed: cleared every WordPress Plugin Check finding except
plugin_updater_detected, which is inherent to a self-hosted updater — escaping at the point of output, prepared statements inline,wp_delete_file()instead ofunlink(), documented nonce and sanitisation exemptions on the request-path parsing that must stay byte-exact - Removed: the manual
load_plugin_textdomain()call. Since WordPress 6.7 the textdomain registry loads the plugin's own/languagesjust in time from theDomain Pathheader - Fixed: the shipped German
.l10n.phptranslations stored plural entries as PHP arrays instead of a NUL-joined string. WordPress' translation controller passes that value straight toexplode(), so on a German site the second failed login attempt died with a fatalTypeError— the login page returned HTTP 500 and no IP was ever blocked. Both files are regenerated withwp i18n make-php - Security:
/wp-signup.phpis now blocked on single sites too. Core answers it with a redirect towp_registration_url(), which this plugin rewrites to the custom slug — so one anonymous request returned the secret login slug in theLocationheader - Fixed: the
wp_login,wp_login_failed,authenticate,login_url,logout_url,lostpassword_url,logout_redirectandsite_urlcallbacks required strictly typed arguments. Third-party code that fires these with fewer arguments or anull— MainWP Child callsdo_action( 'wp_login', $user_login )with one argument — caused a fatalArgumentCountError/TypeError. All callbacks now accept the foreign shapes and normalise internally - Fixed:
wp jpkcom-hide-login get-slug/set-slugdid not exist; WP-CLI had registered them asget_slug/set_slug. Both are now declared with@subcommand, matching the documentation - Changed: verbose request tracing moved from
WP_DEBUGto its ownJPKCOM_HIDE_LOGIN_DEBUGconstant (default off). It used to write ~10 lines per request on anyWP_DEBUGsite, including the request URI and the full$_GETof every login attempt — password-reset keys included
1.2.6
- Changed: the plugin banners (
assets/banner-1544x500.avif,assets/banner-772x250.avif) are now a plain#3c4955surface with no lettering
1.2.5
- Security: the client IP is now taken from
REMOTE_ADDR;X-Forwarded-For,CF-Connecting-IPandX-Real-IPare only believed when the request arrives from a proxy declared viaJPKCOM_HIDE_LOGIN_TRUSTED_PROXIESor thejpkcom_hide_login_trusted_proxiesfilter. Previously a single spoofed header made the plugin see a whitelisted address, which disabled both the wp-login.php block and the brute-force protection, and allowed an attacker to get someone else's address blocked - Security: the wp-login.php / wp-signup.php block no longer relies on a substring test against the raw request URI.
//wp-login.phpand/wp-%6cogin.phpbypassed it; matching is now done against the script the server actually resolved, plus a normalised (decoded, slash-collapsed) path - Security: redirects only reveal the custom slug while the masked login page is being served or for an authenticated request — an anonymous probe no longer receives it in the
Locationheader - Fixed: the wp-admin block matched any path containing "wp-admin", so a post with a slug such as
/my-wp-admin-guide/returned 404 for every visitor. It now matches the first path segment - Fixed: CIDR whitelist entries never matched IPv6 addresses because
ip2long()returns false for them, while the admin UI happily accepted IPv6 ranges. Matching now works for both families viainet_pton(), and the prefix ceiling depends on the family (/128 vs /32) - Changed: IP keys are derived with a salted
hash_hmac( 'sha256', … , wp_salt( 'auth' ) )instead of a baremd5(), which was reversible for IPv4 in seconds. Existing attempt counters and blocks are invalidated once on upgrade - Added:
tests/test-security.php— regression tests for every issue above, each written to fail against the previous implementation. Run in CI on every pull request
1.2.4
- Security: update packages are now verified before installation — the verified file is handed to WordPress instead of being downloaded a second time, so the bytes that were checked are the bytes that get installed
- Security: a missing or unfetchable SHA-256 checksum now aborts the update instead of installing unverified code (previously it silently skipped verification)
- Security: pinned every GitHub Action to a full commit SHA and added Dependabot with a 7-day cooldown, so a moved tag can no longer change the release build
- Security: tightened which download the updater claims, so sibling plugins cannot match each other's package
- Fixed:
sprintf()calls in the updater bound named arguments to a variadic parameter, which raisesArgumentCountErroron PHP 8.3 - Fixed: the "View Details" modal could fail with a
TypeErrorwhen the manifest omittedrequires_plugins - Performance: a failed manifest fetch is now cached for an hour instead of being retried on every admin request
- Added: CI workflow on every pull request (PHP lint, named-argument check, YAML validation, action-pinning guard)
1.2.3 (2026-06-16)
- Raised the minimum WordPress version to 6.9 and "Tested up to" to WordPress 7.0
- Switched license metadata to the SPDX identifier
GPL-2.0-or-laterwith the HTTPS license URI
1.2.2 (2026-06-16)
- Security: updater prefers an exact match against the manifest
download_urlover the slug heuristic, so a tampered manifest can no longer bypass the checksum gate - Security: timing-safe checksum comparison (
hash_equals()) with anis_string()guard againsthash_file()failures - Security: manifest fetch via
wp_safe_remote_get()(SSRF defense-in-depth) - Fixed PHP warning and missing contributor names in the plugin detail popup (
display_namenow provided) - Fixed PHP warning/deprecation on
wp plugin listby completing theno_updatetransient entry (new_version,package,tested,requires_php)
1.2.1 (2026-03-13)
Fixed
- ZIP-Upload Fix - Manual ZIP uploads via WP-Admin no longer fail with "invalid URL" error during checksum verification
- Release ZIP Structure - GitHub Actions release now creates ZIP with top-level plugin folder, ensuring WordPress correctly recognizes updates
1.2.0 (2025-11-12)
Added
- IP Whitelist Management - Add trusted IPs that will never be blocked
- CIDR Range Support - Whitelist entire IP ranges (e.g.,
192.168.1.0/24) - Enhanced Admin Interface - Professional settings page with all features
- Blocked IP Viewer - See currently blocked IPs with expiration times
- Brute Force Protection - Automatic IP blocking after failed login attempts
- Customizable Protection Thresholds - Configure max attempts, attempt window, and block duration
- Login Attempt Counter - Shows remaining attempts on failed logins
- Current IP Display - See your current IP in admin settings
- One-Click Block Clearing - Clear all blocked IPs with a button
- Automatic Database Cleanup - Daily WordPress Cron job removes expired login attempt data
- WP-CLI Cleanup Command - Manual database cleanup via
wp jpkcom-hide-login cleanup - Full WP-CLI Support - Complete command-line management for all plugin features
…
1.0.0 (2024-11-30)
- Initial Release
- Basic login URL masking
- Simple IP blocking
- Multisite support
- Basic admin settings