I have a collection in my app that contains a few relationship fields to other collections. I'm noticing the data is correct in the DB and even is being returned to the admin panel when editing the collection. However, for some reason the values for those fields are not being populated in my production deploy of the payload app. In my dev environment, when connecting to the production DB, they do populate. Can someone help me troubleshoot this?
Do you have any failed network requests in the browser when you are on the server? My initial thought is it could be an issue with the authentication cookie not being set.
I don't see any failed requests. However, the
_preferences
request for the collection is returning
{"message":"Not Found","value":null}
I'm not sure if that is relevant.
Hey, @ralphusadolphus I’ve experienced the same when I accidentally deleted related collection item. So in that case I just got ID as the value and relationTo field.
I don't think I deleted anything, however I did migrate my database. It's possible that something got mixed up in the move? However, I'm connecting to the same DB in both production and development environments and in development it seems to work correctly, but in production it doesn't.
@dribbens I still have not been able to determine a cause for this. Any other ideas?
I'm out of ideas.
Preferences is not going to be an issue. That happens whenever a lookup for something that isn't there is made which can happen very often when using the admin UI.
In production you have done a new build since making changes?
We need to figure out what is making your dev different from prod
there's got to be a mismatch somewhere with your Payload config that's running in prod and in local dev
likely access control, or a mismatching field config
either that or maybe you have a
cors
/
csrf
issue and you are not actually authenticated while hitting your prod API, but you might be authenticated when hitting your local API
I don't think authentication is the issue because I am definitely seeing the missing values in the network request. I would imagine that if I was not properly authenticated that it would not return that data. Unless I guess those pieces of data had some specialized permissions associated with them? Is that a thing?
Could it be some sort of networking issue? My DB is on a server separate from my production Payload instance.
I did another build just now to be sure and the relationships are still now showing up.
Here's what I'm seeing. These empty values have been filled in and have data in the DB and in the network response:
did you modify the
relationTo
of your fields?
or change collection slugs?
have you rebuilt your admin UI?
and to be clear, what you're saying is that the network requests are
correctbut the admin UI doesn't show the right thing
No, I didn't modify the
relationTo
of those fields
I didn't change the collection slugs. None of them really have slugs. Do I need to add slugs to them? They seem to work fine when I go to them directly.
I rebuilt my payload project. I'm not sure if that is different from rebuilding the admin UI. These are my build commands, I ran the
build
one that runs the other three:
"build:payload": "cross-env PAYLOAD_CONFIG_PATH=src/payload.config.ts payload build",
"build:server": "tsc",
"build": "yarn copyfiles && yarn build:payload && yarn build:server",
"copyfiles": "copyfiles -u 1 \"src/**/*.{html,css,scss,ttf,woff,woff2,eot,svg,jpg,png}\" dist/",
Yes, the data in the network request is correct but the UI is not showing those fields as having values. This occurs for any collection that has relations to other collections. Here is an example of a different collection with a similar issue:
What version of payload? Can you paste a copy of one of the field configs that’s giving you trouble?
Here's one of the configs that has the relationships that are failing to load:
const LevelBlock: Block = {
slug: "LevelBlock",
fields: [
{
name: "title",
type: "text"
},
{
name: "text",
type: "richText"
}
]
}
const Builds: CollectionConfig = {
slug: 'builds',
admin: {
defaultColumns: ['title', 'author', 'category', 'tags', 'status'],
useAsTitle: 'title',
},
access: {
read: () => true,
},
fields: [
{
name: 'title',
type: 'text',
},
{
name: "metaTitle",
type: "text"
},
{
name: "slug",
type: "text"
},
{
name: 'author',
type: 'relationship',
relationTo: 'users',
},
{
name: 'publishedDate',
type: 'date',
},
{
name: 'category',
type: 'relationship',
relationTo: 'categories',
},
{
name: 'tags',
type: 'relationship',
relationTo: 'tags',
hasMany: true,
},
{
name: "bannerImage",
type: "upload",
relationTo: "media",
required: true,
filterOptions: {
mimeType: { contains: 'image' },
},
},
{
name: 'shortDescription',
type: 'text'
},
{
name: "metaDescription",
type: "text"
},
{
name: "characterConcept",
type: "richText"
},
{
name: "levelTable",
type: "array",
label: "Level Table Row",
labels: {
singular: 'Row',
plural: 'Rows',
},
fields: [
{
name: "levelTitle",
type: "text"
},
{
name: "levelNotes",
type: "text"
}
]
},
{
name: 'levelBlocks',
type: "blocks",
blocks: [
LevelBlock
]
},
{
name: 'analysis',
type: 'richText'
},
{
name: "lastUpdated",
type: "text"
},
{
name: 'status',
type: 'select',
options: [
{
value: 'draft',
label: 'Draft',
},
{
value: 'published',
label: 'Published',
},
],
defaultValue: 'draft',
admin: {
position: 'sidebar',
}
}
],
timestamps: false,
}
Every one of the
type: "relationship"
fields fail to load saved data
So if you create a new document, and add a relationship, it won’t show up on refresh?
Correct
Do you have a public repo I can clone and check out?
Here's my repo.
https://github.com/ThatBalls/payload-cms-blogIt does work fine when I run it locally.
Sorry, forgot to reply
OK I think I can narrow down that it isn't an issue with the DB. I just tried my Payload with a fresh DB and this issue still exists.
I realized the repo was private. I just made it public.
@jesschow can you and I pair on this today to see if we can get to the bottom of @ralphusadolphus's issue?
@jmikrut absolute
Thank you! Let me know if you need any more information.
Did you deploy this on Cloud? or elsewhere?
It's deployed on a DigitalOcean Droplet
okay thanks!
I deployed your project to Cloud and the relationships fields in the Build collection are working as expected, so I'm thinking it must be something in your DigitalOcean setup... this is a tricky one...
Is everything else in your app working? Any other errors that might give us a hint?
You can take a look here
https://ralphus.payloadcms.app/admin/login: dev@payloadcms.com
pw: test
could be CSRF / CORS
hmhmhmhm
okay lemme dig
Looks like it is working correctly there.
It's certainly possible. I have suspected it might have something to do with the networking setup on my droplet. But I don't really know what to look for.
I'm not sure it would help at all, but I could make a temporary account on my deployed payload instance and you can see the issue firsthand. Let me know if you think that would be useful
i think that would help for sure
if you could DM me an account, i can probably find the issue in a few sec
OK, let me create that real quick and I will DM you the credentials
ok figured out what the discrepancy is at least
the
depth
query parameter is not taking effect
when the Payload admin UI fetches a document to edit, it fetches with
depth=0
but for some reason, and only on your digitalocean server, payload is returning the fully populated document
it
shouldonly be returning IDs for your relationships, but it's returning full populated related docs
kinda like depth=0 is just being disregarded
something in your digitalocean droplet must not be forwarding the query params on to the Node service
Interesting. Probably something wrong with my nginx config, I would think?
yes
Not incredibly surprising. I'm not great with nginx. It's currently taking the requests and forwarding them to the appropriate port for the service. It must be cutting off the query parameters...
here is how we do it:
server {
server_name your-website.com;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
proxy_pass http://localhost:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_set_header X-Forwarded-For $remote_addr;
}
listen [::]:443 ssl ipv6only=on;
listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/your-website.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/your-website.com/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
}
the real relevant stuff is in the
location
block.
the rest of this is just for SSL
Here's my relevant nginx config:
upstream payload {
server localhost:3001;
}
server {
server_name my-website.com
location ~ /(admin|api|media)(.*) {
proxy_pass http://payload/$1/$2;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
}
I am only trying to catch
admin
,
api
, or
media
requests because others I'm sending along to my website. I don't have the
$remote_addr
line but I don't know if that is the issue. I think my regex for the location or the
proxy_pass
line might be incorrect.
yes 100% that is it
you have
/$1/$2
but that is not forwarding the query params
only the path
and honestly this is where my nginx knowledge starts to be limited as well
AH! Yes, that makes sense.
Well at least now I know what I need to focus on. This should get me where I need to go. I'll try to find what's missing and I'll post an update here hopefully today.
Thank you!
of course
this was a real mystery for me too haha
nice solve jim 🔍
Well, once you found the issue, the fix was very easy. When you're using regex for the location in nginx, the query parameters are treated as variables.
$is_args
is
?
if there are args and empty string if there aren't. Then
$args
is the list of args.
So I changed the above location statement to:
location ~ /(admin|api|media)(.*) {
proxy_pass http://payload/$1/$2$is_args$args;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
And now it works perfectly
Thank you so much! This was driving me crazy!
This actually also probably resolves the only other issue I was having with Payload which is that my queries weren't respecting the conditions I was using and I was having to filter them after the request. Now I suspect that will work fine.
Star
Discord
online
Get help straight from the Payload team with an Enterprise License.