Ideas for additional features

[JVariance]

• Modal: It can be frustrating when you've made changes to fields, then click outside the modal and lose all your changes. Two solutions come to mind:
  a) Save on an outside click
  b) Show a warning on an outside click, with a button to save
  This could also be an opt-in feature, for all Mason fields or individual ones.
• Duplicate a brick:
  a) via the outline?
  b) via an additional button in .mason-block-controls?
  c) via Shift + click on the Add button? ACF/SCF handles it this way in repeater fields.
• Presets: a sticky button at the bottom, or a tab next to "Bricks" and "Outline" (with overflow-x), that shows presets: groups of bricks that are inserted at once.
• Copy and paste:
  • Classic shortcuts (Cmd/Ctrl + C, Cmd/Ctrl + V) that copy one or more bricks and paste them after the selected brick
  • A "Clipboard" item (mason-actions-brick) in the sidebar to drag and drop the brick(s) from the clipboard
  • A "Clipboard" item (mason-brick-picker-brick) in the "Add brick" popup
• Select multiple bricks with Shift/Cmd + click, so they can be deleted, copied or pasted at once, both in the preview and in the outline.
• Delete key shortcut to delete one or more selected bricks.

What do you think?

---

Copy-paste of my comment from feat: container bricks that hold other bricks - #73:

One alternative came up while thinking about your answer, and I think it fits your direction: brick parts.
Instead of bricks inside bricks, a developer marks fixed areas in a brick's own view as parts, and groups the brick's fields by part:

<section>
    <header data-mason-part="heading">
        <h2>{{ $heading }}</h2>
        <p>{{ $subline }}</p>
    </header>
    …
</section>

In the preview, clicking a part opens an edit modal with only that part's fields, rather than the whole brick form. A part can optionally be hidden, but never removed or moved. The form for configuring the brick itself remains clean.

The stored content stays flat: everything is still in the brick's own config.
The layout stays with the developer. Authors can only edit (or hide) what the brick offers.
It helps with the one downside of the Repeater/Builder approach: bricks with a lot of structure end up with long forms, and parts let authors edit the piece they clicked on.

A typical case for us: an accordion(-section) whose heading has its own fields (Tagline, heading, subline, (to conditionally render a hgroup instead of a simple heading), level, visually hidden). Today that goes into one long form with the accordion items.

Would something like this be interesting for Mason? If so, I'm happy to sketch out the API first before writing any code.

It might look something like this (although it would probably be nicer to display the name of the element—in this example, “heading”)

[awcodes]

Thanks for writing these up, and for asking before building. That makes this much easier. Going through them in order:

Clicking outside the modal. I agree losing changes this way is frustrating, but I don't want an outside click to save. Everywhere else in Filament it means cancel, and in insert mode it would add a brick the author may have meant to discard. A warning dialog is a lot of machinery for the problem. I'd rather make closeModalByClickingAway(false) the default for the brick action, so only Cancel or Esc closes it. Bricks can still change that in configureBrickAction(). Happy to take a small PR for that.

Duplicate a brick. Yes, this is the one I'd most like to have. I'd put it as a button in the brick controls and an action in the outline. I'd skip Shift + click on Add: it's hard to discover, and it gives Add two meanings. One thing it needs: some config values shouldn't be copied as they are, like anchors or ids, slugs, or upload paths. So I'd like a small hook on Brick (something like duplicateConfig(array $config): array) that lets a brick reset those. It would pass the config through unchanged by default.

Presets. I can see the use, but it's close to the templates side of #73, and inserting several bricks at once with configs that skip their forms brings its own problems. Not for now. If it comes back, I'd rather add a general "insert these bricks at this position" hook a package could build on than presets in core.

Copy/paste, selecting several bricks, the Delete key. I'm going to pass on these for now. Selection is built around a single brick in both the editor and the preview, and selecting several would touch most of it. That's the part of Mason I'm most careful with. Pasting also means trusting content from another field, record or app, which would need checking on the server against the field's bricks. While looking at the keyboard side I also found and fixed a bug (#83): the undo/redo listener acted on every Mason field on the page, so one Cmd+Z undid both. Shortcuts now act only in the field that has focus, and any new ones should work the same way.

Brick parts. This fits the direction much better than containers did, thanks for thinking it through. My concern is the partial form. Saving only one part's fields breaks as soon as a field is required elsewhere in the form, or a field depends on another part through visible() or Get. Making parts clickable in the preview also means reworking how the preview handles the pointer, and we've only just got that stable. And since toHtml() renders the site too, the part attributes would end up on the frontend.

What I'd be open to is a lighter version: clicking a part opens the full brick form, scrolled to that part's Section or with its Tab already open. Authors still land on the piece they clicked, there's one form to validate, and nothing needs merging. If you want to sketch an API for that, I'm happy to look.

So in short: duplicate and the outside-click default are yes, parts as scroll-to-section is maybe, and the rest is not for now.

Thanks again!

[JVariance]

What I forgot:

1 | Show layout toggle

Note

PR submitted in #88 .

My preview layout wraps the bricks in the site's header and footer, but authors usually want to see the bricks alone. I built a toggle for this in my app and think it would fit in core. "Layout" because the marked parts are exactly what the field's previewLayout() adds around the content. That isn't always a header and footer: it could be an email frame, the rest of a product page or a device mockup.

Mason::make('content')
    ->previewLayout('layouts.mason-preview')
    ->layoutToggle()
    ->layoutToggleLabel('Show header and footer') // optional, defaults to "Show layout"

The parts are marked in the preview layout:

<div data-mason-layout>@include('partials.header')</div>
<main>@include('mason::iframe-preview-content', ['blocks' => $blocks])</main>
<div data-mason-layout>@include('partials.footer')</div>

Implementation, following the colour mode toggle:

• layoutToggle(bool|Closure $condition = true), hasLayoutToggle() and layoutToggleLabel(string|Closure|null) in Mason.php, plus a toolbar button with a translated default label
• The state is kept in local storage (mason-show-layout), and a setShowLayout message goes to the iframe
• The iframe script sets the class on <html> as soon as it runs, so the header doesn't move the content after a reload and the scroll position stays put
• @masonStyles adds html:not(.mason-show-layout) [data-mason-layout] { display: none; }
• While the field is empty, the "Drop blocks here" placeholder is positioned inside the content area instead of lying over the header

The toggle is off by default, and the docs note that it only makes sense with a custom previewLayout(). I have this working on a branch. Would you accept a PR?

---

2 | limit how often a brick can be used

Note

PR submitted in #89 .

While building duplicate I wondered about bricks that should only appear once, such as a hero or a page meta brick. An opt-out for duplicate alone would not help, since the brick could still be added from the sidebar, the picker or the add line. So I'd rather suggest a general limit, similar to Gutenberg's supports.multiple:

public static function getMaxInstances(): ?int
{
    return 1; // null (default) = no limit
}

Once the limit is reached:

• the brick is disabled in the sidebar and the picker, with a short hint
• its duplicate control is hidden
• BrickAction (insert) and DuplicateBrickAction refuse it on the server
• optionally, the field fails validation on save, as the state comes from the client

Values that only need to be unique (anchors, IDs) are already covered by duplicateConfig(), so this is only about the number of bricks.

Would this be something you'd consider? If so, I'd sketch it after the duplicate PR.

[JVariance]

For further feature ideas see the comment above.

---

Regarding "parts as scroll-to-section":

Sketch: brick parts that open the form at the right place

Note

PR submitted in #91 .

Following your suggestion, here is a sketch for the lighter version: a part only tells the editor where to open the full form.

In the brick view, a helper marks an element as a part. It outputs data-mason-part="…" in the editor preview only, so nothing reaches the front end or the entry:

<header {{ mason_part('heading') }}>
    <h2>{{ $heading }}</h2>
</header>

The part name is the key of a component in the brick's form: a field name, or the ->key() of a section or tab. No extra registration:

Tabs::make()->tabs([
    Tab::make('Heading')->key('heading')->schema([...]),
    Tab::make('Media')->schema([
        FileUpload::make('image'), // part "image" works too
    ]),
])

In the preview, a click on a part of the selected brick opens its form with a part argument. The first click still only selects the brick, and the edit control and double-click behave as before. So the pointer handling only gains one closest('[data-mason-part]') check in the existing click handler.

In the form, Mason finds the component with that key. Once the modal is open, it dispatches Filament's own expand event up the tree from it, the same contract Filament uses to reveal validation errors. That way tabs switch and collapsed sections open without Mason knowing about either. Then it scrolls the component into view and focuses its first input. If the key does not exist, the form simply opens as usual.

Because the whole form is submitted, required fields and visible()/Get dependencies keep working.

One open point: the helper needs to know that it is rendering inside the editor preview. Today a brick can only guess from $data being null, which no longer holds once a field uses previewData(). I'd add an explicit flag that IframeRenderer sets while it renders, and mason_part() reads. It could also be public (e.g. Mason::isRenderingPreview()) for bricks that render differently in the editor.

Does this direction work for you? Happy to adjust names before I start.

[awcodes]

Thanks for all of these. I've gone through each one, and I'm not merging any of them as they are yet. Notes are on each PR. A few things apply to most of them:

• The compiled workbench styles are no longer committed. workbench/resources/dist/ is now git-ignored (chore: stop committing the compiled workbench styles #94), and composer build/composer serve compile it with npm run build:workbench. Without a composer.lock, every rebuild carried whichever Filament version was installed, so most of the theme.css diffs were Filament's CSS, and they caused most of the conflicts between these PRs. When you rebase onto 3.x, please drop your changes to workbench/resources/dist/theme.css and app.css.
• resources/dist/mason.js conflicts across every PR that touches the JS. I'll rebuild it after each merge, so whichever lands later will need a rebase.
• Please check with me before building the next feature. feat: show or hide the preview layout with layoutToggle() #88 and feat: limit how often a brick can be used with getMaxInstances() #89 came in before I'd replied in Ideas for additional features #82, and feat: turn off adding, moving and deleting bricks with addable(), reorderable() and deletable() #93 is close to the locked structure I passed on in feat: container bricks that hold other bricks #73. I'd rather we agree on direction first, so you don't sink time into something I end up declining.