
MagicWP Updates: Templates, Temporary Sites and PHP 8.5
Try MagicWP on a real WordPress site before you pay, start from a ready-made template, pick themes and plugins up front, and run your sites on PHP 8.5.

This month is about the first ten minutes with MagicWP. You can now create a real WordPress site before you choose a plan, start it from a finished design instead of an empty install, and decide its address, theme and plugins before it's built. If you like what you see, choosing a plan keeps that exact site. Nothing gets moved or rebuilt.
There's more for people already running sites here: PHP 8.5 is available, staging copies now sit right under their live site, ⌘K search reaches every page in the dashboard, and two fixes stop PHP notices from plugins like Elementor breaking Magic Login and several dashboard pages. Here's what shipped and what it means for you.
TL;DR
- Temporary sites let you build a real WordPress site on the same platform paying customers use, before you pick a plan. Pick a plan while it's running and you keep it as is: same address, same content.
- Start from a Template gives you a ready-made site with content, theme and plugins in place, updated before handover. Free on every plan and on temporary sites.
- Advanced Mode on the create-site form lets you name your own subdomain and choose themes and plugins before the site is built.
- PHP 8.5 is available for new and existing sites. New sites default to PHP 8.4. PHP 8.0 and 8.1 are gone from the list.
- ⌘K search (Ctrl+K on Windows and Linux) jumps to any site or setting by name.
- Fixes and security: Magic Login and the Plugins, Themes, WP Settings, Debug and Redis pages no longer break on sites that log PHP notices, and Google sign-in only links to an account whose email is confirmed.
Temporary sites: try it on a real site before you pay
Most hosting trials give you a demo account or a sandbox that looks a bit like the real product. A temporary site is not that. It's a real WordPress site, running on the same stack a paying customer gets, so what you test is what you'd actually be running. Page speed, the dashboard, Magic Login, the database tools: you're judging the real thing.
Before you create one, the screen tells you how long it will run, so there's no surprise expiry. Three things make it worth using properly rather than as a quick poke around:
- Choosing a plan keeps the site. If you pick a plan while the temporary site is running, it becomes your site. Same address, same content, nothing to export or re-import. That means the work you do during the trial isn't throwaway.
- Running out of time isn't instant deletion. When the time is up, the site is stopped first and removed later. In between there's a window where you can still pick a plan and get everything back.
- You get a warning. We email you before the site stops.
A practical way to use this: don't just install WordPress and look at the dashboard. Build the thing you actually plan to run. Install the plugins your real site uses, import some content, and check the pages that matter to you. If you're thinking of moving an existing site, a temporary site is a good place to see how your theme and plugin set behave on our stack, and on a newer PHP version, before you commit.
Note: The exact trial length is shown on the screen when you create the site. Don't treat a temporary site as a place for anything you can't afford to lose until you've chosen a plan.
Start from a Template
The other half of a better start is not starting from nothing. Start from a Template lets you pick a ready-made site that already has its content, theme and plugins in place. You can look at a live demo of each template on desktop and mobile before you choose, then we build your site from it.
Before we hand the site over, we update WordPress, the theme and the plugins. That matters more than it sounds. A template is a snapshot, and snapshots age. Without that step, a fresh site could start life with outdated plugins, which is both a security risk and an annoying first job. You get the design and the current versions together.
Templates are free on every plan and work on temporary sites too, so you can try a template and the hosting in one go. The template docs walk through picking one and creating your site from it.
There's also a guard against a common mistake. Some templates rely on plugins or themes that don't run on every PHP version. Any PHP version a template can't run on is greyed out when you create the site, so you can't pick a combination that won't work.
Advanced Mode: your own subdomain, your themes, your plugins
The create-site form now has an Advanced Mode for people who know what they want before the site exists.
- Name your own address. Instead of taking a generated subdomain, you pick it. That's handy if you'll share the site with a client or teammate before a custom domain is connected, since a readable name is easier to recognise than a random one.
- Choose themes and plugins before the build. We install them and switch them on, so the site you open is already set up the way you meant it to be.
- Pick several themes and mark one as active. The stock WordPress themes are removed, so you don't start with default themes you'll never use sitting in the Themes list.
If you build sites for clients and always start with the same base (a particular theme, a page builder, an SEO plugin, a forms plugin), Advanced Mode turns that first half hour of clicking into part of the create form. When a custom domain is ready, our guide to creating a new site and the Domain docs cover connecting it.
A setup screen that shows what's happening
Creating a site used to be a short wait with not much to look at. Now the setup screen shows each stage as it actually happens: DNS, files, containers and the WordPress install. A preview of your site builds up on its own address next to it.
When it's done you land on the site's Overview. Until then, the site's other pages stay closed. That's on purpose: opening the Plugins page or the database tools on a half-built site is a good way to get confusing errors or interrupt the install. Now you simply can't.
PHP 8.5, and PHP 8.4 as the new default
PHP 8.5 is now available for new and existing sites. At the same time, new sites start on PHP 8.4, which we now recommend for most sites, and PHP 8.0 and 8.1 no longer appear in the version list.
Here's where each version stands, based on the PHP project's own support schedule:
| PHP version | Status on php.net | On MagicWP |
|---|---|---|
| 8.0 | End of life since 26 Nov 2023 | Removed from the list |
| 8.1 | End of life since 31 Dec 2025 | Removed from the list |
| 8.2 | Security fixes only, until 31 Dec 2026 | Available |
| 8.3 | Security fixes only, until 31 Dec 2027 | Available |
| 8.4 | Active support until 31 Dec 2026, security until 31 Dec 2028 | Default for new sites |
| 8.5 | Active support until 31 Dec 2027, security until 31 Dec 2029 | Available |
On the WordPress side, core documents full support for PHP 8.4 from WordPress 6.8 and full support for PHP 8.5 from WordPress 6.9. WordPress dropped the "beta" label for both earlier this year. WordPress's own minimum recommended version is PHP 8.3.
Why the default is 8.4 and not 8.5
If WordPress core supports 8.5, why not make it the default? Because your site isn't just WordPress core. It's core plus a theme plus a stack of plugins, and plugins and themes are usually the last to catch up with a new PHP release. PHP 8.4 has had a year for that to happen. PHP 8.5 is newer, and some plugins will still throw deprecation notices or worse on it.
So our advice is simple: use 8.4 unless you have a reason not to. Move to 8.5 when your plugins and theme say they support it, or after you've tested it.
Should you move to PHP 8.5?
For most site owners the real gain from 8.5 is staying current, not a new feature. Most of the headline changes are for developers: a pipe operator, array_first() and array_last(), and a new built-in URI extension. One change helps anyone debugging a site: fatal errors now include a backtrace, so the error tells you how the code got there, not just where it died.
There are deprecations too. A few older PHP habits now raise deprecation warnings, like the backtick operator as a shortcut for shell_exec() and the long cast names such as (integer) and (boolean). A deprecation warning doesn't break your site, but older plugins can fill your logs with them, which is worth knowing given the notice fixes further down.
A safe way to try it:
- Take a backup of the live site first. See our backup docs.
- Create a staging copy and switch that copy to PHP 8.5, if your plan and site allow a different PHP version on staging. If not, test on a temporary site with the same theme and plugins.
- Turn on debug logging, click through the pages that matter (checkout, forms, logins), then read the log.
- If it's clean, switch live. If something breaks, switch back. Changing the PHP version is reversible.
Over SSH, WP-CLI can confirm which PHP version a site is actually running and show recent errors:
# Show the PHP version this site is running
wp eval 'echo PHP_VERSION . PHP_EOL;'
# List plugins with available updates before you switch
wp plugin list --update=available --fields=name,version,update_version
# Read the last 50 lines of the WordPress debug log (if WP_DEBUG_LOG is on)
tail -n 50 wp-content/debug.logUpdating plugins first is the step people skip. A lot of "PHP 8.5 broke my site" problems are really "this plugin was two versions behind."
If you're on PHP 8.2: It's in security-only support now and reaches end of life on 31 December 2026, which is three months away. If you're still on 8.2, plan the move to 8.4 this quarter rather than in December.
Staging now sits next to your live site
Last month we launched staging sites. This month they're easier to keep track of.
A staging copy now appears directly under its live site on the Sites page, with its own status and how much time it has left. Inside a staging copy, a notice tells you you're on staging, and Manage Live takes you back to the live site in one click. The site switcher and sidebar both mark staging clearly too.
This sounds small, but it fixes a real risk. When a staging copy and a live site look the same in the dashboard, it's easy to make a change on the wrong one: clearing the cache, changing a setting, or deleting a plugin on live when you meant to do it on staging. Clear labels at every level make that mistake a lot harder. The staging docs cover creating a copy and pushing it live.
Search anywhere with ⌘K
Press ⌘K on a Mac (Ctrl+K on Windows and Linux) from any page in the dashboard, or click Search in the header, and type where you want to go.
Two things make it more useful than a page list. First, you can type part of a domain to jump between sites, which helps a lot once you have more than a handful. Second, you search for what something is called, not which page it lives on. Type Magic Login, ionCube or Fix Site and you land on the right page with the right tab already open. As the dashboard has grown and more tools moved into tabs, this saves remembering where each one ended up.
Always the latest WordPress on new sites
New sites are always installed on the current WordPress release, and the version field on the create form now just shows Latest. There's no reason to start a new site on an older version, and an old version on day one only means an update to run on day two.
Clearer password and 2FA screens
The sign-in screens got a round of small fixes that remove friction:
- Password rules now show as you type, instead of after you submit and get rejected.
- Accounts created with Google can now set a password, so you have a second way in if you ever lose access to that Google account.
- Two-factor authentication errors now say what went wrong, instead of leaving the spinner running.
Fixes: PHP notices no longer break Magic Login or dashboard pages
Two fixes this month have the same cause. Some plugins, Elementor among them, write PHP notices to the log as they run. Notices aren't errors. The site keeps working. But that notice text was getting mixed into the output our dashboard reads from your site.
- Magic Login on sites running Elementor. The notice could end up attached to your Magic Login link, which then didn't work. We now pull out only the link itself.
- Plugins, Themes, WP Settings, Debug and Redis pages on busy sites. The same notices could stop these pages loading. They now load whatever your plugins write to the log.
If Magic Login or one of those pages failed for you on a site with Elementor or another chatty plugin, try it again. No change is needed on your side.
Security: Google sign-in only joins a confirmed account
Signing in with Google now connects to an existing MagicWP account only after that account's email address has been confirmed.
Here's why that matters. Without this rule, someone could sign up with your email address and a password of their choosing, never confirm it, and wait. If you later signed in with Google using that same address, your Google sign-in could be joined to the account they created, and they'd still have their password. Requiring a confirmed email before linking closes that gap. The person who controls the email address is the one who owns the account.
This was part of a wider round of security hardening across sign-in and billing this month.
Frequently Asked Questions
Can I try MagicWP before I pay?
Yes. You can create a temporary site, which is a real WordPress site on the same platform paying customers use, before choosing a plan. The screen shows how long it will run before you create it, and we email you before it stops. If you choose a plan while it's running, you keep that exact site with the same address and content. If time runs out, it's stopped first and removed later, so there's still a window to pick a plan and get it back.
What happens to my temporary site when I choose a plan?
It stays exactly as it is. The address, content, theme and plugins all carry over, so there's nothing to export, migrate or rebuild. That's the point of building on a temporary site rather than a separate demo: the work you do while trying MagicWP becomes your real site the moment you pick a plan.
Are templates free?
Yes. Start from a Template is free on every plan and also works on temporary sites. Each template comes with its content, theme and plugins in place, and you can preview a live demo on desktop and mobile first. We update WordPress, the theme and the plugins before handing the site over, so you don't start with outdated software.
Why can't I pick some PHP versions when I use a template?
Some templates rely on themes or plugins that don't run on every PHP version. Rather than let you build a site that won't work, the create form greys out any PHP version the chosen template can't run on. Pick one of the versions still available, and you can change PHP later from the site's settings once you've checked your plugins support the newer version.
Should I switch my site to PHP 8.5?
Only once your theme and plugins support it, or after testing. WordPress core fully supports PHP 8.5 from version 6.9, but plugins and themes often lag behind a new PHP release. That's why new sites default to PHP 8.4, which we recommend for most sites. Back up first, test on a staging copy or temporary site, update your plugins, check the debug log, and switch back if anything breaks.
What happens to sites on PHP 8.0 or 8.1?
PHP 8.0 and 8.1 are past end of life and no longer appear in the version list, so new sites can't choose them. Both versions stopped getting security fixes from the PHP project, which means any new PHP security bug stays open on them. If one of your sites is still on 8.0 or 8.1, move it to 8.4 after testing on staging.
How do I use dashboard search?
Press ⌘K on a Mac or Ctrl+K on Windows and Linux from any dashboard page, or click Search in the header. Type part of a domain to jump to a site, or type the name of a tool such as Magic Login, ionCube or Fix Site to land on the right page with the right tab open.
Magic Login wasn't working on my Elementor site. Is it fixed?
Yes. On sites with plugins that log PHP notices, like Elementor, the notice text could get attached to the Magic Login link and break it. We now extract only the link. The same fix applies to the Plugins, Themes, WP Settings, Debug and Redis pages, which could fail to load for the same reason. You don't need to change anything; just try again.
Wrapping up
This release makes the start easier and the middle safer. Temporary sites let you test MagicWP on a real WordPress site and keep it when you pick a plan. Templates and Advanced Mode mean the first site you open is close to the one you wanted, not an empty install. For existing sites, PHP 8.5 is ready when your plugins are, PHP 8.4 is the sensible default, and clearer staging labels and ⌘K search make day-to-day work quicker.
If you're still on PHP 8.2 or older, that's the one thing worth doing this quarter: test on staging and move to 8.4. And if you haven't tried MagicWP yet, a temporary site is the easiest way to see how it handles your theme and plugins. See the plans when you're ready to keep it.
Get the best of MagicWP in your inbox.
Monthly engineering notes, product updates, and WordPress performance tips. No spam, unsubscribe anytime.

