It would be nice if we could set the router mode based on project instead of only one global setting.
Hi @davebeauchemin - thanks for the feature request. I’m interested in learning more about this use case. Can you explain how you would use this? Is there a reason you’d like some projects on localhost and others on a site domain?
Hi @austinwendt I’m currently working on 2 projects and the first project is a WP installation used only as a backend with WPGraphQL and the second project is a basic WP site. The problem is when I’m working on the headless wordpress, the request sent from the frontend (React Application in SSR with ApolloClient) needs to be sent to 127.0.0.1:[local-wp-port] without SSL (I will skip why 127.0.0.1 instead of localhost or site domains, but it only work this way for now). Then when I’m working on a default WP site like my second project I would like to be able to use the site domains instead of localhost for the site url.
Hey @davebeauchemin - that makes sense! I appreciate the extra context, that is helpful. Let me get back with the team and what the changes to Local would look like to make this possible.
Hello @austinwendt
Do we have an update on this?
We would really appreciate the ability to use router mode on per site basis.
Here is my use case -
I have few websites that need to run on site domains because they force HTTPS. They were pulled down to my local environment using local connected to a WP engine account. If I try to load these sites on localhost, the assets (css and js) don’t load correctly in the browser because localhost does not support HTTPS.
For some other projects where I’m working to integrate social account logins like Google, the site domains are invalid domain names in the Google cloud console. However, Google cloud console accepts localhost as a valid top level domain for local development.
So, I have to switch between router modes every time I have to switch between projects.
If we can set router mode on per site basis, that would be wonderful.
Thanks,
Ashish
Hey @ashish900 - thanks for joining and posting!
I do not have an update on this issue specifically - we have not added this feature, and it is not on our immediate-term roadmap (before the end of the year).
However, we are starting our planning for 2026, and how we handle HTTPS/SSL is near the top of our list for next year. That may have some downstream impacts here, or something we can evaluate fixing at the same time.
Thank you for bringing this back up to the top for us to consider!