Prismic toolbar not displaying the relevant documents

[website (Website 360Learning)]

Hi everyone,

We’ve been using Prismic for our blog - https://360learning.com/blog/. Very happy with the product so far. However, our content manager has reported a weird behavior of the Prismic toolbar when visiting some blog page while being logged in Prismic.
Basically the toolbar is not displaying the right main document.
For instance, we’ve got a custom type for articles, and if I check this article here - https://360learning.com/blog/training-needs-analysis - the main document identified is the navbar as you can see on attached screenshot

Is that a bug or is there a setup that we need to follow in order to make sure that it’s the right main document that is displayed here?

Many thanks for youe help in advance and keep up the good work!!

[Phil (Phil Snow)]

Hi Team,

We had a look at this and we could see that you were using Nuxt, for static generation we’re guessing. From a bit of digging we came to the conclusion that it seems you are doing static queries for your documents but maybe not for you menus etc.

The edit button script learns from the queries made and documents returned what is the main document. So this can cause issue when the site is being statically deployed.

It would be really interesting if you could show us how you are doing the queries for you menus and blog posts. This would be a good start to debugging this.

Thanks.

[jeremy.benzakein]

Hi @Phil,

You guessed right, we are indeed using nuxt.js for static generation. The generated content is then hosted on Netlify.

We do our queries similarly to what has been done in the multi-page website example.

You are right, we query documents differently for pages and UI elements.

• The page documents are queried in the asyncData component like so

// pages/blog/_uid.vue
async asyncData({ $prismic, params, error }) {
    try {
        // this is a simplified version of the query
        const article = (await $prismic.api.getByUID("blog_article", params.uid)).data;
        return { article }
    } catch catch (e) {
        error({ statusCode: 404, message: "Page not found" });
    }
}

• Ui element documents (such as navbar and footer) are queried from a vuex store actions

// store/footer.js
export const state = () => ({
    data: {},
    errors: []
});
export const mutations = {
    setFooter(state, footerData) {
        state.data = footerData;
    },
    addError(state, error) {
        state.errors.push(error)
    }
}
export const actions = {
    async fetch({ commit }, $prismic) {
        try {
            const footerData = (await $prismic.api.getSingle("footer")).data;

            commit("set", footerData);
        } catch (e) {
            const error = "Please create a footer document";

            commit("addError", error);
        }
    }
}

• Thes actions are invoked in the layout middleware components

// layout/default.vue
export default {
    [...],
    async middleware({ store, $prismic }) {
        await store.dispatch("footer/fetch", $prismic);
        [...]
    }
}

Thanks for your help

PS: I work with @website

[jeremy.benzakein]

Hi @Phil,

Have you found anything of note ? Would changing the way we query documents resolve the issue ? If so, what could we do ?

[Phil (Phil Snow)]

Hey,

Sorry about the delay, it all seems correct. I’m testing on my side now with different queries to see what it changes in my project.

[Phil (Phil Snow)]

So looking in to it a little more, I’m seeing similar behaviour when using or multi-page example when going through the nuxt-links to the homepage, if I refresh the page the edit button is finding the correct main document.

When we did checks on your blog the blog query wasn’t appearing in the dev mode, so I’d love to investigate more as I’m not completely sure exactly where the issues stems. Is there any way you can send me the project in a zip or a Github link in a private message so I can debug more?

[monogram (Monogram Design)]

We are also having the same exact issue. We have a Nuxt 2.13.3 application statically generated, which, while in development mode, the Prismic toolbar sometimes only shows 1/2 types on the page. For example, we have a ‘home’ single type and a ‘services’ repeating type, and both are being rendered on the page, but the toolbar only shows ‘services’.

[Phil (Phil Snow)]

Hi Team,

Can send me the project in a zip or a Github link in a private message so I can debug more?

Thanks.

[Phil (Phil Snow)]

Just an update:

I checked your project and could indeed reproduce this, but only on the homepage, all the blog pages work fine.

I’m not sure if it’s linked to the fact it’s statically deployed, with the banner queried first in the store or because your homepage is made almost entirely of context relationships or a mix of both.

But I’ve explained it to the Dev team so they can investigate and hopefully they’ll have a more educated answer than my what I’ve given you here.

[Phil (Phil Snow)]

Adding quote here to continue conversation:

@evvvritt

I’m using the @nuxtjs/prismic plugin for a Prismic/Nuxt site. I’ve enabled Preview on production and the /preview endpoint is working beautifully

However, when I click the “Edit Button” () on the Nuxt site the doc link for “Main Document” is always incorrect. It lists the first “linked” doc as the main.

@evvvritt For the linked document are you also using a content relationship?

Thanks.

[evvvritt]

Thanks @Phil yes, pretty much every page uses a content-relationship, with the “Main Document” being the first related doc. Like Jeremy, I also use asyncData in my nuxt app to fetch the main doc.

[Phil (Phil Snow)]

OK, thanks for the extra information. I’ll update everybody here once we have more info or questions.

[benji (Ben Gurney)]

Hi Phil,

We’re also getting the wrong Main document when using the PHP toolkit. In our case, we have a Footer document that is appearing as the Main document. Is there an articulation of the logic that is used to determine the Main and related documents? Or a way to explicitly define them?

Cheers,

Ben

[Phil (Phil Snow)]

Hey Ben,

I’m not sure myself of the logic behind the predictions, I’ll try to get some more info on how exactly this works and get back to you.

Are you defining the footer with a content relationship by any chance?

[benji (Ben Gurney)]

Thanks Phil. No, we are pulling the Footer in using the getSingle query.

[Phil (Phil Snow)]

Hi Everyone,

This is being tracked as an open issue in the tracker. It's seems to be an issue with how the toolbar predicts the main document through queries, when the team has more information they'll update you in this thread.

Though I think it will require some updates to the toolbar. I also think @benji 's suggestion of somehow defining the main doc could be interesting, so I've added this as a feature request in the issue tracker.

Sorry for the inconvenience this is causing in the main time.

[Phil (Phil Snow)]

Hi Everybody,

The Dev's (@sebastien ) have been working on improving the logic of the toolbar to better predict documents.

The work is open source and you can track it here:

Fix uids matching for better prediction

Thanks.