Closed joshhills closed 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
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!
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
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!
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?
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:
paths
from config typeserverURL
does not contain a path We can take a stab at that stuff tomorrow!
Closed with #28 .
This issue has been automatically locked. Please open a new issue if this issue persists with any additional detail.
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
http://localhost:3000/foo
http://localhost:3000/foo/admin
Detailed Description
I am trying to do this because I have multiple containerized applications running in my environment - e.g.
Ideally, the front-end site will exist at the
/
root and the CMS will exist at/cms
(akin to Wordpress)