Performance and media

Signocore Toolkit trims what WordPress loads on your pages, limits how much history and clutter the database collects, and cleans up files as they are uploaded. Most of it works from the moment you activate the plugin. This page lists every setting, every default and everything that happens without a setting.

Performance settings

Go to Signocore Toolkit → General, find the Performance card and click Save Changes when you are done.

Setting	Default	What it does
Post Revisions	10	The number of revisions WordPress keeps per post.
Admin Heartbeat Interval	Empty	Seconds between the background requests the admin area sends, from 15 to 120.
Embed Script	On	Keeps WordPress's embed script off the frontend.
jQuery in Footer	On	Loads jQuery at the end of the page instead of in the head.
jQuery Migrate	On	Leaves jQuery Migrate out on the frontend.

Post revisions

WordPress saves a revision every time you update a post, page or product. With a number in Post Revisions, WordPress deletes the oldest revisions of a post beyond that number the next time you update it. Posts you do not touch keep all their revisions until you run Optimize WP.

Enter 0 to stop saving revisions.
Leave the field empty to let WordPress decide: it keeps every revision, or the number set with WP_POST_REVISIONS in wp-config.php.
A number here takes priority over WP_POST_REVISIONS. The highest value is 1,000.

Heartbeat

While you have the admin area open, WordPress sends small background requests, the heartbeat, for things such as post locks and the check that your login is still valid. A higher Admin Heartbeat Interval means fewer requests and less load on the server, while a notice that another user has taken over a post appears later. Leave it empty to keep WordPress's own timing.

On the frontend, Signocore Toolkit always removes the heartbeat script. There is no setting for this. A frontend script that lists the heartbeat as a dependency does not load either.

Embed script

With Embed Script on, Signocore Toolkit stops WordPress from loading its embed script on the frontend. WordPress only uses that script on pages that embed posts from other WordPress sites. Embeds from YouTube, Vimeo and other services do not depend on it.

jQuery

Both jQuery settings only matter when your theme, WordPress or a plugin already loads jQuery on the frontend. Signocore Toolkit never adds jQuery to a page, and the admin area is not affected.

jQuery in Footer moves jQuery to the end of the page, so it no longer holds up the first render. When a script in the head needs jQuery, WordPress keeps jQuery in the head for that page.
jQuery Migrate leaves out jQuery Migrate, a compatibility layer for code written for jQuery versions older than 3. If an old slider or plugin stops working, turn this setting off to load jQuery Migrate again.

The environment setting

Go to Settings → Reading and choose an Environment: Production, Local, Development or Staging, then click Save Changes. Signocore Toolkit defines WordPress's environment type, WP_ENVIRONMENT_TYPE, from your choice, so WordPress, your theme and other plugins see the same value. Until you save one, the field shows the type WordPress already uses, which is Production unless your server says otherwise.

Inside Signocore Toolkit, the environment type decides:

whether browser cache headers are sent, only in Production,
whether a missing favicon.ico is created, only in Production,
the environment label in the admin bar and whether the mail log holds emails back, while Environment Override under Dev Tools is set to Auto-detect.

Important: When WP_ENVIRONMENT_TYPE is defined in wp-config.php, that value always wins and this setting has no effect. The field then shows the value from wp-config.php, is locked and says so, and keeps your saved choice for when the line is removed. The setting is stored in the database, so it travels with a database copy: a live database copied to staging brings Production along, and a staging database copied to live brings Staging along. On sites you copy between servers, define WP_ENVIRONMENT_TYPE in each server's wp-config.php instead. Environment Type under Signocore Toolkit → Dev Tools → System Status shows the type in use.

This setting is not the same as Environment Override under Dev Tools, which only changes Signocore Toolkit's own label and mail handling. See Developer tools.

Browser cache headers

In Production, and while Discourage search engines from indexing this site is not ticked on Settings → Reading, Signocore Toolkit adds cache headers to public pages:

Pages may be kept by browsers and shared caches for one hour (Cache-Control: public, max-age=3600, must-revalidate). Single posts and pages, a static front page and the blog page also get a Last-Modified date.
Visitors who are logged in, or who have a WooCommerce cart or session, the password to a protected post or saved comment details, get WordPress's no-cache headers instead, so their personal version of a page is never stored.
Previews and the admin area get no cache headers from the Toolkit.

The Toolkit only sets headers on responses WordPress creates. Images, CSS and other files your web server delivers directly keep the server's own cache rules. When a request for such a file reaches WordPress instead, a successful answer may be cached for 30 days, or 7 days for CSS and JavaScript, while a redirect or a 404 page is not cached that long.

Favicon

In Production, when a browser asks for /favicon.ico and there is no such file in the root folder of your site, Signocore Toolkit creates it:

With a Site Icon and the Imagick PHP extension on the server, it converts your Site Icon.
Without a Site Icon, it copies the Signocore icon that comes with the plugin.
With a Site Icon but without Imagick, or when the conversion fails, it creates nothing. WordPress then sends browsers that ask for /favicon.ico to your Site Icon.

The file is created once and never replaced. To switch from the Signocore icon to your own, set a Site Icon and delete favicon.ico from the root folder. With Imagick, the next request creates the file from your Site Icon. Without it, WordPress points browsers to your Site Icon.

Uploads

These run on every upload. There are no settings for them.

File names

Every uploaded file gets a clean name: lowercase, without accents, with spaces turned into hyphens, other special characters and extra dots removed, and cut to 59 characters before the extension. Café Menu (Final).jpg becomes cafe-menu-final.jpg. The extension itself is kept as it is.

Photo orientation

Phones and cameras often save a photo sideways and store the rotation in the photo's EXIF data. For uploads ending in .jpg, .jpeg or .tiff, in lower or upper case, Signocore Toolkit rotates or flips the image itself and resets the rotation flag, so the photo shows upright everywhere, including in programs that ignore the flag. This needs the exif PHP extension, which most hosts have. Without it, the Toolkit leaves photos as they are and the upload works as usual.

Extra-large image sizes

For every large image you upload, WordPress normally creates two extra copies, 1536 and 2048 pixels on the longest side. Signocore Toolkit stops WordPress from creating them, which saves disk space and upload time. Your theme's image sizes and WordPress's other sizes are not affected, and copies created before you activated the plugin stay on the server.

SVG uploads

WordPress does not allow SVG files by default, because an SVG file can carry scripts. Signocore Toolkit allows them for trusted users and cleans every file before it is saved.

Go to Signocore Toolkit → Security and find the File Uploads card.

Setting	Default	What it does
SVG Uploads	On	Allows SVG files in the media library.
Who Can Upload SVG	Editors and administrators	Administrators, Editors and administrators, or Everyone who can upload files. Other users can still upload regular images.

What sanitizing removes

Before an SVG file is saved, Signocore Toolkit removes scripts, event attributes such as onclick and other unsafe content, and references to files on other sites, including url() references in styles. When a file cannot be made safe, the upload is refused with the message "The SVG file contains content that cannot be sanitized and was rejected."

Uploads through the media library and the editor are cleaned before WordPress stores them.
SVG files added through XML-RPC are refused with "SVG files can only be uploaded through the media library."
SVG files brought in by an importer are cleaned right after the import. A file that cannot be made safe is deleted from the server.

The media library reads the width and height of each SVG, from its size attributes or its viewBox, so SVG images show at the right size in the library and in your theme.

Clean existing SVG files

SVG files uploaded before sanitizing was in place, or copied in from another site, may still contain unsafe content. The Existing SVG Files row in the File Uploads card shows how many SVG files your media library holds.

Click Sanitize existing SVG files.
Wait while the Toolkit works through the files in batches of 100. It moves on to the next batch by itself and returns to the Security tab when all are done.
Read the notices at the top of the page:
- how many files were sanitized,
- which files could not be sanitized. These are left unchanged, so review or delete them,
- how many attachments had no file on disk and were skipped.

Run it once after updating from an older version of the plugin, and again after you import files from another site. It works even when SVG Uploads is off. Developers can change the batch size with the signocore_toolkit_svg_sanitize_batch filter.

Note: Sanitizing needs the PHP DOM extension. Without it, the File Uploads card shows "SVG sanitization is unavailable because the server is missing the PHP DOM extension. SVG uploads are rejected until it is installed.", every SVG upload is refused, and the button for existing files is hidden. Ask your host to enable the extension.

Clean up the database with Optimize WP

Optimize WP sits in the admin bar on admin screens and is shown to administrators. One click runs the tasks below and then shows "WordPress was optimized successfully!" with a count of what was removed.

Important: Everything Optimize WP deletes is deleted permanently. Back up your database before you run it.

In this order, Optimize WP:

Deletes old revisions: keeps the 5 newest revisions of every post, page and other content, and deletes the rest. This number is fixed and does not follow the Post Revisions setting.
Deletes spam comments: permanently deletes comments marked as spam, up to 1,000 per run. Run it again if you have more.
Deletes expired transients: removes cached values in the database whose expiry time has passed. Transients that are still valid are kept.
Deletes orphaned metadata: removes post, comment, term and user metadata whose post, comment, term or user no longer exists.
Optimizes tables: runs OPTIMIZE TABLE on database tables with unused space, but only tables that start with your site's table prefix.
Clears caches: resets PHP's OPcache, flushes the object cache and purges the page cache of SpinupWP, WP Super Cache, WP Rocket, WP Fastest Cache, W3 Total Cache and LiteSpeed Cache when they are installed. A CDN or your host's own server cache is not purged.
Refreshes permalinks: rebuilds the rewrite rules, the same as saving Settings → Permalinks.

It does not touch published content, drafts, the trash, or comments that are pending or approved. When the activity log is on, each run is recorded there.