Thanks @antonioribeiro. I don't think this shows how to set up block transforms but the docs in the package README do @Erwin. You may also want to look into https://github.com/area17/twill-api and https://github.com/area17/twill-api-client

are there any headless tutorials?

Libraries but no tutorials yet. More to come with the Twill 3 release! There will be a Nuxt 3 example.

Is the develop branch of area17/twill-api compatible with 3.x?

yes

the documentation for initial setup needs a bit more work, we're on it

I'm actually a bit undecided now if I want to go headless. The intention isn't to provide content or data to a JS based site (nuxt,react,ect) but rather "static" content to a laravel project which uses my own package for dynamic products and procurement. The only cross over between the two schemas are "files" which I don't really require on the Twill side anyway. It's looking like the two packages will play nicely together so, considering running them both in the same project.

that makes sense. And yes Twill is definitely made to play nicely with the rest of your Laravel codebase

Hello! I am evaluating Twill as a headless cms and I really like the architecture and admin functionality. But I am not able to get twill-api running - I am always getting "Server v1 does not exist in config or is not a valid class." as a RuntimeException when requiring it. I tried laravel9/twill3/twill-api:dev-develop and laravel8/twill2/twill-api:dev-main with the same error. Do I miss something?

hey @andy_a a quick search brought me this, https://github.com/cloudcreativity/laravel-json-api/issues/32 may be related?

Thanks @Harings Rob , will look into it.

That's from the wrong repository, twill-api is using laravel-json-api/laravel

I investigated and I think there is some installation step missing. I was successful by creating a laravel-json-api server and configuring it in config/jsonapi.php. To do that, I had to disable the api routes first. There is an example server in twill-api/skeleton which I used.

Hey @andy_a the Twill API docs need some work for the install steps, the config from laravel-json-api needs to be published.

Yes, and the Server needs to be created. The problem is that the runtime error occurs on each artisan command, so I had to disable the route in twill-api/routes/api.php

Right! It's on our list to fix that in time for the Twill 3 release and annoucements. We're also working on a full installable example with a Nuxt 3 app consuming it through area17/twill-api-client, with Typescript support!

That sounds great!

that sounds dope

Is there a way to get block editor previews without making a file for each block, like a global file that is gotten on all blocks?

I don't think there's a way to do this globally but one simple solution would be to manually map all blocks to one view :

$item->renderBlocks(true, [
    'my-block-1' => 'my.custom.view',
    'my-block-2' => 'my.custom.view',
    // ...
]);

You could wrap it in a helper function to avoid copy-pasting the view mappings all over.

👋 @pboivin, I think @Erwin isn't using renderBlocks in a headless context, but your comment would still work if done at the twill.php config level

Makes sense! I skipped over a few words apparently 😅

Ah i understand, thanks!

Do you guys know of a more effective way to do a headless block editor preview instead of storing every little edit in the cache and getting it via preview token in the iframe?

Have you tried a full-page (module) preview, instead of individual block previews?

Yes i have the the full-page preview working, now i'm just trying to get the block editor preview working. If i want to do it the same way as i'm doing the full-page previews it will store something in cache every time the input changes.

Ok I see, I wasn't sure if you had worked on the page preview yet. On a previous project, my colleague had disabled the block editor preview entirely. The client used the inline block editor (in the form) to enter content and the full-page preview was their way of seeing the blocks in context. It worked pretty well.

What's your concern with the cache? You can put it in the cache for a very short duration anyway, just enough time for your frontend to request it.

Any update on this? I need a new headless cms, right now it's sitting between Payload, Twill, Sanity and to a lesser extent webiny. Would love to see your teams approach to Headless. Twill in my opinion is the most polished in terms of what I deem critical features with Sanity second, but again any insights would be appreciated. Thanks.