Admin site always fetches from localhost

[thasmin]

Bug report

Describe the bug

The admin site always tries to fetch localhost:1337/admin/project-types, even after the url is set in config/server.js.

Steps to reproduce the behavior

1. Install strapi on new server with npx create-strapi-app@latest strapi.
2. Configure DNS so a hostname points to the server.
3. Add a url key in config/server.js with the hostname.
4. Start server with npm run develop.
5. Navigate to site, click on the button to set up the administrator user
6. See error, open devtools to see broken API call to localhost:1337

Expected behavior

XHR call goes to hostname configured in config/server.js

Screenshots

It has a red triangle instead of a form.

Code snippets

System

• Node.js version: v16.13.2
• NPM version: 8.1.2
• Strapi version: 4.0.7
• Database: sqlite
• Operating system: Ubuntu 20.04

Additional context

[manutepowa]

Same issue.

System

• Node.js version: v14.18.1
• NPM version: 6.14.15
• Strapi version: 4.0.7
• Database: mysql
• Operating system: Ubuntu 20.04

[derrickmehaffy]

The admin needs to be rebuilt if you change the url in the server.js, this is normal and intended as we now ship a pre-built admin so you don't have to build on first use but this is only designed for local devleopment. For any deployment you will need to build the admin as the url is statically compiled into the admin panel build.

Closing as this is intended.

[0xearl]

weird enough, I tried changing the server.js and it fetches right after (without rebuilding the admin panel). is this working as intended too @derrickmehaffy ?

[cloakedninjas]

I'd like to petition that this baking-in of admin URL be changed to use the .env system

A common practice is that you build your app for a staging environment, run tests there and when it's time to deploy, you copy that staging image onto your production servers, thus ensuring that what you test is what you deploy.

Requiring a build step right before deploying to production means you potentially pull in bugs that you were not able to see when testing a release candidate.

[strapi-bot]

This issue has been mentioned on Strapi Community Forum. There might be relevant details there:

https://forum.strapi.io/t/strapi-4-0-desployed-admin-keep-call-to-http-localhost-1337-admin-project-type/15028/7

[quedicesebas]

The important thing is that if you added url key to server.js like this:
url: env("STRAPI_BASE_URL", "http://localhost:1337")
ypu need to add that env variable to build environment (in my case, to GitLab CI)

[rweintraub-cycleon]

@derrickmehaffy Please re-open this. Telling the community that a unconventional behaviour "is expected" doesn't change the fact that it's non-standard. as @cloakedninjas mentioned there are valid reasons to do it this way

[derrickmehaffy]

Can you please open a feature request on https://feedback.strapi.io

As this isn't really a bug report but would be considered a feature request.

[Stofkat]

Is there any update for this? Still running into this issue while trying to run strapi containerized

[goetzc]

Come one guys, this is a basic practice to use environment variables in runtime, not in build time. This breaks the 12factor application:

https://12factor.net/config

[derrickmehaffy]

Come one guys, this is a basic practice to use environment variables in runtime, not in build time. This breaks the 12factor application:

https://12factor.net/config

There is nothing specific in 12factor that says you can only use env vars during runtime, build time env vars are both extremely common and widely accepted. I mentioned before this would considered a feature request so I will lock this issue but please feel free to mention it on our FR site I linked above.