Relationships not populating

ralphusadolphus

7 months ago

77

• 

  dribbens

  Payload Team

  7 months ago

  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.

• 

  ralphusadolphus

  7 months ago

  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.

• 

  nikich

  7 months ago

  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.

• 

  ralphusadolphus

  7 months ago

  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?

• 

  dribbens

  Payload Team

  7 months ago

  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

• 

  jmikrut

  Payload Team

  7 months ago

  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

• 

  ralphusadolphus

  7 months ago

  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:

  
  

  
  

  

  
• 

  jmikrut

  Payload Team

  7 months ago

  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

  correct

  but the admin UI doesn't show the right thing

• 

  ralphusadolphus

  7 months ago

  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:

  
• 

  jarrod69420

  7 months ago

  What version of payload? Can you paste a copy of one of the field configs that’s giving you trouble?

• 

  ralphusadolphus

  7 months ago

  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

• 

  jarrod69420

  7 months ago

  So if you create a new document, and add a relationship, it won’t show up on refresh?

• 

  ralphusadolphus

  7 months ago

  Correct

• 

  jarrod69420

  7 months ago

  Do you have a public repo I can clone and check out?

• 

  ralphusadolphus

  7 months ago

  Here's my repo.

  https://github.com/ThatBalls/payload-cms-blog
  

  It 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.

• 

  jmikrut

  Payload Team

  6 months ago

  @jesschow can you and I pair on this today to see if we can get to the bottom of @ralphusadolphus's issue?

• 

  jesschow

  Payload Team

  6 months ago

  @jmikrut absolute

• 

  ralphusadolphus

  6 months ago

  Thank you! Let me know if you need any more information.

• 

  jesschow

  Payload Team

  6 months ago

  Did you deploy this on Cloud? or elsewhere?

• 

  ralphusadolphus

  6 months ago

  It's deployed on a DigitalOcean Droplet

• 

  jesschow

  Payload Team

  6 months ago

  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

• 

  jmikrut

  Payload Team

  6 months ago

  could be CSRF / CORS

• 

  jesschow

  Payload Team

  6 months ago

  hmhmhmhm

  
  

  
  

  okay lemme dig

• 

  ralphusadolphus

  6 months ago

  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

• 

  jmikrut

  Payload Team

  6 months ago

  i think that would help for sure

  
  

  
  

  if you could DM me an account, i can probably find the issue in a few sec

• 

  ralphusadolphus

  6 months ago

  OK, let me create that real quick and I will DM you the credentials

• 

  jmikrut

  Payload Team

  6 months ago

  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

  should

  only 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

• 

  ralphusadolphus

  6 months ago

  Interesting. Probably something wrong with my nginx config, I would think?

• 

  jmikrut

  Payload Team

  6 months ago

  yes

• 

  ralphusadolphus

  6 months ago

  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...

• 

  jmikrut

  Payload Team

  6 months ago

  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

• 

  ralphusadolphus

  6 months ago

  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.

• 

  jmikrut

  Payload Team

  6 months ago

  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

• 

  ralphusadolphus

  6 months ago

  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!

• 

  jmikrut

  Payload Team

  6 months ago

  of course

  
  

  
  

  this was a real mystery for me too haha

• 

  jesschow

  Payload Team

  6 months ago

  nice solve jim 🔍

• 

  ralphusadolphus

  6 months ago

  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.