Changing Your Site Address (Domain)

When you move a website to a new domain — or switch a staging URL over to the real one — the CMS needs to know its new address so every generated link, email, sitemap entry, and structured-data reference points at the right place. WebProCMS does this in one action from Dashboard → Tools → Site Address, or with the cms:set-site-url command.

Why a one-click tool exists

The site address lives in the APP_URL setting, but changing it in isolation isn't enough. The old domain lingers in three separate cache layers, so the live site keeps emitting the previous address until each one is flushed:

The config cache — a cached copy of APP_URL (and the storage-disk URL derived from it). A deploy can even re-cache the old value moments after an edit, silently reverting it.
The application cache — Cache::remember() values that baked absolute URLs into them (JSON-LD WebSite schema, media/video poster URLs, and similar).
The response cache — the stored HTML of every public page, rendered with the old domain.

The tool rewrites APP_URL and clears/rebuilds all three in the correct order, so the new address takes effect everywhere at once instead of leaving stale copies of the old domain scattered across the site.

What it does

Given a new URL, SiteUrlChanger:

Validates and canonicalises the URL — defaults the scheme to https, lowercases the host, drops any path/query and trailing slash, keeps an explicit port.
Rewrites .env — replaces the APP_URL line (appending it if missing) while preserving every other line, comment, and the file's line endings. Optionally re-homes MAIL_FROM_ADDRESS on the new domain (e.g. [email protected] → [email protected]).
Refreshes the running config so anything later in the same request already sees the new URL (including the public storage-disk URL).
Clears the caches — config:clear, cache:clear, the response cache, and recompiles the page-data sidecars. If config was cached, it rebuilds the cache from the updated .env rather than leaving it uncached.

Using it — dashboard

Dashboard → Tools → Site Address:

Enter the new address (e.g. https://example.com).
Optionally tick "Also update the email 'from' address to match the new domain."
Click Change Address and confirm.

The caches are cleared in the background, so the request returns immediately.

Using it — command line

php artisan cms:set-site-url https://example.com

# also update the email from-address, re-homed on the new domain:
php artisan cms:set-site-url https://example.com --mail-from=auto

# or set an explicit from-address:
php artisan cms:set-site-url https://example.com [email protected]

# skip recompiling page-data sidecars (rarely needed):
php artisan cms:set-site-url https://example.com --no-recompile

What it does not do

This tool changes how the application refers to itself. It does not touch anything outside the app:

DNS — pointing the domain at your server is done at your DNS provider.
SSL certificate — issue/renew the cert for the new domain through your host or CDN.
Web-server domain binding — add the domain to your host's site/vhost configuration.

Run this tool after the new domain already resolves to your server, so the address it writes matches where visitors actually land.

Notes

You may need to sign back in. Session cookies are scoped to a domain, so if you switch to a different domain you'll re-authenticate on the new address. (Fixing only the scheme, or running the tool while already on the new domain, keeps you signed in.)
Deliverability. Changing the from-address to a new domain means that domain's SPF/DKIM/DMARC records must authorise your mail path, or messages may be filtered. This is a DNS concern, separate from the app.
Admin only. The Tools page is restricted to administrators.

Documentation