> For the complete documentation index, see [llms.txt](https://docs.themeupstudio.com/crimson/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.themeupstudio.com/crimson/custom-pages/sign-in.md).

# Sign In

Crimson includes a dedicated **Sign in** page that works in two modes:

1. **Portal mode** (Ghost Portal popup) → controlled by the custom setting `use_portal_links`
2. **Custom form mode** (inline sign-in form) → uses Ghost’s members form attributes

It also includes a safety feature: **if a logged-in member visits `/signin/`, they are redirected to the Account page** using the correct mode.

<figure><img src="/files/k3x316upbcyGVnlemyVl" alt=""><figcaption><p>Sign In page in Crimson</p></figcaption></figure>

### How to create the Sign In page in Crimson?

To create Sign In page, you do not need to create anything inside Ghost. Just upload the `routes.yaml` file and Crimson will create the custom Sign In page.

{% hint style="success" %}
Read more about `routes.yaml` file at [Upload routes.yaml file](/crimson/getting-started/upload-routes.yaml-file.md)
{% endhint %}

***

### URL and route setup

For Sign In page, we have following `routes.yaml` configuration.

```yaml
routes:
  /signin/:
    template: signin
```

**What this does:**\
It tells Ghost that when someone opens `https://example.com/signin/`, Ghost should render `signin.hbs` as the template.

{% hint style="warning" %}
If you see a 404 on `/signin/`, the route is either missing, your `routes.yaml` hasn’t been uploaded, or Ghost hasn’t reloaded routes yet.
{% endhint %}

***

### How Ghost member sign-in works

Ghost member authentication is **passwordless**. Members sign in using an email-based flow (magic link) and can also use **one-time login codes** depending on how the form is configured.

Crimson supports both:

* **Portal sign-in** (popup UI handled by Ghost Portal)
* **Theme sign-in form** using `data-members-form="signin"`

***

### The key toggle: `@custom.use_portal_links`

Crimson’s `signin.hbs` checks the custom setting:

* **ON (`true`)** → use Portal screens (popup experience via `#/portal/...` and `data-portal` attributes)
* **OFF (`false`)** → use the custom inline sign-in form (`data-members-form="signin"`)

This lets you choose between a “Portal-first” site experience vs a “fully theme-styled” experience.

<figure><img src="/files/7jVXPjujm89Jo7F1RQOS" alt=""><figcaption><p>Sign In Page when Using Portal Links</p></figcaption></figure>

<figure><img src="/files/UfOQbqyAXrEis2hdwuSX" alt=""><figcaption><p>Sign In Portal Popup</p></figcaption></figure>

{% hint style="success" %}
See [Site-wide Settings](/crimson/custom-settings/site-wide-settings.md) for more details on changing `use_portal_links` setting.
{% endhint %}

***

### Behavior summary

<table><thead><tr><th>Visitor state</th><th width="100" align="right">use_portal_links</th><th>What they see on /signin/</th><th>What happens</th></tr></thead><tbody><tr><td><strong>Logged in</strong> (<code>@member</code> exists)</td><td align="right"><strong>ON</strong></td><td>Nothing (no page UI)</td><td>Immediate redirect to <code>{{@site.url}}/account/#/portal/account/</code></td></tr><tr><td><strong>Logged in</strong> (<code>@member</code> exists)</td><td align="right"><strong>OFF</strong></td><td>Nothing (no page UI)</td><td>Immediate redirect to <code>{{@site.url}}/account/</code></td></tr><tr><td><strong>Logged out</strong></td><td align="right"><strong>ON</strong></td><td>Sign-in heading + Sign in button + Sign up link</td><td>Page sets hash to <code>#/portal/signin/</code> to automatically open Portal sign-in</td></tr><tr><td><strong>Logged out</strong></td><td align="right"><strong>OFF</strong></td><td>Sign-in heading + Sign up link + inline email form</td><td>Ghost handles form submit and emails a magic link (+ one-time code if enabled)</td></tr></tbody></table>

<figure><img src="/files/ZpAFt3FG6438vrLHeza7" alt="" width="563"><figcaption></figcaption></figure>

***

### Recommended usage

#### Keep `use_portal_links` ON if you want:

* Portal popups for sign in/sign up/account
* A consistent Portal UI across the whole site
* Portal customization to apply everywhere (Portal settings + design)

#### Keep `use_portal_links` OFF if you want:

* A fully theme-designed sign-in experience (inline form)
* A “no popups” approach for authentication pages
* Direct control over layout and content on `/signin/`

***

### Troubleshooting

<details>

<summary><code>/signin/</code> shows 404</summary>

* Confirm the route exists in `routes.yaml`
* Upload `routes.yaml` again and restart/reload theme routes (especially on self-hosted)
* Ensure the template name matches exactly: `template: signin`

</details>

<details>

<summary>Portal doesn’t open when <code>use_portal_links</code> is ON</summary>

* Confirm Portal is enabled/configured in Ghost Admin (Portal links should work like `#/portal/...`)
* Confirm your theme includes `{{ghost_head}}` and `{{ghost_foot}}` in the right places (Portal scripts are normally injected by Ghost)

</details>

<details>

<summary>Sign-in emails aren’t being received</summary>

* Member sign-in requires working email delivery
* On self-hosted sites, ensure mail is configured (mail is one of the core required setup items).

</details>

***

### FAQs

<details>

<summary>If I turn OFF <code>use_portal_links</code>, do one-time codes still work?</summary>

Yes. Crimson's custom form explicitly enables them with `data-members-otc="true"`.

</details>

<details>

<summary>Why redirect logged-in users away from <code>/signin/</code>?</summary>

Because a signed-in member doesn’t need the sign-in screen. Crimson sends them straight to the Account experience (Portal account or theme account).

</details>

<details>

<summary>Can I change where logged-in users are redirected?</summary>

Yes — edit the two `<script>window.location = ...</script>` lines at the top of `signin.hbs` (just make sure the destination route exists to avoid loops).

</details>