Preview not working using page id, idType, asPreview:true

[mattLaakvand]

We have been working on generating the page preview for a project created in NextJs and have all of the main functionality build for this but we have hit a bit of a brick wall due to this plugin. The latest version still has problems with ACF data not showing when using Grapqhl’s preview argument.

As an example, we have attached the Careers page templates query for a website we are working on, with the preview argument. Currently, graphql queries using the idType argument URI doesn't work with preview mode either.

The code we have written will enable NextJs' preview mode when browsing the API route and a secure token gets passed as URL parameters, which then redirect you to the correct location.

After being redirected the page will get generated as a preview on the server which will be served to the client. This gets done by converting the URL to the database ID and passing asPreview boolean argument as true, which then gets the latest revision of the page. (a revision gets created when clicking preview)

This then generates a query as below:

query MyQuery {
  page(id: "320", idType: DATABASE_ID, asPreview: true) {
    content
        featuredImage {
          node {
            altText
            caption
            id
            sizes
            sourceUrl
            srcSet
          }
        }
        id
        menuOrder
        slug
        title
        uri
        seo {
          metaKeywords
          title
          metaDesc
          opengraphTitle
          opengraphDescription
          twitterDescription
          twitterTitle
          focuskw
        }
        template {
          ... on Template_Careers {
            templateName
            alternating_marketing_boxes {
              alternatingMarketingBoxes {
                imageAlternativeText
                marketingBoxParagraph
                marketingBoxTitle
                marketingImage {
                  mediaDetails {
                    height
                    width
                  }
                  sourceUrl(size: LARGE)
                }
              }
            }
            simple_page_intro {
              fieldGroupName
              introPara
              introTitle
              buttonLabel
              buttonLink
              openInTab
            }
            complex_banner {
              complexBanner {
                buttonLabel
                desktopImage {
                  sourceUrl(size: SUPER)
                  mediaDetails {
                    width
                    height
                  }
                }
                imageAltText
                mobileDeviceImage {
                  sourceUrl(size: SUPER)
                }
                shortText
                subtitle
                title
              }
            }
            select_featured_stories {
              featuredStoriesTitle
              featuredStoriesParagraph
              selectedStories {
                ... on Story {
                  id
                  uri
                  avatar {
                    avatar {
                      videoTitle
                      videoShareLink
                      videoImage {
                        sourceUrl(size: LARGE)
                        mediaDetails {
                          height
                          width
                        }
                        altText
                      }
                      avatarName
                      avatarTitle
                    }
                  }
                }
              }
            }
          }
        }  
  }
}

This works great when making changes to the title or standard Wordpress content boxes, but due to the bug in Graphql ACF those fields remain empty. Since all the pages are 95% made up of ACF data, preview won't be usable without this working.

This is the resulting data from the query above though the id is fake:

{
  "data": {
    "page": {
      "content": null,
      "featuredImage": null,
      "id": "123456789123",
      "menuOrder": null,
      "slug": "320-autosave-v1",
      "title": "Careers",
      "uri": "/careers/?preview=true",
      "seo": {
        "metaKeywords": "",
        "title": "Careers – English",
        "metaDesc": "",
        "opengraphTitle": "",
        "opengraphDescription": "",
        "twitterDescription": "",
        "twitterTitle": "",
        "focuskw": ""
      },
      "template": {
        "templateName": "Careers",
        "alternating_marketing_boxes": {
          "alternatingMarketingBoxes": null
        },
        "simple_page_intro": {
          "fieldGroupName": "simple_page_intro",
          "introPara": null,
          "introTitle": null,
          "buttonLabel": null,
          "buttonLink": null,
          "openInTab": null
        },
        "complex_banner": {
          "complexBanner": {
            "buttonLabel": null,
            "desktopImage": null,
            "imageAltText": null,
            "mobileDeviceImage": null,
            "shortText": null,
            "subtitle": null,
            "title": null
          }
        },
        "select_featured_stories": {
          "featuredStoriesTitle": null,
          "featuredStoriesParagraph": null,
          "selectedStories": null
        }
      }
    }
  },

[mattLaakvand]

Hi There,

Is there an update on this?

Many thank.

[DerthVedder]

Hi @mattLaakvand

We were having similar issues with our set up and it's namely due to post_meta ( which is where ACF fields are stored ) fields being available in autosaves.

I ended up writing a script to trigger an autosave on new posts / pages / custom post types and writing postmeta to the generated autosave's postmeta using the ACF Javascript API.

I'm sure it can get far more complex than our specific use case (we have repeaters being used in several places), but it seemed to do the trick. I think with your scenario, it would be relatively easy to implement something similar.

[lalilaloe]

@DerthVedder can you show how this is setup, looking for a workaround for the same issue. For me any acf fields return null or defaults when using asPreview: true

[mattLaakvand]

Thank you for getting back to me @DerthVedder and sorry for the long delay in doing so. If it is possible to see a sample of the code you used to set this up that would be great.

In the meantime I will look into the ACF Javascript API and postmeta.

[eliawk]

@jasonbahl @mattLaakvand I'm still getting null from a simple ACF field if I use asPreview: true this the query I'm testing:

query CaseById {
  caseStudy(id: 1485, idType: DATABASE_ID, asPreview: true) {
    title
    databaseId
    detailFields {
      headerColor
    }
  }
}

[justiny]

@eliawk I'm getting null on a post field on fresh wp install.

query NewQuery {
  post(id: "123", idType: DATABASE_ID, asPreview: true) {
    preview {
      node {
        title
      }
    }
  }
}

[jhochgrevetsd]

I am actually getting null the same as @eliawk on essentially any query (as far as I can tell) when using asPreview. Still debugging and looking for a conflict etc, but thus far I have not found a way to make it work.

[DidoMarchet]

Hi, same issue

[missionmike]

We've encountered the same issue. When previewing an already-published post, the ACF values populate normally. As soon as I make an edit to the post title/content, and preview again, the ACF fields in the GraphQL response are null.

@jasonbahl I've set up a minimal reproduction of this here: https://github.com/missionmike/wordpress-acf-wpgraphql-preview-bug-minimal-reproduction

I'm currently looking into the codebase for WPGraphQL and the WPGraphQL ACF plugin to see if it's something that can be fixed there.. If anyone has any pointers of where I should look, please let me know! So far, I'm checking in the wp-graphql/src/Type/ObjectType/RootQuery.php and getting familiar with the wp-graphql-acf/src/* content.

CC @salim523

Update

I can reference the original ACF values as a temporary workaround, but it doesn't allow us to preview any ACF changes. Perhaps this is due to an underlying issue with ACF + Gutenberg itself.

If I add this snippet:

$revision_parent_id = wp_is_post_revision( $id );

if ( $revision_parent_id ) {
    $id = $is_revision;
}

before this line: https://github.com/wp-graphql/wp-graphql-acf/blob/05636eff8562d4f5ea65979ef82eb6808b4a3fb2/src/class-config.php#L455

... I can at least reference the original ACF values. I'm not thinking this is any kind of real solution, but just a clue/breadcrumb for reference. I'll provide an update if we come up with a more reasonable idea.

Thanks for all your work on WPGraphQL!

[jasonbahl]

👋🏻 sorry for the lack of attention on this issue.

---

This PR on core WPGraphQL that resolves some bugs around the asPreview argument might also be relevant here? https://github.com/wp-graphql/wp-graphql/pull/2937

---

If the changes from the above PR do not resolve the issue, then my next question would be:

Are you using ACF with Gutenberg or Classic Editor?

There's a core WordPress issue that prevents meta from being previewed when using Gutenberg (even in non-headless WordPress).

You can read my comment on the Gutenberg issue here: https://github.com/WordPress/gutenberg/issues/16006#issuecomment-657965028

---

For those that are NOT using Gutenberg, and the above changes to core WPGraphQL don't fix things for you, I recommend you try the new version of WPGraphQL for ACF that we're building over here: https://github.com/wp-graphql/wpgraphql-acf

It is a complete re-architecture, and there are breaking changes, but it's the version we'll be going stable with and supporting long-term.

It's solved a lot of bugs during the re-architecture, but if for some reason this feature is still not working on the new version, I'd recommend opening a new issue on that repo with detailed steps to reproduce. (and note whether you've tried the changes from the core WPGraphQL PR linked above and whether you're using Gutenberg or not)

[jasonbahl]

fwiw: WPGraphQL v1.18.0 was released yesterday which includes the asPreview fix mentioned above.

[jasonbahl]

related: https://github.com/wp-graphql/wpgraphql-acf/issues/118

[clieee]

Currently using wp-graphql/wp-graphql version 1.18.2, and also have the WPGraphQL for Advanced Custom Fields version 0.6.1. Running WP as headless and trying to get Preview working. I dont have any ACF setup yet, just a regular page I've created. The page has been published, and then I try to edit the title and then click Preview without any other actions involved.

On my frontend (nextjs) I do the following query to fetch the entry data:

query EntryQuery($id: ID!) { page(id: $id, idType: DATABASE_ID, asPreview: true) { id slug title content } }

But I get null as a response for that. If I skip "asPreview" I get the version for the published one.

Do we have any updates on this?

[jasonbahl]

@clieee are your GraphQL requests authenticated when using asPreview?

if you're not authenticated, then a asPreview:true will return null.

Just like in monolithic WordPress, WPGraphQL previews are only returned to authenticated users that have appropriate capabilities to be able to preview data.

[clieee]

that explains it I guess, thanks for letting me know. Is there a token you can pass along, or what is there to setup this?

[jasonbahl]

👋 Hello,

I've opened this issue to track documenting preview better.

I believe this issue might be related to either a known bug with the block editor or possibly mis-configuration of Authorization / Authentication.

I'll write up a guide that details how Preview is expected to work in WPGraphQL (and WPGraphQL for ACF).

I'm going to close this issue as I've not been able to reproduce and recent activity seems to confirm my suspicions that Auth might be the culprit in some cases.