Custom Domains and HTTPS Support in WordPress Studio ![rw-book-cover](https://readwise-assets.s3.amazonaws.com/static/images/article0.00998d930354.png) 🔗 **Source:** [Custom Domains and HTTPS Support in WordPress Studio](https://www.youtube.com/watch?v=9XcfNpe_H2M) > [!note]+ Document Notes > tags: [wordpress, local-development, https-certificates, developer-tools, custom-domains] > author: Nick > source: WordPress.com > reference: https://www.youtube.com/watch?v=9XcfNpe_H2M > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > # 🏷️ Title: Custom Domains and HTTPS Support in WordPress Studio > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [WordPress Studio](https://developer.wordpress.com/studio/) — the free, open-source local development tool featured in the video. - Linked in the video description (not transcribed): Studio download and documentation. ## 📝 Summary - Nick, on the WordPress.com channel, walks through two Studio features: custom local domains and HTTPS for local sites. - It matters because the default `localhost` URLs are hard to remember and run over plain HTTP, which doesn't resemble production. HTTPS support produces secure local connections closer to a real environment. - Key stakeholders: WordPress plugin/theme developers and site builders who use Studio for local work, plus the WordPress.com team that ships the tool. - Risks and tradeoffs: custom domains must end in `.local` and be unique per site; enabling them modifies the system hosts file (requires admin password); on Mac the generated root certificate must be trusted manually in Keychain Access or browsers throw warnings. - Bottom line: flip two checkboxes (use custom domain + enable HTTPS), authorize the hosts-file change, and on Mac trust the `Studio-CA.crt` certificate. You get a memorable, secure local URL. ## 📖 Main Content - Studio is a local development tool that spins up WordPress sites on your own machine for plugin development, theme development, or building full sites. The demo starts from a site called "Encore." - By default a new Studio site uses a `localhost` URL over HTTP. Two reasons to change that: a custom domain is easier to remember, and HTTPS more closely mimics production. - To upgrade an existing site: click **edit site**, check **use custom domain**, set the domain, check **enable HTTPS**, then save. - To create a new site with both: click **add site**, name it (demo name "Push to Prod"), toggle **advanced settings**, check **use custom domain**, pick a domain, check **enable HTTPS**, then **add site**. - Caveat on domains: the custom domain must end in `.local`, and you can't reuse a `.local` domain already assigned to another Studio site. - On **add site** you're prompted for your computer password. This grants Studio permission to modify the system hosts file, which all custom domains need. The flow differs slightly on Windows vs. Mac (demo is on Mac). - For HTTPS, Studio generates a root certificate authority. Windows installs it automatically; Mac requires manual install to avoid browser warnings. - The manual Mac path: opening the site in Chrome shows "your connection is not private." Click the provided link to open Finder at the cert file `Studio-CA.crt`. Double-click to install (password prompt), then in Keychain Access find "WordPress Studio CA Certificate," open it, expand the Trust section, set **Secure Sockets Layer (SSL)** to **Always Trust**, and close (another password prompt). - After trusting, reopen the site — no warnings, connection secure, certificate valid, and WP Admin loads. If a warning persists, clear browser cache or, rarely, restart the browser. - Uncertainty: the video shows only the Mac flow in detail; the Windows steps are asserted to be automatic but not demonstrated. ### 🗒️ Notes #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=9XcfNpe_H2M?t=0) Intro and what Studio is - Host is Nick; series covers Studio features. - Studio is a local development tool for WordPress: spin up sites locally for plugin/theme development or full websites. #### ⏱️ [00:00:45](https://www.youtube.com/watch?v=9XcfNpe_H2M?t=45) Why custom domains and HTTPS - New sites default to a `localhost` URL. - Custom domains are easier to remember; default URLs use plain HTTP. - "HTTPS support in Studio though allows you to create sites with secure connections that more closely resemble production environments." #### ⏱️ [00:01:30](https://www.youtube.com/watch?v=9XcfNpe_H2M?t=90) Editing an existing site - Click edit site → check use custom domain → set domain → check enable HTTPS → save. #### ⏱️ [00:02:00](https://www.youtube.com/watch?v=9XcfNpe_H2M?t=120) Creating a new site with custom domain + HTTPS - Add site → name "Push to Prod" → toggle advanced settings → use custom domain → enable HTTPS → add site. - Caveat: "it needs to end in local" and don't reuse a `.local` domain from another Studio site. #### ⏱️ [00:02:50](https://www.youtube.com/watch?v=9XcfNpe_H2M?t=170) Hosts file permission - Password prompt grants Studio permission to modify the system hosts file, needed for all custom domains. - Windows flow looks slightly different from Mac. #### ⏱️ [00:03:20](https://www.youtube.com/watch?v=9XcfNpe_H2M?t=200) Root certificate authority - Studio generates a root CA for HTTPS. - Windows: auto-installed. Mac: manual install required to avoid browser warnings. - Chrome shows "your connection is not private." #### ⏱️ [00:04:00](https://www.youtube.com/watch?v=9XcfNpe_H2M?t=240) Trusting the certificate on Mac - Click the in-app link to open Finder at the cert: `Studio-CA.crt`. - Double-click to install (password prompt) → cert added to Keychain Access. - Find "WordPress Studio CA Certificate," open, expand Trust, set SSL to Always Trust, close (password prompt). #### ⏱️ [00:05:10](https://www.youtube.com/watch?v=9XcfNpe_H2M?t=310) Verify and wrap-up - Reopen site: no warnings, secure connection, valid certificate, WP Admin loads. - Persistent warning fix: clear browser cache or restart browser. - Studio is free and open source; link in the description; call to subscribe. ## 📚 References - [WordPress Studio](https://developer.wordpress.com/studio/) — official product page for the local development tool. - [WordPress.com on YouTube](https://www.youtube.com/@WordPressdotcom) — publishing channel. ## 🗣️ Paraphrase - Studio runs WordPress locally for development, and new sites start on a plain `localhost` HTTP URL. You can swap that for a memorable custom domain and turn on HTTPS so local work behaves more like production. - Toggle the two options when editing or creating a site. The domain has to end in `.local` and be unique. Studio edits your hosts file (needs your password) and generates a root certificate. - On Windows the certificate installs itself; on Mac you trust it by hand in Keychain Access, setting SSL to Always Trust. After that the browser stops warning and the connection reads as secure. ## 📰 Newsletter - Developing WordPress locally and tired of squinting at `localhost`? The WordPress.com team's latest Studio walkthrough shows how to give every local site a tidy `.local` domain and a real HTTPS padlock. It's two checkboxes plus a quick Keychain trust step on Mac (Windows handles the cert for you). Closer-to-production local sites, free and open source. Worth a watch if Studio is your local stack. ## ✅ Action Items #### DevRel - Developer advocacy: N/A — this is vendor product content, no advocacy plan to action. - Education: produce a companion written quickstart mirroring the Mac/Windows cert-trust split. - Developer experience: N/A — DX is the subject, not a task here. - Developer marketing: N/A. - Community management: N/A. - Internal/external/cross-project: N/A. #### OSPO - Policy & Governance: N/A — no governance question raised. - License Compliance: note Studio is free and open source; verify license if redistributing docs. - Security Management: document the trust-this-root-CA step as a security consideration (a trusted local CA widens trust scope). - Software Inventory: N/A. - Developer Support: N/A. - Community Engagement: N/A. - Strategic Alignment: N/A. #### Community - Maintainers: N/A. - Contributors: N/A. - Sponsors: N/A. - Ecosystem: N/A. #### WordPress - Core: N/A. - Core Performance: N/A. - Core AI: N/A. - **Core Program Team:** N/A. - Mobile: N/A. - Playground: contrast Studio's local HTTPS workflow with Playground's browser-based model for an education module. - Community: N/A. - Training: add a Learn WordPress lesson on local HTTPS and custom domains using Studio. - Marketing: N/A. - Support: pre-write a support note for the "connection is not private" warning and the cache-clear fix. - Design: N/A. - Documentation: ensure the cert-trust steps and the `.local` uniqueness caveat are in DevHub docs. - Photos: N/A. - TV: caption this video and index under local development. - Polyglots: N/A. - Accessibility: N/A. - Meta: N/A. - CLI: N/A. - Hosting: N/A. - Tide: N/A. - Openverse: N/A. - Themes: N/A. - Plugins: N/A. #### The WPCC - Programs: N/A. - Projects: N/A. - Funding experiments: N/A. ### FAIR - Technical independence: N/A — not relevant to this tutorial. - Policies and covenants: N/A. - Productized governance artifacts: N/A. ## 🧪 Hypotheses - Developers who set custom `.local` domains report higher recall of their site URLs than those on `localhost`. - Local HTTPS surfaces mixed-content and protocol-relative bugs earlier than plain HTTP local environments. - The manual Mac certificate-trust step is the most common point of confusion or support contact for this feature. - Windows users complete the HTTPS setup faster than Mac users because cert install is automatic. - A non-trivial share of "connection is not private" complaints resolve purely by clearing browser cache. ### 📊 Methodology - Instrument Studio (with consent) to log domain type and HTTPS toggles; correlate with task-completion telemetry. - A/B usability study: Mac vs. Windows cohorts timed through first successful HTTPS site load. - Mine support tickets and forum threads for the certificate-trust step and the cache-clear fix frequency. - Controlled bug-detection task: same project on HTTP-local vs. HTTPS-local, count protocol-related defects caught. ### ❓ Questions - What exactly differs in the Windows flow that the video skips? - Does Studio scope the generated root CA narrowly, and how is it revoked or rotated? - What happens if two developers on one machine both want the same `.local` domain? - Can the Mac trust step be automated safely, or is the manual gate intentional for security? ### 🔮 Future Research - Compare Studio's local-HTTPS approach to mkcert and other local-CA tools for security and friction. - Study whether closer production parity (HTTPS, custom domains) measurably reduces deploy-time surprises. ### 💡 Implications - Practice: lowers the friction of realistic local testing, nudging developers toward HTTPS-by-default habits. - Security: trusting a tool-generated root CA expands a developer's trust surface; teams should understand and document this. - Education: a clean teaching example of hosts-file editing, certificate authorities, and OS trust stores. - Funding models: reinforces WordPress.com's open-source tooling as a developer-acquisition channel. ### 🧠 Learning Styles Assessment - Reading level estimate: roughly Flesch-Kincaid grade 8–9 — conversational, short clauses, light jargon (hosts file, root certificate authority, SSL). #### 👀 Visual learners - Present: screen recording of the actual UI, modals, Finder, and Keychain Access. - Improve: add a labeled diagram of the cert-trust flow and a Mac-vs-Windows branch chart. #### 🔊 Aural learners - Present: clear narration throughout. - Improve: offer a 2–3 minute audio recap and downloadable speaker notes. #### 🗣️ Verbal learners - Present: terms named in context (hosts file, root CA, SSL Always Trust). - Improve: a short glossary defining certificate authority and `.local` TLD. #### 🧩 Kinesthetic learners - Present: a literal step-by-step you can follow along with live. - Improve: a printable checklist and a sample repo to practice on. #### 🧠 Logical learners - Present: ordered cause-and-effect (toggle → hosts edit → cert → trust → secure). - Improve: a decision tree for "still seeing a warning?" troubleshooting. #### 🧑‍🤝‍🧑 Social learners - Present: invitation to subscribe and engage on YouTube. - Improve: link a community thread or office-hours for setup questions. #### 🧘‍♀️ Solitary learners - Present: self-paced video format. - Improve: a self-check ("can you reach WP Admin over HTTPS?") milestone list. #### 🌿 Naturalistic learners - Present: N/A — no environmental framing in this tutorial. - Improve: N/A — not a natural fit; forcing it would be artificial. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: N/A — video medium; semantics depend on the YouTube page, not transcribed. - Improve: ensure the description and any companion article use proper headings and alt text. #### Keyboard navigation - Present: N/A — not assessable from transcript. - Improve: document keyboard paths through Studio's modals in written docs. #### Contrast and readability - Present: N/A — cannot verify on-screen contrast from transcript. - Improve: confirm Studio UI and captions meet 4.5:1. #### Text resizing and reflow - Present: N/A — not assessable from transcript. - Improve: verify Studio UI reflows at 200% zoom. #### Media and captions - Present: spoken narration; YouTube auto-captions likely. - Improve: ship human-reviewed captions and a downloadable transcript (this analysis derives from one). #### Forms and interactions - Present: checkboxes and modals described verbally. - Improve: confirm Studio's form fields have visible labels and clear error states. #### Standards reference - Map gaps to WCAG 2.2 AA: 1.2.2 Captions, 1.4.3 Contrast, 1.4.10 Reflow, 3.3.2 Labels — all unverifiable here and worth a dedicated audit. ### 🌍 DEIB Assessment #### Cultural breadth - Present: covers both Mac and Windows users, broadening reach. - Improve: add Linux guidance and note non-English Studio locales if available. #### Inclusive language - Present: plain, neutral language; no idioms that block comprehension. - Improve: define jargon (root CA, hosts file) inline for newcomers. #### Neurodiversity support - Present: consistent, chunked, sequential steps. - Improve: add explicit step numbers and a recap checklist for working memory support. #### Representation - Present: N/A — single presenter; no representation claims to assess. - Improve: N/A. #### Psychological safety - Present: reassuring tone ("if you do still see the warning…"), normalizes the error state. - Improve: explicitly reassure that trusting the cert is safe and reversible. ### ✅ Logical Validity #### Strong reasoning - Causal: the claim that HTTPS "more closely resemble[s] production environments" is sound — production is HTTPS, so matching it locally reduces environment drift. - Procedural/deductive: the trust-the-cert sequence is a valid step chain; each step's output is the next step's precondition (install → locate in Keychain → set Always Trust → reload). - To clarify further: state explicitly why an untrusted self-generated CA triggers the browser warning. #### Fallacies - No notable fallacy. Mild appeal to authority/popularity near the end: "It is my preferred way to develop locally" — a personal endorsement, not evidence. Fix: pair the preference with a concrete reason (e.g., speed or parity). #### Tone of voice - Friendly, instructional, lightly informal ("so let's dive in," "sure enough, we have no more browser warnings"). Confident and encouraging. ### 🛡️ DARVO Analysis - Deny: N/A — no accusation present; nothing is denied or minimized. - Attack: N/A — no accusers or credibility targets; it's a neutral product tutorial. - Reverse victim/offender: N/A — no conflict framing of any kind. - Emotional cues/rhetoric: only mild persuasion (subscribe, "greatly appreciated") — standard creator CTA, not DARVO. ## 🎯 Conclusion - Bottom line: Studio lets you give local WordPress sites a memorable `.local` domain and real HTTPS by toggling two options; Studio edits the hosts file (password required) and generates a root CA — auto-trusted on Windows, manually trusted on Mac via Keychain Access. - Next steps for readers: install or open Studio, try a new site with both options, and on Mac walk the `Studio-CA.crt` → Keychain → SSL Always Trust path. If a warning lingers, clear the browser cache. Then verify WP Admin loads over HTTPS. ## 🔄 Refactor Appendix — Custom Domains and HTTPS Support in WordPress Studio > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### [H1] Local HTTPS makes dev sites resemble production > [!quote] ID:rw_h1 > create sites with secure connections that more closely resemble production environments **Context & use**: - ~00:00:55 — the stated rationale for enabling HTTPS on local sites. - Justifies HTTPS-by-default locally: matching production reduces environment drift and protocol-related surprises at deploy. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H2] Studio custom domains must end in .local > [!quote] ID:rw_h2 > it needs to end in local and also don't use it DOT local domain you've already set up **Context & use**: - ~00:02:30 — the caveat when choosing a custom domain for a new Studio site. - Practical constraint: domain must use the `.local` TLD and be unique across Studio sites, or hosts-file/routing collisions occur. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Local environments should mirror production protocol **Claim** (one sentence, Courtney's voice): A local development environment earns its keep by matching production's protocol and URL shape, so HTTPS and real domains belong locally, not just in production. **Evidence pointer**: [[#H1]] **Scope & conditions**: Holds for web apps where HTTPS-only behavior (secure cookies, mixed-content rules, HSTS) affects functionality; breaks when local parity costs more setup friction than the bugs it prevents. **Links**: - [[Local development tooling]] — because applies-in WordPress Studio - [[Environment parity]] — because extends the dev/prod parity principle <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Check how Studio scopes/rotates its generated root CA for security hygiene — https://www.youtube.com/watch?v=9XcfNpe_H2M #fleeting #inbox - [F2] Find the documented Windows cert-install flow the video skips — https://developer.wordpress.com/studio/ #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Try a new Studio site with a `.local` domain + HTTPS and trust the cert on Mac — local-dev #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Custom Domains and HTTPS Support in WordPress Studio.md|Custom Domains and HTTPS Support in WordPress Studio by WordPress.com]] ## Highlights - And you can see that the local URL is set to local host. Now this is the default configuration whenever you create a brand new Studio site. However, there are plenty of reasons why you might want use a custom domain instead, even if it's just to make the site URL a little bit easier to remember these default local host URLs also use http HTTPs, which doesn't always make for the most realistic development experience. HTTPS support in Studio though allows you to create sites with secure connections that more closely resemble production environments. ([View Highlight](https://read.readwise.io/read/01kw2n0tmm0xgr0bk7af8hd1xb)) - Note: The rationale for HTTPS-on-local: secure connections that more closely resemble production, reducing dev/prod drift. - Tags: https-certificates, atom/literature/h1 - Then toggle advanced settings and then use custom domain. We're gonna check that here, just like we saw before. Then you can choose any custom domain you want, but there is a caveat it needs to end in local and also don't use it DOT local domain you've already set up on another Studio site. Finally, let's check Enable HTTPS if you want Secure Connections. ([View Highlight](https://read.readwise.io/read/01kw2n0xb2feh6gz3ab14vqxng)) - Note: The custom-domain caveat: must end in .local and be unique across your Studio sites. - Tags: atom/literature/h2, custom-domains ## Links - [[Emulated Local Dev Trades Production Fidelity for Zero-Setup Speed]] — contrasts: local HTTPS improves fidelity while the `.local` domain and generated certificate preserve meaningful differences from production. - [[Environment Aliases Identify Targets, Not Authority]] — applies-in: a memorable local hostname identifies an environment but doesn't determine what deployment actions are safe.