Add a WordPress site

Most applications on strackt arrive as a git repository you push commits to. WordPress is the exception: a WordPress site is created straight from the Applications screen, with no repository to point at.

You need a connected server first. If you don't have one yet, start with Connect a server.

Two ways to start

When you add an application and choose WordPress, you pick one of two starting points:

• Start fresh — a new, empty WordPress site, ready to log into and build.
• Import an existing site — upload an export of a site you already run, and strackt brings it up as a managed site.

Either way strackt sets up everything the site needs — the WordPress runtime, its database, its cache, and its public address — as a single application. You don't add those separately.

Starting fresh

Choose WordPress, choose Start fresh, pick the server, and confirm. strackt provisions the site and deploys it. When it finishes, the application page gives you a link into the WordPress admin.

From there it's an ordinary WordPress install: your themes, your plugins, your content.

Importing a site you already run

Choose Import an existing site and upload an export. strackt accepts:

• All-in-One WP Migration archives (.wpress), as long as they aren't encrypted
• Duplicator packages
• A plain ZIP containing your site files and a single SQL dump at the top level
• A restore point exported from strackt — so a site you've downloaded from one strackt site can be uploaded to create another

Large files upload in chunks, so a slow or interrupted connection resumes rather than starting over.

Check the summary before you commit

Before anything is copied, strackt reads the archive and shows you what it found: the format, the address the site is currently served from, the WordPress version, the plugins and themes inside it, and how large the database and files are.

Read that summary. It's derived from the archive itself rather than from anything the export claims about itself, so it's the most reliable picture of what you're about to bring across.

What won't import

Some archives are refused rather than half-imported:

• Encrypted .wpress archives — export again without encryption
• Multisite networks
• Archives missing the database information strackt needs to place the site correctly
• Archives containing unsafe or duplicated file paths

If an archive is refused, nothing from it is copied and the site is never deployed. The application itself has already been created by that point, though, so you'll find it waiting in your Applications list — fix the export and retry the import there, or delete the application if you'd rather start over.

After the import

strackt imports the database, moves the site to its new address, keeps your existing table names, and checks the result. Then it:

• runs health checks against the site,
• creates a restore point called Imported site, so you can get back to exactly this state, and
• takes an inventory of your plugins and themes, which is what keeping WordPress updated runs on.

Imported copies are muted on purpose

If the site you imported is still running somewhere else, you now have a copy — and a copy that behaves like the original causes real damage. It can email the original site's customers, and it can compete with the original in search results.

So when the imported site's address differs from the address it came from, strackt installs a small plugin that stops WordPress sending email and tells search engines not to index it. Your content, themes, and plugins are untouched; only those two behaviours change.

One limit worth knowing, because this is a safety net rather than a guarantee. It works by intercepting WordPress's own mail function, so a plugin that sends through its own service — an SMTP or transactional-email plugin calling an API directly — can still get mail out. If the original site is one you must not duplicate mail from, disable its mail-sending plugins on the copy as well rather than relying on this alone.

This is deliberate and it does not expire. When you're ready for the copy to behave like a real site — usually once you've pointed your domain at it and you're no longer running the original — remove the strackt-clone-safety plugin from the site's must-use plugins. There is no switch for this in strackt; the site is yours and the decision is yours.

If the imported site's address matches where it came from, you're restoring rather than copying, and nothing is muted.

How WordPress deploys differ

A managed WordPress site is operated, not pushed. That means a few things you'd see on a repository-based application aren't offered here:

• No deploy-on-push, because there's no repository to push to
• No preview environments per pull request
• No zero-downtime releases, no release history to roll back through

Instead, your safety net is restore points. A restore point is taken before any plugin, theme, or core update strackt applies for you, and you can return to it in one step. An import works the other way round: the first restore point, Imported site, is created once the site has landed successfully.

Your site also gets a page cache. Visitors who aren't logged in are served a cached page; anyone signed in to WordPress bypasses the cache and always sees the live response.

From here

• Point your domain at the site with Domains and SSL
• Set up restore points and check your backups
• Let strackt handle plugin and theme updates — Keep WordPress updated