Indeed, i also don't feel the need to create repeaters as it will quickly become cluttered

html tables are supported in the wysiwyg field with type

tiptap

which is becoming the default in Twill 3

it seems like @feelgoodinc you are looking for a datatable for content entry, not just displaying information in the CMS like @kalle right? Both are valid use cases though and we could definitely bring some functionality from the index into the form for displaying tables. For content entry repeaters are not that bad depending on how many rows/columns you need, you can also leverage the columns helper to display up to 3 fields side by side

Hi,

https://twill.io/docs/3.x/crud-modules/nested-modules.html#self-nested-modules I only seem to get nested slugs to work for when there is 1 nested. Like http://127.0.0.1:8000/nl/kennisbank/veelgestelde-vragen works but http://127.0.0.1:8000/nl/kennisbank/veelgestelde-vragen/wat-betaal-ik-voor-een-domeinnaam never works. And with twill 3 i dont seem to get the nested slugs to show up in the CMS permalink

I have also a setup like this in the model:

public function resolveRouteBinding($slug, $field = null)
    {
        $page = app(PageRepository::class)->forNestedSlug($slug);

        abort_if(! $page, 404);

        return $page;
    }

    // #region routekey
    public function getLocalizedRouteKey($locale)
    {
        return $this->getNestedSlug($locale);
    }

And combining that with whats told on https://twill.io/docs/3.x/crud-modules/nested-modules.html#self-nested-modules here, but i cant make it work 😮

nvm got it Updated the resolveRouteBinding:

public function resolveRouteBinding($slug, $field = null)
    {
        if (str_contains($slug, '/')) {
            // Get the last part of the nested slug.
            $slug = strrchr($slug, '/');

            // Remove the leading slash.
            $slug = ltrim($slug, '/');

            // Remove all forward slashes.
            $slug = str_replace('/', '', $slug);

            // $lastPart now contains the last part of the nested slug without any slashes.
        }

        $page = app(PageRepository::class)->forSlug($slug);

        abort_if(! $page, 404);

        return $page;
    }

->forNestedSlug($slug); is not working when there i a parent\child\grandchild for me. Now it seems to work as in the db the actual page title slug is the one there

That would potentially end up in conflicts between pages with the same slug at different level of nesting

we'll check forNestedSlug

Ah yes ofcourse. For now ill not do that then 😛

Twill Capsule case: how include in form.blade.php (in capsule) form root laravel resources view part of blade ? i need to include @include('admin.utils.builder.forms.seo._social') form root laravel resources view folder

Hi @AntonyPL that should work fine. Is it not finding that view? Is the capsule in a package or in your app folder?

@ifox in my app folder (default laravel resources). if i include this way - i couldn't see a some filelds included

so no error but you're not seeing the fields from that blade partial?

@ifox i need include this partial in my capsule Page

and this is my capsule form blade

right, makes sense, can't see why that wouldn't work really, but I'll try to reproduce

did you try another view with just one field to try if something in your view is causing an issue?

@ifox yes, i copy-paste this partial into pages capsule views and this same error - include doesn't work as expected

@ifox if i use default approach (via Model), included works as expected , they import from app resources folder

Does anyone have strong opinions on how to best implement multisite? I know Twill supports subdomain-based multisite but these will be all TLDs. Not sure whether to use nginx routing to Twill subdomains vs spatie/laravel-multitenancy with a multi db structure.

frontends can all be different TLDs, do you mean that the admin should be avail on those too?

yeah the admins will be separate

we're building a common site that we'll spin up copies of, each with their own domain and frontend styles

but otherwise common blocks and data structures, but separate content

Separate of course but you don't want admin.abc.example.com and admin.xyz.example.com, you'd like admin.whateverabc.com and admin.whateverxyz.com?

my point was that you can serve all the admins on the same domain but each frontend can be on its own completely different domain

ahhhh okay

so let's say Site ABC is public on siteabc.com with admin on admin.siteabc.landlord.com

cos it doesn't really matter where the admin is