Customize Studio site URL

[sejas]

Related issues

• Fixes https://github.com/Automattic/dotcom-forge/issues/9783

Proposed Changes

• Allow editing Studio site url
• Use the URL set by the user when starting the site

Testing Instructions

Localhost domain

• Access the settings tab
• Find the URL field
• Click on Edit
• Change the URL to whatever.localhost and leave the checkbox unchecked
• Try accessing the site
• Confirm everything works as expected

Tunneling with Ngrok

• Install ngrok in your machine
• run ngrok http 8885 where 8885 is the port of the site that you want to expose to internet
• Access the settings tab
• Find the URL field
• Click on Edit
• Change the URL to Ngrok URL and mark the skip port checkbox
• Navigate to ngrok url , access wp-admin and confirm everything works as expected.

studio-jetpack.mp4

Note

The warning about dns_get_record is returned by Playground WASM on purpose. See https://github.com/Automattic/dotcom-forge/issues/10427

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[wojtekn]

Nice approach @sejas !

What if we added some affordance to help the user to set up the host? It could be another field below that auto-generates based on the first field value:

Hosts file entry
[127.0.0.1 custom.local] [copy]
To ensure proper functionality, add the above entry to your system's host file. Learn more

I know it's a draft, but I gave it an early test. I changed my site's URL to http://custom.local/ and added 127.0.0.1 custom.local entry to the host file, but I couldn't make it work yet.

[matt-west]

Nice! I’m glad we're adding this. 🙌

I agree with @wojtek that we should add some help content under the field if we’re not able to update the hosts files for users at this stage. Perhaps we could tailor the instructions based on whether the user is running on Windows, Mac, or Linux so they don’t have to exist Studio and read a help doc.

I’d love to add this field to the site creation form too. We should wait until we can automatically update the users hosts file before doing that though. Needing to do that manually will catch a lot of people out, even if we present instructions on how to do it.

[wojtekn]

Thanks for chiming in!

Perhaps we could tailor the instructions based on whether the user is running on Windows, Mac, or Linux so they don’t have to exist Studio and read a help doc.

Some users may already know how to do that or use a tool like SwitchHosts. Also, there are multiple ways to do those in both systems, and those can change over time, so I think it would be more manageable to provide a line they should add, a point to docs for detailed instructions which we could update always when needed.

[sejas]

Let’s see where this investigation leads.
Even if the user sets the site URL we won't solve the custom port, so users will need to modify hosts file to point mystudiosite.local, and then access http://mystudiosite.local:8881

My primary goal is to enable the use of tools like ngrok to activate plugins online such as Jetpack, rather than focusing specifically on custom domains. For custom domains it would be great to solve the problem of multiple sites running in the same port.

Thanks for the feedback! I'll add that information in the settings tab 👌.

[sejas]

@matt-west , @wojtekn , here is what we can currently achieve with this PR:

RL4BnA.mov

[sejas]

@wojtekn , @matt-west , Could I get some help with the design and feature?
I think if we want to support editing the hostname, this should be the approach.
In the future we could try to use the same port, ideally 80 or 443 for all sites and use a localhost TLD which works out of the box without any configuration on /etc/hosts .

[wojtekn]

@sejas, what if we go with the following changes:

• Remove /etc/hosts edit helpers if they are not needed when .localhost is used
• Add a label between "Hostname" and the field saying, "If you're using a TLD other than .localhost, you may need to update your hosts file. Learn more."
• Change "Final URL" to "Your site URL"
• Change "Include port in URL" to "Include port in URL (Required locally. Disable for external routing like Ngrok)"

It's still not ideal, but I think it shows the intentions clearer.

[sejas]

@wojtekn , I've created this alternative PR where we don't need any UI and we automatically detect the hostname in the request. #858
I think it's the way to go, we just need to test it with other sites to confirm it doesn't break anything.

[wojtekn]

We've reviewed the state with @sejas and identified one more change we would make at this point:

• Change "Include port in URL" to "Skip port in URL" and "Skip the port to use external routing like Ngrok" and make the checkbox unchecked

We will also need:

• Test push/pull/import flows to confirm they handle URL change correctly
• Draft documentation changes to cover /etc/hosts changes required in some cases, and Ngrok usage for Jetpack development
• Fix tests and review the pass the PR

[sejas]

@wojtekn , changed!

[ivan-ottinger]

Very nice! This a great feature/setting addition! The proposed changes look good and work as expected. 👌🏼🙂

I haven't tested with Ngrok yet, but would like to share a couple ideas that came to my mind while testing and reviewing the PR with localhost domain already:

---

Have we considered adding automatic search/replace for the site's content - to replace all old URLs in the content with the new one?

Alternatively, we could consider adding one more checkbox to let the user decide whether they would like to have their site content updated as well. If not, we could consider adding short sentence to the modal, e.g. "Please note that this changes the site URL only. URLs in the site database will be unaffected."

---

I think we could consider preventing the user from updating the site URL to an address that includes unexpected characters. At the moment, it is possible to update the URL to something like http://localhost23423FF9o£$@£$@£$ for instance and then the site doesn't load of course.

---

I left one minor comment below as well.

[ivan-ottinger]

When it comes to the user-facing documentation section that will be linked to from this Learn more link, is this something we are planning to add before the release?

[wojtekn]

Yes, we will have a section there and will update the link to the correct one before we release Studio.

[wojtekn]

Have we considered adding automatic search/replace for the site's content - to replace all old URLs in the content with the new one?

Alternatively, we could consider adding one more checkbox to let the user decide whether they would like to have their site content updated as well. If not, we could consider adding short sentence to the modal, e.g. "Please note that this changes the site URL only. URLs in the site database will be unaffected."

Let's leave those to users for now, and we will cover that in the documentation, too.

[wojtekn]

Closing in favor of #936