> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rocky.global/llms.txt
> Use this file to discover all available pages before exploring further.

# DOMAIN MIGRATION

# Domain migration: rocky.global → app.rocky.global

This document describes the risks of moving the main application domain from **rocky.global** to **app.rocky.global** and how to mitigate them using **301 permanent redirects**.

***

## 1. Risks

### 1.1 SEO and indexing

* **Risk:** Search engines have indexed **rocky.global**. Changing the domain without redirects causes:
  * Loss of rankings and organic traffic.
  * Old URLs return 404 or point to the wrong site.
* **Mitigation:** Redirect every URL from `rocky.global` (and `www.rocky.global`) to the same path on `app.rocky.global` with **HTTP 301 (Moved Permanently)**. Search engines transfer most of the “link equity” to the new URLs and update their index over time.

### 1.2 External links and bookmarks

* **Risk:** Third-party sites, emails, and user bookmarks point to `https://rocky.global/...`. Without redirects they break.
* **Mitigation:** Same 301 redirects: `https://rocky.global/path` → `https://app.rocky.global/path`. Links and bookmarks keep working.

### 1.3 Sessions and cookies

* **Risk:** Cookies are often set for the current host (`rocky.global`). After moving to `app.rocky.global`, existing cookies may not be sent, so users can be logged out.
* **Mitigation:**
  * Set `SESSION_DOMAIN=.rocky.global` in `.env` so cookies are valid for both `rocky.global` and `app.rocky.global` during and after migration (if you want shared session across subdomains).
  * Or accept a one-time logout: after 301, users land on `app.rocky.global` and log in again; new cookies will be for `app.rocky.global`.

### 1.4 Emails and callbacks

* **Risk:** Links in emails (password reset, order confirmation, etc.) and payment/API callbacks (e.g. Redsys) may use the old domain.
* **Mitigation:**
  * **APP\_URL:** Set `APP_URL=https://app.rocky.global` in `.env` so Laravel generates all new links with the new domain.
  * **301 redirects:** Any old link (e.g. `https://rocky.global/password/reset/...`) will redirect to `https://app.rocky.global/...`, so old emails and callbacks still work.
  * **Redsys / payment gateway:** Update notification and return URLs in the gateway dashboard to `https://app.rocky.global/...` when possible; redirects cover any remaining old URLs.

### 1.5 CORS and Sanctum

* **Risk:** If the frontend or API consumers use the domain in CORS or Sanctum’s stateful domains, the old domain may stop working.
* **Mitigation:**
  * Set `APP_URL=https://app.rocky.global`; Sanctum uses this for allowed hosts.
  * Keep 301 redirects so that requests to `rocky.global` are redirected to `app.rocky.global` before hitting the app; then CORS and Sanctum see the canonical host.

### 1.6 SSL/TLS

* **Risk:** Both `rocky.global` and `app.rocky.global` must have valid certificates. Redirects should use HTTPS on the new domain.
* **Mitigation:** Configure SSL for both domains (e.g. wildcard `*.rocky.global` or separate certs). The application redirects to `https://app.rocky.global`.

### 1.7 Hardcoded domain references

* **Risk:** Code or config that hardcodes `rocky.global` (e.g. support email, asset URLs) can point users to the wrong place.
* **Mitigation:** Use `config('app.url')` (and thus `APP_URL`) for the app’s base URL. Support email (`support@rocky.global`) can stay as is; it’s an email address, not the app domain. No change required unless you move support to e.g. `support@app.rocky.global`.

***

## 2. Redirect strategy (301)

### 2.1 Rules to implement

* Redirect **all** requests from the old host(s) to the same path (and query string) on the new host, with **301**:

| From                         | To                           |
| ---------------------------- | ---------------------------- |
| `http://rocky.global/*`      | `https://app.rocky.global/*` |
| `https://rocky.global/*`     | `https://app.rocky.global/*` |
| `http://www.rocky.global/*`  | `https://app.rocky.global/*` |
| `https://www.rocky.global/*` | `https://app.rocky.global/*` |

* Preserve path and query string (e.g. `/events/123/dashboard?tab=orders` → `https://app.rocky.global/events/123/dashboard?tab=orders`).
* Use **301** so search engines and clients treat the move as permanent and update caches/bookmarks.

### 2.2 Where redirects are implemented in this project

1. **Laravel middleware** (`App\Http\Middleware\RedirectOldDomain`):\
   Runs on every request. If the request host is one of the configured “old” domains (e.g. `rocky.global`, `www.rocky.global`), it returns a 301 to the same path/query on the canonical URL from `config('app.url')` (i.e. `APP_URL`).\
   This works regardless of web server (Apache, Nginx, load balancer).

2. **Optional: Apache `.htaccess`** (in `public/.htaccess`):\
   If the app is served by Apache and the old domain points to the same document root, you can **uncomment** the redirect block at the top of `public/.htaccess`. This redirects at the web server level (before PHP) and reduces load.\
   The middleware still handles any request that reaches Laravel (e.g. behind Nginx or a reverse proxy), so redirects work even if you do not use the `.htaccess` rules.

### 2.3 Configuration

* **`.env`**
  * `APP_URL=https://app.rocky.global`\
    This is the canonical application URL; all new links and the redirect target use it.
  * Optional: `REDIRECT_OLD_DOMAINS=rocky.global,www.rocky.global`\
    If not set, the middleware uses the default list in `config/domain.php` (see below).

* **`config/domain.php`** (optional)
  * `redirect_old_domains`: list of hosts that must be redirected to `APP_URL` with 301.

***

## 3. Checklist before and after cutover

**Before:**

* [ ] DNS: `app.rocky.global` points to the same application server (or load balancer).
* [ ] SSL certificate valid for `app.rocky.global` (and ideally for `rocky.global` and `www.rocky.global` for redirects).
* [ ] `.env`: `APP_URL=https://app.rocky.global`.
* [ ] `.env`: Optional `REDIRECT_OLD_DOMAINS=rocky.global,www.rocky.global` if you use custom list.
* [ ] Payment gateway / Redsys: Update notification and return URLs to `https://app.rocky.global/...` where possible (redirects still cover old URLs).
* [ ] Deploy middleware and (if used) `.htaccess` changes so 301s are active as soon as both domains hit the app.

**After:**

* [ ] Test: `https://rocky.global` and `https://rocky.global/any/path` return **301** and `Location: https://app.rocky.global/...`.
* [ ] Test: Login, password reset, and payment return URLs work via `app.rocky.global` and via old links (through redirect).
* [ ] Google Search Console: Add `https://app.rocky.global` as a property and, if needed, submit a change of address or sitemap for the new domain.
* [ ] Monitor logs and errors for broken links or callbacks still using the old domain; 301s should handle them transparently.

***

## 4. Summary

* **Risks:** SEO, broken links, sessions/cookies, emails/callbacks, CORS/Sanctum, SSL, hardcoded URLs.
* **Mitigation:** Use **301 redirects** from `rocky.global` and `www.rocky.global` to `app.rocky.global` (same path and query), set `APP_URL=https://app.rocky.global`, and optionally `SESSION_DOMAIN=.rocky.global` if you want shared cookies. Redirects are implemented in Laravel middleware (and optionally in Apache `.htaccess`).