payloadcms / payload

Payload is the open-source, fullstack Next.js framework, giving you instant backend superpowers. Get a full TypeScript backend and admin panel instantly. Use Payload as a headless CMS or for building powerful applications.
https://payloadcms.com
MIT License
24.54k stars 1.56k forks source link

serverURL with a base path does not work #24

Closed joshhills closed 3 years ago

joshhills commented 3 years ago

Bug Report

Setting the server URL to something with a path such as

http://localhost:3000/cms

Does not appear to work, despite printing:

[02:31:35] INFO (payload): Payload Admin URL: http://localhost:3000/cms/admin

Expected Behavior

You should be able to access the admin panel at the URL that is printed

Current Behavior

The route binding does not appear to factor in sub paths

Possible Solution

Use the provided serverURL when configuring express bindings in index.js

Steps to Reproduce

  1. Set the serverURL to http://localhost:3000/foo
  2. Observe that the log prints the admin URL as http://localhost:3000/foo/admin
  3. Observe that opening your browser to that page shows a broken looking "loading" message indefinitely

Detailed Description

I am trying to do this because I have multiple containerized applications running in my environment - e.g.

https://staging.mysite.com
 - port 3000 -> payload
 - port 7017 -> mongodb
 - port 3001 -> my-website-using-payload

Ideally, the front-end site will exist at the / root and the CMS will exist at /cms (akin to Wordpress)

joshhills commented 3 years ago

Upon further investigation it appears that the issue may lie with the API URL, as the page at e.g. /foo/admin attempts to hit http://localhost:3000/api/users/me as opposed to http://localhost:3000/foo/api/users/me

jmikrut commented 3 years ago

Hey @joshhills!

This is actually not intended functionality, and there may be a way to do exactly what you’re looking to do with current functionality.

Can you try setting your routes.admin to /cms/admin and just leave your serverURL equal to http://localhost:3000?

If this works for your needs, we will make sure to update the docs accordingly!

joshhills commented 3 years ago

Thanks for the quick reply! I think the info log message could be considered a bug given it ultimately points to a URL that doesn't work - perhaps an extra line in the docs section for hosting at a sub-path?

I gave that a whirl and it worked. Do you know if there are other paths that need adjusting to ensure that no resources get hosted at the root? I can see options for API etc. in the routes block, but I also see a paths object used as part of the file upload mechanism (?) further down in the configuration? Ideally I need to find a way to scope every Payload resource (CSS/JS, routes...) to foo so that it doesn't fight with the other apps

jmikrut commented 3 years ago

Totally. IMO we really just need to enforce that the serverURL itself does not contain a path - only protocol, domain, port. That would then solve the info log. Well, that and some improved docs of course. Thoughts?

The only routes that get mounted by Payload are the ones that you can customize through the routes config property. Everything that Payload does Express-wise will be scoped accordingly so nothing outside of those routes will compete with your apps whatsoever. Including all statically served CSS, JS, etc. required by the admin panel.

The paths property is actually no longer used and is left over in the config type. We will remove that - good eye!

joshhills commented 3 years ago

Yes, I think to be pedantic, "URL" can typically contain a path, so either a comment or splitting it into those individual fields (though that might be more boilerplate) should suffice. Support for a basePath to automatically pre-pend the routes fields might be a good feature request if others also run into the same issue? Additionally, showing the default URLs in one place might be useful - I had to skip between docs pages to grab them all - unless I'm missing something.

RE other routes - good to know! From reading the docs on uploads, I gather that I can ensure that media uploads are scoped accordingly by making the staticURL and staticDir also contain /foo in some way. I think it's very elegant that it's suggested that media be its own collection type (though you might want to include that in the npx setup alongside TODOs, I imagine it'll be necessary for most projects?).

I'll try setting them all, creating a collection with file uploads, and close with a final comment when it works?

jmikrut commented 3 years ago

Good point regarding pedantics. We will keep an eye out for further requests and should be able to facilitate basePath support in one way or another if it’s important to the community.

I say we keep this issue open until we can do the following:

We can take a stab at that stuff tomorrow!

jmikrut commented 3 years ago

Closed with #28 .

github-actions[bot] commented 1 month ago

This issue has been automatically locked. Please open a new issue if this issue persists with any additional detail.