Troubleshooting

Most problems with Signocore Toolkit come from a protection doing its job a little too well, a cache showing an old version, or a missing theme or plugin that a feature depends on. Start with the section that matches what you see.

Locked out after failed logins

The login page says "Too many failed login attempts. Please try again in 30 minutes.", counting down the minutes that are left. Login protection has blocked your IP address. Try these in order:

1. Wait until the block ends. It lasts 30 minutes unless you changed Block Duration (minutes).

2. Log in from another network, such as a phone on mobile data. A block applies to one IP address.

3. Turn login protection off without logging in. With your host's file manager or FTP, add this line to wp-config.php, above the line that says That's all, stop editing!:

   define('SCTK_LOGIN_PROTECTION', false);
   

   Log in, add your IP address under Trusted IP Addresses on Signocore Toolkit → Security, and remove the line again. A block that is still running applies again once the line is gone, but never to a trusted address.

4. Deactivate and activate the plugin, which clears all current blocks unless your site keeps its cache in a persistent object cache. Another administrator can do this on the Plugins screen. With WP-CLI, run wp plugin deactivate signocore-toolkit and then wp plugin activate signocore-toolkit.

A successful login does not reset the count of failed attempts, so a few typos spread over the attempt window still add up.

Everyone gets blocked at once

When the site runs behind Cloudflare, a load balancer or another proxy that Signocore Toolkit does not recognize, every visitor seems to come from the same IP address, and one person's failed logins block everyone. Look at Your IP Address on Signocore Toolkit → Security. If it shows a warning, or an address that is not yours, choose the header your proxy uses under IP Detection. See IP detection behind Cloudflare or a proxy.

You forgot the hidden login address

With Hide Login Page on, /wp-login.php shows your theme's 404 page, and so does /wp-admin/ for anyone who is not logged in. That is on purpose. To get back in:

1. Try the default address, /login/ (or /?login=1 with plain permalinks), in case the slug was never changed.

2. Ask another administrator who is logged in to read Login Slug on Signocore Toolkit → Security.

3. Look for a password reset or new user email from the site. Its login link uses the hidden address.

4. Turn the hidden login page off without logging in. With your host's file manager or FTP, add this line to wp-config.php, above the line that says That's all, stop editing!:

   define('SCTK_HIDE_LOGIN', false);
   

   Log in at /wp-login.php, read or change Login Slug on Signocore Toolkit → Security, and remove the line again.

5. With WP-CLI, run wp plugin deactivate signocore-toolkit, log in at /wp-login.php, activate the plugin again and read the slug on the Security tab. Your settings are kept.

6. Without WP-CLI, rename the folder wp-content/plugins/signocore-toolkit with your host's file manager or FTP, for example to signocore-toolkit-off. Log in at /wp-login.php, rename the folder back, and activate the plugin on the Plugins screen if WordPress has deactivated it.

SCTK_LOGIN_PROTECTION does not help here: it turns off login protection, not the hidden login page. SCTK_HIDE_LOGIN is the switch for the hidden login page. For more, see Get back in.

Consent choices are not applied

Google tags run before consent

Signocore Toolkit sets the Google Consent Mode defaults early in the page head. A Google tag only respects them if it loads afterwards.

1. Open a page in a private browser window and view its source. The line gtag('consent', 'default' must come before your Google tag or Tag Manager snippet.
2. If it comes after, the tag is printed too early, for example written into the theme's header.php above wp_head(). Move it into wp_head, as shown in Cookie consent and Consent Mode.
3. In Google Tag Manager, tags that are not from Google ignore Consent Mode until you give them consent settings. See Google Tag Manager.

Other scripts run before consent

The Toolkit does not block scripts, iframes or pixels by itself. Consent Mode only reaches Google tags. Load everything else, such as advertising pixels and chat widgets, only after consent, as shown in Load other scripts only after consent. The events and the cookie format are listed under JavaScript consent events.

Custom categories added with a filter are not sent to Google at all. Only Analytics and Marketing map to Consent Mode.

A performance plugin changes the scripts

Plugins that delay JavaScript until the visitor interacts, or that move and combine inline scripts, can break the order the consent setup relies on. Exclude these from delaying and combining:

• the inline script in the head that contains gtag('consent', 'default',
• the inline script that contains sctkConsentConfig,
• signocore.min.js from the plugin's assets/js folder.

Signs of the problem: the banner appears late, tags fire before the defaults, or the consent cookie lasts 365 days whatever you set in Consent Duration (Days).

The banner comes back on every page

• The site does not use HTTPS. The consent cookie is marked secure, so browsers only store it over HTTPS. On a plain HTTP address the choice is not saved.
• The choice has expired. Visitors are asked again after the number of days in Consent Duration (Days).
• The browser blocks or clears cookies, as private windows do when they close.

To check, open your browser's developer tools and look for a cookie named sctk_consent after you click Accept All.

A script or form is blocked by the Content Security Policy

Signocore Toolkit sends a Content-Security-Policy header with frontend pages. When it blocks something, the browser console shows a Content Security Policy error that names the directive, such as form-action or script-src. Common cases:

• A form that submits to another domain, such as a newsletter sign-up form that posts to an email marketing service (form-action).
• Code that uses eval(), such as custom JavaScript variables in Google Tag Manager (script-src).
• A chat widget or another tool that opens a WebSocket connection (wss:) to another domain (connect-src).
• A script that starts a web worker from a blob: address, as some map libraries do (script-src).
• Your pages shown inside a frame on another domain (frame-ancestors).
• A resource that is only available over plain HTTP (upgrade-insecure-requests).

To allow what you need, change the policy with the signocore_toolkit_security_headers filter. This callback adds a newsletter service to the Toolkit's policy:

add_filter('signocore_toolkit_security_headers', function (array $headers): array {
    if (isset($headers['Content-Security-Policy'])) {
        $headers['Content-Security-Policy'] = str_replace(
            "form-action 'self'",
            "form-action 'self' https://newsletter.example.com",
            $headers['Content-Security-Policy']
        );
    }

    return $headers;
});

To allow eval() for Google Tag Manager, to drop a header, to replace the policy with your own, or to test one in report-only mode, see Override the headers. A policy that your web server, host or CDN adds does not replace the Toolkit's. Browsers then enforce both, so keep the policy in one place. After a change, clear your page cache, since cached pages keep the old header.

Maintenance mode shows to the wrong people

• A logged-in user sees the maintenance page. Only users with the role in Who Can See the Site or higher see the normal site, Editors and administrators by default. Customers, subscribers and authors see the maintenance page like any visitor. Choose All logged-in users to let every account through.
• You see the normal site, but want to check the maintenance page. Your role lets you through. Open the site in a private window.
• A visitor from an allowed IP address still sees the maintenance page. The address must match the one Signocore Toolkit detects. Compare it with Your IP Address on Signocore Toolkit → Security and check IP Detection.
• The old state still shows after you switch. The Toolkit clears common caching plugins when the mode changes, but not a CDN or your host's server cache. Purge those yourself. See Caching.

The login page, the admin area and the REST API stay reachable for everyone while a mode is on.

Share buttons or breadcrumbs do not show

Share buttons

Signocore Toolkit places share buttons through hooks in the Kadence theme and in Signocore Slate. With any other theme, posts and pages get no share buttons.

With Kadence or Signocore Slate, check that:

• the post type is ticked under Signocore Toolkit → Social → Add social sharing, Posts by default,
• you are looking at a single post or page. The home page, the front page and WooCommerce pages never get the buttons.

Products are the exception. When Products is ticked, share buttons appear at the end of the product summary with any theme that uses WooCommerce's standard product page.

The buttons are cached per post. Saving the post builds them again.

Breadcrumbs

The breadcrumbs come from Signocore SEO, so it must be active.

• Kadence and older versions of Signocore Slate: the Toolkit prints Signocore SEO's breadcrumbs right below the header and hides the theme's own breadcrumbs. While Signocore SEO is inactive, the Toolkit leaves the theme's breadcrumbs alone, so they show as usual.
• Versions of Signocore Slate with their own breadcrumb settings: the theme prints Signocore SEO's breadcrumbs itself, where its settings place them.
• Any other theme: the Toolkit adds nothing. Place Signocore SEO's breadcrumbs with its shortcode or block, see Shortcodes and blocks.

Shortcodes print nothing

• Signocore SEO is not active. [company-name], [phone], [email], [address], [zip], [city], [country], [vat], [contact] and [social-links] read their data from Signocore SEO and print nothing without it, even when the details are still in the database.
• The field is empty. Fill it in on Signocore SEO → Company, or the profiles on Signocore SEO → Social. Only [company-name] and [email], also inside [contact], fall back to the site title and the administration email address.
• WooCommerce is not active, or no logos are selected. [payment-methods] needs both.
• The shortcode shows up as text. The place you put it does not run shortcodes. Use a Shortcode block, or do_shortcode() in a template. Also check the attribute quotes: curly quotes pasted from a word processor are not read as quotes.

See Shortcodes for every attribute.

An SVG upload is refused

Message	Cause	What to do
"Sorry, you are not allowed to upload this file type."	WordPress's own message. SVG Uploads is off, or your role is below Who Can Upload SVG.	Turn on SVG Uploads on Signocore Toolkit → Security, or ask an administrator to upload the file or to change Who Can Upload SVG.
"You are not allowed to upload SVG files."	Your role is below Who Can Upload SVG. This version of the message comes from Signocore Toolkit.	The same as above.
"The SVG file contains content that cannot be sanitized and was rejected."	The file has content that cannot be made safe, or it is not a valid SVG file.	Export the file again from your design tool as a plain SVG, then upload it.
"SVG uploads are not available because the server is missing the PHP DOM extension."	The server cannot sanitize SVG files.	Ask your host to enable the PHP DOM extension.
"The SVG file could not be read."	The file is empty or could not be opened.	Check the file and upload it again.
"The sanitized SVG file could not be saved."	The server could not write the cleaned file.	Ask your host to check disk space and folder permissions.
"SVG files can only be uploaded through the media library."	The file came through XML-RPC, for example from an app.	Upload it in the media library.

See SVG uploads for how sanitizing works.

Emails still arrive from a staging site

Prevent Sending only holds emails back while Signocore Toolkit's environment is not Production. Check the Mail Log card on Signocore Toolkit → Overview: it says Sending blocked when the block is active. If it says Sending allowed, set the environment as described in Stop emails on a staging site.

If the card says Sending blocked and emails still arrive, a mail plugin that replaces WordPress's mail function is sending them. The Mail Log page then shows a warning that the Toolkit cannot guarantee that emails are stopped, and lists such emails as Not confirmed rather than Blocked. Turn off that plugin's sending on the staging site.

Admin notices

Notice	What it means	What to do
"Signocore Toolkit requires PHP ... or higher"	The server runs a PHP version that is too old, so the plugin has paused itself.	Ask your host to update PHP. See platform support.
"Signocore Toolkit could not load its dependencies"	Some of the plugin's files are missing.	Upload a fresh copy over the old one: on Plugins → Add New Plugin, click Upload Plugin, choose the zip file and click Replace current with uploaded. Do not delete the plugin first, because deleting removes its settings and logs.
"Unlock the full potential of Signocore Toolkit"	Signocore SEO is not installed. The company shortcodes need it.	Install Signocore SEO, or dismiss the notice.
"Signocore SEO is ready to activate"	Signocore SEO is installed but not active.	Click Activate Signocore SEO, or dismiss the notice.
"Signocore Toolkit now limits failed login attempts ..."	A one-time note that login protection is on.	Add your own IP address under Trusted IP Addresses, then dismiss it.
"Maintenance mode is active. ..." or "Coming soon mode is active. ..."	Visitors see the maintenance or coming soon page. Administrators see this on every admin screen.	Click Turn off when you are done, or Settings to change the page.
"The login slug "..." is reserved by WordPress, so the login slug was not changed." or "A page already uses the slug "...", so the login slug was not changed."	Shown after you save the Security tab. The new slug is a word WordPress uses in its own addresses, or a page already has it, so the Toolkit kept the slug you had. The other settings were saved.	Choose another Login Slug.
"Another plugin replaces wp_mail(), so Toolkit cannot guarantee that emails are stopped. ..."	Shown on the Mail Log page while Prevent Sending is active and a mail plugin replaces WordPress's mail function.	Turn off that plugin's sending on the staging site. See Emails still arrive from a staging site.
"The login slug "..." is not allowed. Please choose a different slug."	The saved slug, from before the Toolkit checked slugs on save, is a word WordPress uses in its own addresses, so the hidden login page cannot work with it.	Choose another Login Slug right away, before you log out.
"Signocore Toolkit: Debugging is enabled. Please disable it in production environments."	WP_DEBUG is on in wp-config.php.	Turn it off on your live site. See Debug notice.
"SVG sanitization is unavailable because the server is missing the PHP DOM extension. ..."	Shown in the File Uploads card. SVG files cannot be cleaned, so SVG uploads are refused.	Ask your host to enable the PHP DOM extension.
"... SVG files could not be sanitized and should be reviewed or deleted:"	After Sanitize existing SVG files, these files could not be made safe and were left unchanged.	Open each listed file in the media library and delete or replace it.
"... SVG attachments have no file on disk and were skipped."	These media library entries point to files that no longer exist.	Delete the entries, or restore the files from a backup.
"The activity log is disabled. New events are not recorded."	Shown on the Activity Log page while Record Activity is off.	Turn on Record Activity on Dev Tools → Settings.
"Warning: your request carries the proxy header ..." or "Warning: the connecting address is a private network address ..."	Shown under Your IP Address on the Security tab. IP detection does not match your server setup.	Choose the right option under IP Detection. See Everyone gets blocked at once.

If you are stuck, contact Signocore with a description of the problem and what you have tried.