SignInForge

No. The native WordPress screens stay in place until you publish an experience and choose it for the login screens.

Go to SignInForge > Templates, create an experience from a template, adjust the logo, colors and text in the block editor, publish it, then select it for the login screen in SignInForge > Settings. The lost password, password reset and registration screens use the same experience unless you choose another one for them. You can also click "Use on login screens" in the SignInForge > Experiences list, or tick the screens in the "Screens using this design" panel of the block editor.

You do not need a design per screen: one experience covers them all, as its Authentication Form block set to "Automatic" (the default) shows the form of the screen being displayed. While you design, choose the screen in the toolbar of the form block ("Screen: Log in") or in the "Screen preview" panel of the block editor, or in the "Preview screen" control of the Elementor widget: the form then shows the lost password, password reset or registration form, or a message such as "Check your email" or an expired reset link, so you can style it. "Preview on this screen" opens the whole page. The template previews of SignInForge > Templates offer the same choice, and SignInForge > Settings links each screen to the preview of its design. Your visitors always see the form of the screen they open.

A template creates a draft experience that you are free to change; the template itself never changes. To copy a design to another site, export it: "Export" under an experience in the SignInForge > Experiences list, the "Export" bulk action for several experiences (one file), the "Template" panel of the block editor (where you can also name and describe the template), or "Export as template" in the page settings of the Elementor editor. Then import the file in SignInForge > Templates on the other site. Imported designs are sanitized and always created as drafts, and designs containing shortcodes or embeds are refused, because they would run on the login page for every visitor. Images are not copied: the template refers to them by their URL on the original site.

Yes. An exported Elementor design imports as an Elementor draft when Elementor is active on the other site, and as its block editor version otherwise (you are told so). For security, Elementor templates may only use layout elements, the basic core widgets (heading, text, image, button, icon, divider, spacer…) and the SignInForge form: the HTML and Shortcode widgets, embeds, WordPress widgets, dynamic tags, custom CSS and widgets of other plugins are refused or removed, because they could run code or load remote content on the login page.

Yes. Every bundled template and every new design has a palette: a few named colors (background, surface, text, accent…) with a light and a dark value each. Visitors see the version that matches their system setting, unless you choose "Always light" or "Always dark" in the "Colors" panel of the block editor, where you also edit the palette and switch the editor between both versions. The template previews have a Light / Dark toggle. Only the colors picked from the palette switch: a color typed by hand stays the same in both versions. A design without palette (an imported template without one, for example) keeps fixed colors until you add a palette to it.

Their page background, text and the SignInForge form widget follow the palette of the experience. Elementor sections and widgets keep the colors set in Elementor, in both versions: leave their background and text colors empty to let the palette show through, or force one version in the "Colors" section of the page settings. The "Preview colors" setting of the form widget shows a version in the Elementor editor.

SignInForge shows the native WordPress screen instead of a design that cannot be displayed: a design without the Authentication Form block, a design that is not published, or a rendering error. Your visitors can always log in.

Open the safe mode URL shown in SignInForge > Settings, or add define( 'SIGNINFORGE_SAFE_MODE', true ); to wp-config.php. Both show the native WordPress login screen. The safe mode URL only works for the request that carries its secret key; you can regenerate it in the settings.

Yes, when Elementor is active. Open SignInForge > Experiences, create or edit an experience and click "Edit with Elementor". Add the "SignInForge Auth Form" widget (SignInForge category) where the form must appear, style it from the widget's Style tab, then publish and choose the experience in SignInForge > Settings. Without the widget, the native screen is shown.

Yes. Caching plugins and CDNs normally never cache wp-login.php, where SignInForge screens are served. When you place the Authentication Form block on another page, SignInForge tells page caching plugins not to cache it (DONOTCACHEPAGE) and sends no-cache headers, because the form carries a security token. If your CDN caches pages whatever the headers say, exclude the pages that contain the form.

Most plugins that hook the login form or authentication (for example two-factor authentication, captcha, membership or WooCommerce plugins) keep working, because SignInForge uses the WordPress login functions and fires the core form and authentication hooks. Plugins that rely on the screen hooks tied to the wp-login.php markup (login_head, login_footer, login_message, login_form_{action}, lost_password) will not see those hooks fire on SignInForge screens. See "Built on WordPress authentication" in the description.

By the IP address the web server sees (REMOTE_ADDR), combined with the account being logged into (its username and email address count as one) or, for a login that matches no account, the text that was typed. Logins and IP addresses are stored as keyed hashes, never in clear text. A successful login clears the failures of that IP address and login. If you are locked out, wait for the lockout to end (15 minutes by default) or log in from another network; safe mode does not lift rate limiting, which is a security feature. If you already use another login limiter, you can turn this one off in SignInForge > Settings > Security.

Behind a reverse proxy, every visitor may reach WordPress with the proxy's IP address, so they would share one rate limit. SignInForge never trusts forwarding headers such as X-Forwarded-For on its own, because anyone can forge them. If you know which header your trusted proxy sets, return the visitor IP with the signinforge/security/client_ip filter, for example in a must-use plugin: add_filter( 'signinforge/security/client_ip', function ( $ip ) { return isset( $_SERVER['HTTP_CF_CONNECTING_IP'] ) ? sanitize_text_field( wp_unslash( $_SERVER['HTTP_CF_CONNECTING_IP'] ) ) : $ip; } ); Only do this when requests can only reach your server through that proxy. If the filter returns something that is not an IP address, SignInForge uses REMOTE_ADDR again. While rate limiting is on and nothing uses this filter, the SignInForge admin screens show an error notice when your own requests carry Cloudflare's CF-Connecting-IP header, or come from a private or local IP address with a forwarding header, which usually means a proxy stands in front of the site.

If Cloudflare cannot be reached or reports an error on its side (including a wrong secret key), the check is skipped so that nobody is locked out, and the event is logged when WP_DEBUG is on. If the widget itself fails (for example with a wrong site key), open the safe mode URL shown in SignInForge > Settings or define SIGNINFORGE_SAFE_MODE: safe mode turns Turnstile off, but not rate limiting.

With generic login errors on (the default), the lost password form gives the same answer whether or not the account exists, so that nobody can use it to find out who has an account. If emails do not arrive, check your site's email delivery; the failures are logged when WP_DEBUG is on. You can turn generic errors off in SignInForge > Settings > Security.

SignInForge requires PHP 8.1 or later and WordPress 6.9 or later.

Not yet: on multisite, registration notices are shown instead of the registration form, and deleting the plugin only cleans the site it is deleted from. Full multisite support is planned for a later release.

Only if you enable "Delete all SignInForge data" in SignInForge > Settings. Otherwise your experiences and settings are kept. The failed login counters used by rate limiting and the guided tour progress of each user are always deleted.

SignInForge is translated on translate.wordpress.org; language packs install automatically with your site language, and you can help translate it there. The plugin includes no translation files of its own. The bundled templates are translated too: a new experience created from a template uses the texts of the language of your administration screens.

The compiled scripts in build/ are generated from the TypeScript sources in assets/blocks/, assets/editor/ and assets/onboarding/ with @wordpress/scripts. Both are included in the plugin: run npm install then npm run build in the plugin directory to rebuild them.

The guided tour uses Driver.js 1.x by Kamran Ahmed, released under the MIT license (GPL-compatible). It is bundled in build/onboarding/, with its copyright and license notice in build/onboarding/driver-js-license.txt; nothing is loaded from another site.

Click "Guided tour" at the top of the SignInForge > Experiences, Templates or Settings page, or choose "Guided tour" in the Options menu of the block editor. Quitting it or finishing it is remembered for your account, so it does not start on its own again.