I think youd need a Collection and then add every block to it then conditionally show/hide it if that block is present in the current iteration. Then you could build it out with tokens and more complex structures.
It's kind of a lot of work to setup but once you have it then it should be working fine.
I'd need to see the api response to understand if this solution is viable though
The advantage is you get a lot more editing control from the CMS
If the API resonse is an array of blocks then the solution i suggested should work
If it's HTML then you can only get so far with content embed, but we'll add ability to add custom selectors in the future
Great, I hadn't thought of the conditionally/show hide—I was concerned about query blocks that might not be present. Here's the first few dozen lines of the response for that page:
yeah i think you can do it. idk if all blocks will be usable but looks like those are.
Youd bind the blocks array to a collection then collectionkey and show hide based on that. So if block_richtext then show your box that has the styles for that
great, makes sense! Some of the blocks in the template are designed with sub-blocks (Steps for example), and are just listed as UUIDs. Here's the relevant JSON:
"item": {
"alternate_image_position": true,
"headline": "<p><em>Refined</em> over tons of projects</p>",
"id": "a163efd7-1037-4261-939d-28a08122c426",
"show_step_numbers": true,
"title": "Our Process",
"steps": [
"6dc81e9f-c446-4005-a87f-a54163f48433",
"36ec55d8-1bc0-494c-8448-7afcce4bd5e1",
"6ace7412-79cc-4f03-9d1c-64343b3ebd87",
"8306f18f-0dd1-446d-b173-6f1a481049b9",
"75903f73-8964-46a8-a33a-c9d22ecb5daa"
]
}
},In Webstudio,
<query variable>.data.data[0].blocks[5].item.steps[0] just yields the UUID
If I were to use something like that, I'd guess I'd need to do a follow-up query to get the html of those sub-blocks.
Or maybe that's possible with one call in GraphQL? Not at all familiar with it
Honestly, all of this may be overkill for my use case. It's between Directus and Ghost, but I'm annoyed with the lack of custom field types in Ghost
Never mind, answered my own question—the initial REST or GraphQL query would just need to use the API filters to access the content of sub-blocks. Still... maybe this is too much of a shiny new toy syndrome, and something simpler like Ghost will keep me focused 🙃
interesting. ghost actually has a lot of components by default. and you can use markdown for things like tables and it renders an html table
Ah ok—so you can add default Ghost components with their HTML. Not quite as hands-off, but good to know!
Bogdan's comment Would support only tags at first means at first it would only support <div> or <somecustomtag>?
hope you don't mind one more Ghost question, since I know you've been working with it a lot. Can using a theme with headless Ghost permit adding components in the Ghost UI—without hand-coding them—so that they're available in the content API?
no thats an old comment before Contend Embed came out. So he was saying it would work how it does today, Heading 1, etc
you dont hand code them as it. you select Callout from the dropdown and it provides the html in the response
Oh, nice. This is looking a lot more streamlined than setting up Directus. Thank you!
I just wish Ghost would make headless work better with its membership portal and newsletter stuff. Maybe in v6
any ballpark for when this might be available?
i built some proxy with ghost membership before webstudio for another project and got super close to membership working but i recall getting hung up on one thing so there might be hope. Depends exactly what you want out of it
Go upvote it 🙂 I want it too lol. There's just so many high prio things
I don't think I'm up to the task of building something as a workaround, but good to know it might be possible. At this point, I'd want basic stuff like paid membership/newsletter, adjusting payment and personal/contact info, etc—stuff I'm assuming is in the membership portal that Ghost says is unavailable in headless
at a minimum i would expect you can use a webhook form and collect emails and use ghost to send emails. Login and tiers would be a different more complex story
in reference to your comment on that github issue:
JSON may open the opportunity to map blocks to our Components
mapping JSON to Webstudio Components would be amazing!
thanks! I think what I'm suggesting is something beyond what you shared there, but I'm checking to make sure so I don't waste anyone's time
Ok, you were absolutely right. Sorry about that, and thanks for teaching me something new. I'll close the issue!
By the way, do you think there will eventually be a way to more easily manage situations like this rather than manually updating conditional show/hide for each block type? Perhaps by introspecting the GraphQL or something?
no worries at all! I think a lot of this is too ambiguous and unique across platforms to create some generic thing. Some sort of discovery is intriguing though
thanks for your help! I agree—the discovery thing could be very handy down the road for people
Just wondering if there's any workaround for this, currently?
I'm really enjoying getting set up with Ghost, and I'm not expecting that github issue you shared getting worked on very soon, but 🤞
custom css for now 🤷♂️ i'm personally just avoiding those components right now but idk might be worth adding some css
Thanks--yeah I think I can get away with keeping it simple and avoiding them for now
