MagicWP Updates: Sharper Monitoring and More Site Control

This release sharpens how you watch your sites and widens what you can do to them. Resource monitoring now measures every minute instead of every five, so spikes and trends show up much sooner. And a set of new control tools lands alongside it: clone a site onto an existing site, reset any WordPress user's password, set a custom database table prefix, and hand a whole site over to another MagicWP account.

Here's what shipped and how to use it.

TL;DR

• Per-minute monitoring — PHP, Nginx, and database CPU and memory are now sampled every minute instead of every 5, so the Live view is far more responsive and the Daily view shows finer detail. The three usage cards are now clickable, too.
• Clone onto an existing site — overwrite one of your sites with a complete copy of another, with an automatic safety backup of the target and links rewritten for you. Ideal for refreshing staging from live.
• Reset a WordPress user's password from the dashboard — pick the user, set or generate a strong password, save. It's never stored on our side, so copy it before saving.
• Custom database prefix — rename your tables to a custom prefix, with an automatic backup first and rollback if anything fails.
• Transfer a site to another account — hand a site to another MagicWP account; the recipient confirms with a 6-digit code, and nothing moves until they accept.

Faster, more detailed monitoring

Your site's resource usage — PHP, Nginx, and database, both CPU and memory — is now measured every minute instead of every 5 minutes. That's five times the resolution, and it changes what the charts are actually good for.

The difference shows up in two places. The Live view updates far more responsively, so when something is happening right now you see it as it happens rather than in five-minute chunks. The Daily view shows finer detail, which means short spikes that a coarser sample would smooth over and hide now actually appear.

That last point is the practical one. A traffic spike, a runaway plugin, or a heavy cron job can come and go inside a five-minute window and leave almost no trace on a chart that only samples every five minutes. At one-minute resolution the spike is visible, so you can catch it, connect it to a cause, and act before it turns into a pattern. Trends surface sooner too, which is what you want when you're deciding whether a site is genuinely growing into a bigger plan or just had a busy afternoon.

One small quality-of-life addition: the three usage cards are now clickable. Tap PHP, Nginx, or database and you jump straight to that service's charts, instead of hunting for them.

Clone a site onto an existing site

Cloning used to mean one thing: make a brand-new copy. Now it can also overwrite an existing site with a complete copy of another one. You'll find it under Site → Settings → Clone Site (also under Tools); pick Clone to an existing site, choose the target, and that site gets a full copy of the source — files, database, themes, and plugins.

Two things make this safe to run against a site that already has content on it:

• A safety backup of the target is taken first, before anything is overwritten. If the result isn't what you wanted, you have a restore point for the target exactly as it was.
• Links and URLs are rewritten automatically, so the overwritten site works immediately on its own domain rather than pointing back at the source. That URL rewrite is the step that breaks in a manual clone, because URLs are buried in serialized database data where a blind find-and-replace corrupts things. Having it handled is the difference between a clone that just works and one you spend an afternoon debugging.

The obvious use is refreshing a staging site from your live one. Point live → staging, and staging becomes an exact current copy you can test against, as often as you like, without rebuilding it each time.

Important: Clone to an existing site overwrites the target completely — its current files and database are replaced. The automatic safety backup means you can roll the target back, but make sure you've picked the right target before you confirm. This is the one action in this release where the direction matters: source overwrites target.

Reset a WordPress user's password

You can now reset any site user's WordPress password from the dashboard, under Tools → WordPress admin password. Pick the user, type a password or hit Generate for a strong one, and save. It applies instantly.

This is the fix for the classic lockout: an admin who can't get into wp-admin, a client who lost access, or a stale account you need to secure. Instead of dropping into the database or juggling password-reset emails, you set the new password directly.

Copy it before you save. The password is never stored on our side — that's the secure design, but it means once you save, we can't show it to you again. Copy a generated password before saving, or you'll have to reset it a second time.

Custom database prefix

You can now rename your WordPress database tables to a custom prefix from Tools → Database prefix. Type one or Generate it, confirm, and the platform backs up first and applies it safely, with automatic rollback if anything fails.

It's worth being straight about what this does and doesn't buy you. By default WordPress names its tables with the wp_ prefix, and a lot of automated attacks — bots running scripted SQL injection attempts — assume that default and target table names like wp_users and wp_options directly. Changing the prefix to something unpredictable makes those blind, default-assuming attacks miss, so it stops a chunk of low-effort automated noise.

That's real, but it's modest. This is security through obscurity: it doesn't fix any underlying vulnerability, and a targeted attacker who already has some access can discover the prefix. Treat it as one small hardening step in a layered setup — alongside strong passwords, keeping WordPress and plugins updated, and the platform's own protections — not as a security measure you lean on by itself. What this release adds is that the change is now safe and reversible instead of a risky manual edit, which is the part that usually made people avoid doing it at all.

The safe-apply mechanics are the real value here: renaming table prefixes by hand means editing the database and wp-config.php in sync, and a mistake can take the site down. Backing up first and rolling back automatically on failure removes that risk.

Transfer a site to another account

You can now hand a site over to another MagicWP account. Start from WordPress Hosting → Transfer a Site, enter the recipient's email, and they get a 6-digit code to confirm the move. Nothing changes hands until they accept, and you can cancel any time before it's confirmed.

This is built for the handoffs that actually happen: an agency delivering a finished site to a client's own account, a freelancer transferring ownership at the end of a project, or moving a site between two accounts you control. The confirmation step matters — a site can't be pushed onto someone without their say-so, and the pending transfer is cancellable, so a mistyped email or a changed plan isn't a problem.

A fresh look for our emails

Smaller but visible: receipts, email verifications, and site and ticket notifications now match the MagicWP brand — the logo and colors throughout — for a cleaner, more consistent look in your inbox. Same emails, easier to recognize at a glance.

Frequently Asked Questions

How often is my site's resource usage measured now?

Resource usage for PHP, Nginx, and the database — both CPU and memory — is now sampled every minute, up from every 5 minutes. The Live view updates much more responsively, and the Daily view shows finer detail, so short spikes that a coarser sample would have smoothed over now show up. You can also click any of the three usage cards to jump straight to that service's charts.

What's the difference between cloning to a new site and cloning to an existing one?

Cloning to a new site creates a fresh copy as a brand-new site. Cloning to an existing site overwrites one of your other sites with a complete copy — files, database, themes, and plugins — of the source. The target is safety-backed-up first and its URLs are rewritten automatically. Use the existing-site option to refresh a staging site from live; just confirm you've picked the right target, since it's overwritten completely.

Where does my WordPress password go after I reset it?

It's applied to the site instantly and never stored on MagicWP's side. That's a deliberate security choice, but it means we can't show the password to you again after you save. If you generate a strong password, copy it before saving — otherwise you'll need to reset it again to get a value you know.

Does changing my database prefix actually make my site more secure?

It helps a little, as one small layer. Many automated attacks assume the default wp_ table prefix, so changing it to something unpredictable makes those scripted attacks miss and cuts down low-effort automated noise. But it's security through obscurity — it doesn't fix any real vulnerability and won't stop a targeted attacker. Use it alongside strong passwords, updates, and other protections, not on its own. The platform backs up first and rolls back automatically if the change fails.

Can someone transfer a site to me without my permission?

No. A site transfer only completes when the recipient enters a 6-digit confirmation code, so nothing moves onto your account unless you accept it. The person starting the transfer can also cancel any time before it's confirmed. This two-sided confirmation is what keeps sites from being pushed onto an account by mistake or without consent.

Wrapping up

The through-line is a sharper view of your sites and more you can do with them directly. Per-minute monitoring turns the charts into something you can actually catch problems with, not just a rough trend line. Clone to an existing site, WordPress password resets, a custom database prefix, and account-to-account transfers each remove a task that used to mean a support ticket or a risky manual edit — with safety backups and confirmations built into the ones that need them.

Everything is live in the dashboard now. If you manage sites for other people, the site transfer and the refresh-staging-from-live clone are the two worth trying first — they cover the handoffs and the routine testing that eat the most time.