WordPress 6.0 or later and PHP 7.4 or later, on any standard hosting. There is nothing exotic to install: no Node, no build step, no external service. Some optional features need a little more from the server — encrypted backups need the PHP zip extension, and the country lookup for geofencing needs outbound HTTP requests to be allowed.

Download the ZIP from your account, then in WordPress go to Plugins → Add New → Upload Plugin, choose the file and activate. On first activation nothing changes destructively: the admin picks up the new theme, and every security feature starts switched off until you enable it.

When you update to a newer version, delete the old copy first and install the ZIP fresh rather than uploading over it, then do a hard refresh (Ctrl+Shift+R) so the browser picks up the new CSS.

Almost nothing. The theme, dark mode, charts and logs all live strictly in the admin area, so your public pages are untouched and your front-end performance is unaffected.

There are exactly two deliberate exceptions, and only if you switch them on: maintenance mode, which shows your branded holding page to visitors while you work, and the custom 404 page, which replaces the theme’s default not-found page.

Deskmode Suite is designed for standard single-site installations, which is what the vast majority of agency and freelance projects use. On a Multisite network you can activate it on individual sites, and each site keeps its own settings.

If you are running a large network and want network-wide configuration, get in touch before buying so we can tell you exactly what to expect.

They can coexist, but overlapping features are worth avoiding. If your current plugin already enforces two-factor authentication or limits login attempts, enable that feature in one plugin only — running two implementations of the same protection tends to produce confusing lockouts rather than double the security.

The features that never overlap, and that you can safely keep alongside anything else, are the admin theming, the charts, the database tools and the logs.

The light and dark preference is personal: it is stored per user, so an editor who prefers a dark admin at night does not force it on everyone else, and the choice follows them across their sessions.

The accent color, logo and menu configuration are site-wide settings, because their whole point is a consistent brand for everyone who logs in.

Yes, and this is one of the most useful features for client work. You can hide menu entries entirely, or restrict them by role, so a client logging in as Editor sees a short, relevant menu instead of the full technical inventory of the site.

The admin menu can also be reordered and, when it gets long, compacted behind a “show more” button — or left fully expanded if you prefer scrolling.

That is exactly what it is built for. You can put your own logo in the admin bar and on the login page, choose an accent color that matches the client’s identity, replace the admin footer text with your own HTML — a credit line, a support link, your logo — and give the maintenance and 404 pages the same treatment.

Your settings stay in the database, untouched. Deactivating simply returns the admin to the standard WordPress look, and reactivating brings everything back exactly as you left it — accent color, hidden menu items, security rules and all.

This also means you can safely deactivate it for a moment while debugging a conflict, without having to reconfigure anything afterwards.

Yes. The login screen follows the same theme, including the form fields, which are the part most dark-mode solutions get wrong — a white input box on a dark form is exactly the kind of detail that makes a customized login look unfinished.

Because forcing it would make that page unreadable rather than dark. Some plugins ship a complete admin interface of their own, with panels whose white background is written directly into their markup. Restyling only the text on top of that produces pale grey on white — technically dark mode, practically illegible.

When we detect that pattern we deliberately leave the page in its native light appearance, which keeps it fully readable. Elementor’s admin screens are handled this way, and the same treatment can be applied to any other plugin that behaves the same. If you find one, tell us and we will add it.

Yes. On sites where you would rather not offer the choice — a client who wants one consistent look, for instance — the dark toggle can be switched off, and the admin stays light for everyone.

The plugin has an anti-lockout safeguard that protects the IP address you are currently working from, so the most common accident — blocking your own country by mistake — is prevented before it happens.

If you do get locked out some other way, the classic escape route always works: rename the plugin folder over FTP or your host’s file manager. WordPress will deactivate it on the next request and let you back in, with your settings still saved.

This is the real-world limit of country-based rules, and worth planning for. If you allow only Italy and your client logs in from a holiday in Spain, they will be blocked — correctly, from the plugin’s point of view.

The practical answers are to allow the countries your team actually travels to, or to temporarily widen the rule and narrow it again afterwards. Because every block is logged, you can also look at the log, see the legitimate attempt that was stopped and adjust with real evidence rather than guesswork.

Yes, and this matters more than it sounds. Behind a CDN or proxy, every visitor appears to arrive from the proxy’s own IP address unless the real one is read from the forwarded headers. A plugin that gets this wrong either blocks everyone or blocks no one.

Deskmode Suite uses a single, shared IP-detection routine across all its modules — geofencing, logs and rate limiting all agree on who the visitor is — and reads the forwarded headers set by common proxies.

Yes. Alongside country rules you can define allowed hours, which suits sites where nobody has any business logging in at four in the morning. Combined with rate limiting, it removes a large share of automated attempts before they ever reach the password check.

An administrator can turn two-factor authentication off for that account, letting the user sign in with their password and set it up again on the new device. It is the same recovery path used by most WordPress 2FA implementations, and the reason you should never enable 2FA on the only administrator account of a site you cannot otherwise access.

It is a single number derived from a series of concrete checks across performance, database, plugins, security and server environment. Each check can raise a critical issue or a warning, and the score is reduced accordingly, so a site with two warnings and no critical problems lands in the mid-nineties rather than being flagged as broken.

The point is not the number itself but its direction over time: the score is recorded daily, so you can show a client that the site genuinely improved after your work.

Profiling is off by default, and when you enable it the impact is deliberately contained: it samples front-end requests rather than measuring every single one, and it never runs for your visitors on cached pages.

It is meant to be switched on for a few days while you investigate a slow site, then switched off again. Leaving it on permanently is not harmful, but it is not necessary either.

Because that plugin has not run any database query during the sampled requests. Some plugins only do work in specific contexts — a checkout, a form submission, a cron job — and stay completely idle on a normal page load.

“No data” is therefore good news, not a malfunction: the plugin is loaded but is not costing you database time. Its hook count is still shown, which tells you how deeply it is wired into WordPress.

It is safe to delete leftovers from plugins you have removed, and that is usually where the bloat comes from. It is not safe to delete an option a plugin is still using, so the tool never lets you act blindly: WordPress core options that would break the site are marked as protected and cannot be removed at all, and every deletion requires a two-step confirmation showing you the exact option name.

The rule of thumb: if you recognise the prefix as a plugin you no longer have installed, it is a leftover. If you are not sure, leave it and take a backup first.

WordPress stores a lot of settings as serialized PHP arrays, and in that format every string is prefixed with its own length. A naive SQL find-and-replace changes the text but not the recorded length, and the moment the two disagree the whole value becomes unreadable — which is how widgets vanish and theme options reset after a careless migration.

The tool unpacks those structures, replaces the values inside them and repacks them with recalculated lengths, so a longer or shorter new URL leaves the data perfectly valid.

No, and no tool of this kind can: the rows are rewritten in place. That is precisely why a preview is mandatory before running one — you see how many rows in which tables will be touched, and only then can you execute.

Take a database backup first. Every screen involved says so, and it is the one instruction worth following literally.

Wherever you decide: on the site itself for a quick download, on any S3-compatible object storage, or on a remote server over FTP. Keeping at least one copy off the server is the whole point — a backup that lives only on the machine you are trying to recover is not really a backup.

You choose the scope before running one: the database alone, which is small and fast and covers content and settings, or the database together with the site files, which is what you want before a major update or a migration.

The page also estimates the size before you start, so you know whether you are about to create a 40 MB archive or a 4 GB one — useful on hosting with tight limits.

The things you actually need when something changes unexpectedly: who logged in and when, what was published or edited, which plugins were activated or updated, and which settings were altered. On a site with several editors it turns “the page just changed by itself” into a name and a timestamp.

It records the messages your site sends — recipient, subject, time, delivery outcome and the body — which is what makes it genuinely useful when a customer swears they never received the order confirmation.

Treat it as personal data. It sits in your own database and is never sent anywhere, but if you handle enquiries from EU users you should mention it in your privacy policy and clear it periodically, exactly as you would with any other record of correspondence.

Yes, blocked attempts and logins are recorded with the originating IP address — without it the geofencing charts would be meaningless. Under the GDPR an IP address is personal data, but recording it for the security of your own systems is a recognised legitimate interest.

What you should do is the ordinary housekeeping: mention it in your privacy policy, and do not keep the records longer than you need them.

Yes. Deactivate the license on the old site to free the slot, then activate it on the new one. This is the normal workflow when a client project ends or when you move a site from a staging domain to production.

They should not have to, and that is a fair expectation: nobody wants to spend a paid slot on a copy of a site. If your workflow involves several staging environments, tell us how you work before buying and we will point you to the right plan.

There is a 14-day money-back guarantee. If the plugin does not do what this site says it does and we cannot fix it for you, write to support within fourteen days of your purchase and you get your money back.

We would rather solve the problem than process the refund, so it is always worth describing the issue first — most of them turn out to be a conflict we have seen before.

Deactivating changes nothing. A full uninstall is the moment to be deliberate: the admin returns to the WordPress default, and the plugin’s own records — settings, logs, collected statistics — are removed with it.

If you want to keep your activity or mail history, export it before uninstalling. Your content, users and any other plugin’s data are never touched.

The interface ships in English, Italian, Spanish, French and German. If you run a multilingual admin with WPML or Polylang, the plugin’s own customizable strings — the footer text, the maintenance and 404 pages — can be translated per language from the usual string translation screen, so your Italian editors and your German ones each see the right wording.