Skip to main content

Customizing data before filling the form

You may wish to modify the data from a record before it is filled into the form. To do this, you may define a mutateFormDataBeforeFill() method on the Edit page class to modify the $data array, and return the modified version before it is filled into the form:
Alternatively, if you’re editing records in a modal action, check out the Actions documentation.

Customizing data before saving

Sometimes, you may wish to modify form data before it is finally saved to the database. To do this, you may define a mutateFormDataBeforeSave() method on the Edit page class, which accepts the $data as an array, and returns it modified:
Alternatively, if you’re editing records in a modal action, check out the Actions documentation.

Customizing the saving process

You can tweak how the record is updated using the handleRecordUpdate() method on the Edit page class:
Alternatively, if you’re editing records in a modal action, check out the Actions documentation.

Customizing redirects

By default, saving the form will not redirect the user to another page. You may set up a custom redirect when the form is saved by overriding the getRedirectUrl() method on the Edit page class. For example, the form can redirect back to the List page of the resource:
Or the View page:
If you wish to be redirected to the previous page, else the index page:
You can also use the configuration to customize the default redirect page for all resources at once:

Customizing the save notification

When the record is successfully updated, a notification is dispatched to the user, which indicates the success of their action. To customize the title of this notification, define a getSavedNotificationTitle() method on the edit page class:
Alternatively, if you’re editing records in a modal action, check out the Actions documentation. You may customize the entire notification by overriding the getSavedNotification() method on the edit page class:
To disable the notification altogether, return null from the getSavedNotification() method on the edit page class:

Lifecycle hooks

Hooks may be used to execute code at various points within a page’s lifecycle, like before a form is saved. To set up a hook, create a protected method on the Edit page class with the name of the hook:
In this example, the code in the beforeSave() method will be called before the data in the form is saved to the database. There are several available hooks for the Edit pages:
Alternatively, if you’re editing records in a modal action, check out the Actions documentation.

Saving a part of the form independently

You may want to allow the user to save a part of the form independently of the rest of the form. One way to do this is with a section action in the header or footer. From the action() method, you can call saveFormComponentOnly(), passing in the Section component that you want to save:
The $operation helper is available, to ensure that the action is only visible when the form is being edited.

Halting the saving process

At any time, you may call $this->halt() from inside a lifecycle hook or mutation method, which will halt the entire saving process:
Alternatively, if you’re editing records in a modal action, check out the Actions documentation.

Authorization

For authorization, Filament will observe any model policies that are registered in your app. Users may access the Edit page if the update() method of the model policy returns true. They also have the ability to delete the record if the delete() method of the policy returns true.

Custom actions

β€œActions” are buttons that are displayed on pages, which allow the user to run a Livewire method on the page or visit a URL. On resource pages, actions are usually in 2 places: in the top right of the page, and below the form. For example, you may add a new button action next to β€œDelete” on the Edit page:
Or, a new button next to β€œSave” below the form:
To view the entire actions API, please visit the pages section.

Adding a save action button to the header

The β€œSave” button can be added to the header of the page by overriding the getHeaderActions() method and using getSaveFormAction(). You need to pass formId() to the action, to specify that the action should submit the form with the ID of form, which is the <form> ID used in the view of the page:
You may remove all actions from the form by overriding the getFormActions() method to return an empty array:

Creating another Edit page

One Edit page may not be enough space to allow users to navigate many form fields. You can create as many Edit pages for a resource as you want. This is especially useful if you are using resource sub-navigation, as you are then easily able to switch between the different Edit pages. To create an Edit page, you should use the make:filament-page command:
You must register this new page in your resource’s getPages() method:
Now, you can define the form() for this page, which can contain other fields that are not present on the main Edit page:

Adding edit pages to resource sub-navigation

If you’re using resource sub-navigation, you can register this page as normal in getRecordSubNavigation() of the resource:

Custom page content

Each page in Filament has its own schema, which defines the overall structure and content. You can override the schema for the page by defining a content() method on it. The content() method for the Edit page contains the following components by default:
Inside the components() array, you can insert any schema component. You can reorder the components by changing the order of the array or remove any of the components that are not needed.

Using a custom Blade view

For further customization opportunities, you can override the static $view property on the page class to a custom view in your app:
This assumes that you have created a view at resources/views/filament/resources/users/pages/edit-user.blade.php: