Settings
Every setting on Side Kick's General and Login & passwords pages, what each one does, its default and what to watch out for.
Written for Side Kick 2.18.4
Open Darwin Side Kick and click Settings at the bottom of the sidebar. Side Kick's own settings are split across two pages, General and Login & passwords. Use the buttons at the top to switch between them. Modules can add their own pages here too.
Each group of settings is labelled to show who it affects: applies to the whole site, or only affects your own account. Settings that belong to you alone also carry a Per user badge.
Saving your changes
Changes are not saved as you make them. The bar at the bottom of the screen counts what you have changed, for example 2 unsaved changes.
- Save changes saves everything you have changed, on both pages at once. A message confirms how many settings were saved.
- Discard puts every setting back to how it was when you last saved.
You can move between General and Login & passwords without losing unsaved changes.
Unsaved changes are lost if you leave the Settings screen, including moving to another Side Kick section. Save first.
General
Appearance
Dark mode. Default: off. Shows Side Kick's screens in a dark colour scheme. This is a personal setting: it only changes what you see, and other users keep their own choice. When you click the switch you get a preview straight away. Discard takes the preview away again.
Modules
Hide modules from the plugins screen. Default: off. Removes Side Kick modules from the WordPress Plugins list. They stay installed and active, and you can still manage and update them from the Dashboard. To delete a module, switch this off first so it shows on the Plugins screen again.
Logging
Protect debug.log. Default: off. When WordPress logs errors, it writes them to a file called debug.log in your wp-content folder. Anyone who guesses the address can open that file in a browser, and it can reveal details about your server.
When you switch this on, Side Kick adds a short rule to the .htaccess file in your wp-content folder. An .htaccess file holds instructions for the web server. This rule tells it to refuse all web requests for debug.log. The rule sits between two marker lines, so you can recognise it:
# BEGIN DarwinSK Guard: Debug Log
...
# END DarwinSK Guard: Debug Log
Side Kick never touches anything outside those markers. It removes its rule again when you switch the setting off, deactivate Side Kick or delete it. If the rule was the only thing in the file, the file is removed too.
This only works on Apache and LiteSpeed web servers. Servers running nginx (or Microsoft IIS) ignore .htaccess files, so you need your host to add an equivalent rule to the server's own configuration. The setting only covers debug.log in wp-content. If your site writes its log somewhere else, that file is not protected. If the server will not let WordPress write to the .htaccess file, the rule is not added, and no message tells you, so it is worth checking.
Content
Duplicate button. Default: on. Adds a Duplicate link beside Quick Edit on your post, page and custom post type lists. The copy is always a draft. See Duplicating pages and posts.
Editor and endpoints
Disable Gutenberg. Default: off. Gutenberg is WordPress's block editor. Switching this on:
- uses the classic editor for every post type;
- uses the classic widgets screen instead of the block-based one;
- stops the block editor's stylesheets and scripts loading on your site and in the admin.
Content that was built with blocks may look different once the block stylesheets stop loading. Check your key pages after switching this on.
Disable XML-RPC. Default: off. XML-RPC is an older way for apps and other sites to talk to WordPress remotely. It also carries pingbacks, which are automatic notices sent when one site links to another. If nothing on your site needs it, switching it off closes an unused way in. Switching this on:
- refuses any request sent directly to the XML-RPC address;
- removes every XML-RPC function and refuses pingbacks;
- removes the headers and page links that advertise XML-RPC;
- stops your site sending pingbacks to sites you link to.
Any app or service that still relies on XML-RPC to connect to your site will stop working.
Disable comments. Default: off. Switches comments off across the whole site. It:
- removes comment and trackback support from every post type, and closes comments and pingbacks everywhere;
- hides existing comments and comment counts on the site;
- removes comment feeds and refuses requests for them;
- removes the Comments menu and the Discussion settings page, and blocks them if someone visits by web address;
- removes the comments icon from the admin bar, the recent comments box and comment counts from the admin dashboard, and the Recent Comments widget;
- stops the comment-reply script loading;
- blocks comments through the REST API (the route apps and plugins use to read and write site data) and through XML-RPC;
- turns off the discussion panel in the block editor.
Existing comments are hidden, not deleted. They come back if you switch this setting off.
Login & passwords
These rules are checked whenever a password is set: on a user's profile screen, on the Edit User and Add New User screens, on the password reset form, and on the registration form if it asks for a password. Passwords people already have are not checked until they next change them. If a password breaks more than one rule, all the problems are listed together.
Force strong passwords
Force strong passwords. Default: off. New passwords must have:
- at least 12 characters;
- an uppercase letter (A–Z);
- a lowercase letter (a–z);
- a number (0–9);
- a symbol from this list:
! @ # $ % ^ & * ( ) _ + - = { } ; : ' " , . < > ? ~ [ ] / | `
The password also must not contain the person's username, or the part of their email address before the @. This check only applies when that username or email part is 4 characters or longer. Characters outside the list above, such as £ or accented letters, do not count as symbols. The rules themselves are fixed and cannot be changed.
When the setting is on, a Roles it applies to box appears beneath it. Click it to choose which user roles must follow the rules. If you leave it empty, the rules apply to everybody. When someone's role is changed in the same save as their password, both the old and the new roles count. A person registering on the front end is judged by your site's default role for new users.
The rules are listed under the heading Your password must have: on the standard WordPress password reset and registration forms. If your site uses a custom login page, the list is not shown there, but the rules still apply.
Block breached passwords
Block breached passwords. Default: off. Applies to everybody. Rejects any password known to have appeared in a public data breach. It checks with the free Pwned Passwords service from Have I Been Pwned, without ever sending the password. Here is how:
- Your site turns the password into a fixed-length code called a hash. This works one way only: you cannot turn the hash back into the password.
- Only the first five characters of that hash are sent to the service.
- The service replies with every breached hash that starts with those five characters, padded out with dummy entries so that even the size of the reply gives nothing away.
- Your site compares the list itself. The service never learns which password, if any, matched.
Your site waits up to 3 seconds for an answer. If the service cannot be reached, the password is allowed through. This means an outage elsewhere can never stop you changing your own password. If both this and Force strong passwords are on, the rules list on the login forms adds a line saying the password must not appear in a known data breach.
Stop passwords being reused
Stop passwords being reused. Default: off. Applies to everybody. Stops people switching back to a password they have used recently.
When it is on, a Passwords to remember box appears beneath it. It sets how many previous passwords each user is blocked from reusing. Default: 5. You can choose any number from 1 to 50.
Side Kick keeps a one-way hash of each new password, in the same form WordPress uses to store passwords, never the password itself. A user's history is deleted when that user is deleted.
The history starts when you switch this on. Passwords set before then are not known, so it takes effect as people change their passwords. This history is not removed if you delete Side Kick. See Getting started.