Forum Discussion

ealmachar's avatar
ealmachar
Contributor
2 months ago

HTML support for GraphQL API

Hi Khoros,

I've been roadmapping usage for the GraphQL API that allows for the creation of a Knowledge Base Article: https://developer.khoros.com/khorosauroradevdocs/docs/create-a-knowledge-base-article#create-a-knowledge-base-article

When it comes to populating the GraphQL, I noticed some fields that we can use to populate an article, like "subject", "body", "introduction". However, when it comes to creating a Knowledge Base Article, I'm curious if there is support for some things I can do with the GraphQL API that we can already do with the UI version of creating a Knowledge Base Article. For example, in the UI, I can open the Source Code field in the editor of the article (please see attached screenshot). What this allows me to do is to essentially author the article in HTML, rather than in plaintext.

So, as seen in the screenshot, I can set the Source Code for the new Knowledge Base Article.  My question is this: with the GraphQL API, can I submit the body content as straight HTML just like I can in the UI > SourceCode?

If the answer is no, my question we then be, is there a way we can set the HTML of a new Knowledge Base Article using the GraphQL API in any way (Source Code or otherwise)?

Thanks,

Edson

API
graphQl
UI & Design

1 Reply

  • MattV's avatar
    MattV
    Khoros Staff
    2 months ago

    If I had to guess, I would say you could. I think even in community classic we were able to manually put in those <li-asdf> tags into the message body, and as long as it resolved to an actual object and ID, it would work.

    Aurora uses GraphQL for 100% of its interactions with the DB/Backend, and I'm quite certain we save those tags to the DB. 

    So, what you can do for any Aurora operation, is "do the thing" with brower dev tools network tab open. You may need to make sure to "preserve log" in case the page reloads. You will see a "graphql?opname=Something" in the requests. If you look at the payload of that request, you can see the data they are sending to graphql. 

    The "opname" you see in the network requests just map to a .query.graphql (or .mutation.graphql) on the backend, with relevant variables set. So only sort of gotcha with this is it may not be immediately obvious which graphql query or mutations they are using,