[CLOSED] Filament v2 Consultation - What features would you like to see?

[danharrin]

Hey everyone!

Thanks for all the support over the past couple of months, Filament has had tons of love, and we've received some great contributions from the community. ❤️

While we've been able to implement many of your suggestions in the current version of Filament, some ideas require breaking changes. As we're so excited to see this product move forward and innovate in the admin panel community, looking forward towards v2 seems like the best path forward for development.

We currently have these features and changes lined up for v2:

• A fully typed codebase, requiring PHP 8+ (as union types will be required).
• Unit tests with PEST.

Forms (August / September 2021 Release)

• Custom hydration and dehydration behaviour.
• State updated hooks.
• spatie/laravel-medialibrary support. spatie/medialibrary package support? #283, [CLOSED] Filament v2 Consultation - What features would you like to see? #408 (comment)
• Allow resource fields that aren't saved, to allow for dependent select filters etc.
• A repeater field, allowing developers to embed several fields within a JSON column. Repeatable/flexible fields #230, [CLOSED] Filament v2 Consultation - What features would you like to see? #408 (comment)
• A block-based "flexible content" page builder field. How to create a custom field? #125
• Responsive breakpoint customization for form layouts.
• First day customisation for date picker. [CLOSED] Filament v2 Consultation - What features would you like to see? #408 (comment)
• A multi-file-upload field based on the repeater.
• Input masking. [CLOSED] Filament v2 Consultation - What features would you like to see? #408 (reply in thread)
• Allowing the tags input field to write to JSON and spatie/laravel-tags. TagsInput relationship #400
• A multi-select field.
• Allow customizing file name for uploads. Allow specifying file name for uploaded files #544
• A BelongsToManySelect field built upon the multi-select field. [CLOSED] Filament v2 Consultation - What features would you like to see? #408 (comment)

Tables (September / October 2021 Release)

• Record count in footer.
• Advanced filtering, with support for applying multiple filters, and filter parameters. Support for Multiple Filters #32
• Hiding columns on various responsive breakpoints. [CLOSED] Filament v2 Consultation - What features would you like to see? #408 (comment)
• Select all records or just records on that pagination page. [CLOSED] Filament v2 Consultation - What features would you like to see? #408 (comment)
• Bulk table record actions. Bulk actions #236, feature: bulk table actions #297

Admin panel (November / December 2021)

• Sidebar navigation groups. [Feature] Add ability to create Menu groups #384
• New pages templates for viewing resource records. "View" or "Show" page for resource #146
• Global search. [CLOSED] Filament v2 Consultation - What features would you like to see? #408 (comment)
• Override global scopes for resources. Disable global scopes #442
• spatie/laravel-package-tools support for plugin service providers. PluginProvider to extend Laravel-package-tools #249
• Manage translatable content using spatie/laravel-translatable. laravel-translatable support #373
• Dashboard widget templates.
• Dashboard layout configuration. [CLOSED] Filament v2 Consultation - What features would you like to see? #408 (comment)
• Manage settings using spatie/laravel-settings.
• Easier relation manager customization. Paginate relations #380
• Ability to manage BelongsToMany pivot data with relation managers. Adding additional column data to pivot table when attaching records #103, Is Many To Many possible in a Filament form? #287

Ecosystem

• A plugin and theme marketplace, where authors can sell and distribute their own Filament products to the community. Plugin "Marketplace" #247
• Documentation screencasts. [CLOSED] Filament v2 Consultation - What features would you like to see? #408 (comment)

Please let us know in the replies what other changes you'd like to see in v2! These can be existing pain points, new features, inconsistencies you have noticed, and any breaking changes. 👇

[wdandrewjames]

It would be nice to be able to save uploaded images with multiple sizes from the form builder. E.g. 250px, 500px.

[danharrin]

How would the multiple sizes be stored in the database?

[zhanang19]

I think this would be done when use spatie-medialibrary package using their conversions features

[danharrin]

Cool idea, added to the list!

[zhanang19]

I recommend to add spatie-medialibrary package support

[danharrin]

Ah yes, adding this one to the list!

[danilopolani]

What do you mean by Dashboard widget templates? I don't know if this is included in that point, but I'd love to see an easy way to organize my dashboard widgets, e.g. placing one full-width widget at the top, two half-columns below and so on. Currently you can't decide the size nor the position.

Plus: having the support of spatie/laravel-package-tools for PluginServiceProvider (see #249)

[danharrin]

Both great ideas, added to the list!

[yob-yob]

will the block-based page builder field let me embed an iFrame?

what is a block-based page builder field? and how does it look like? is it something like Editor.JS?

[ryangjchandler]

will the block-based page builder field let me embed an iFrame?

what is a block-based page builder field? and how does it look like? is it something like Editor.JS?

The block editor will be similar to the repeater field, but you can use multiple types of blocks.

The correct name is probably flexible content.

[roni-estein]

Some screencasts ;) I love docs. But I love you doing the hard work for me! And I’m willing to pay you every month!

[danharrin]

Added to the list!

[qalainau]

A repeater field, allowing developers to embed several fields within a separate database table .

[danharrin]

Currently we have plans to implement this in a JSON structure in one column, is this what you mean?

[qalainau]

It means to store data in a different table.
For example, in the case of orders and purchased products, we need to search the purchased products table as well as the orders table.

[danielbidala]

@qalainau you should use realtions for this (e.g. order hasMany orderitem, orderitem belongsTo order)

[pqr]

Define fields once, render them everywhere: as readonly text in table (list route), editable input on edit route, readonly text on view route

[ryangjchandler]

You mean something similar to Nova, where it uses the field definitions to construct the columns etc?

[danharrin]

Does anyone have an example of this feature I could see?

[pqr]

Yes, like Nova fields: https://nova.laravel.com/docs/1.0/resources/fields.html#defining-fields

Main reason: in 90% of admin panel cases you have the same fields for both screens: for table and for detailed view. Some fields like large content usually are not shown in table, but others should be available on both screens with the same formatting rules and lables/column names (like dates, amounts, numbers, names, addresses, etc). Defining them once reduces boilerplate.

[ryangjchandler]

@danharrin Perhaps the columns for resource tables could be optional. I get the benefit of not needing to define columns & fields, inside of Filament at least.

[MACscr]

I have a few requests. 1) manually able to edit datepicker fields 2) relatable fields without having to save first 2a) tag like field where you can select multiple values from a related table (belongstomany)

[MACscr]

Input mask options (cleave?)

[ryangjchandler]

Input masks is definitely something we'd like to look into. Whether Cleave is the right option, I don't know.

A simpler approach would be using RegEx since that would allow users to define custom patterns, we could then just provide some defaults for currency, phone numbers, etc.

[MACscr]

Yep, doesn’t have to be cleave, they just do it well and simple to use without introducing too much complexity. I understand not wanting to use it too though.

[danharrin]

Added these ideas to the list, thank you!

[roni-estein]

I know you've covered responsive but some fine grain control over how tables are rendered in responsive. It's a tricky issue to be sure, but to make this really workable on mobile, which is an unfortunate requirement for lots of internal app as we use them more and more on the go, being able to leave some columns out on some views, or render some columns over one and other like in this example name and email.

[roni-estein]

not for everyone I'm sure, but on mobile, or perhaps in other views as well I prefer it. But if I could attach it to a row click event, and not be forced to show the default on each row, I could populate that modal however I wanted. Or I could generalize it to some common drop down pattern too.

[roni-estein]

There are places where its silly, a waiting room that has a name and arrival time a button, doesn't really need that treatment. I guess it's just choose the right way of handling the rows you are presented with. It would just be good if there was a sensible default but some options to do other things, where it made more sense.

[danharrin]

So some way of defining a "details" modal for each record, that would allow you to perform common actions without leaving the table view?

[roni-estein]

Yeah, its sounds not awesome when you say it :) I use lots of modals. Click a row, open a modal that either options to open more modals, or resolve the situation, and then close up. Unless there is a real need for me to leave the main workflow I try and live on the index page.

Consider, Vaccine land for 3 dis-similar use case examples.

1. Filament for sure. A office worker greeting you, either adding / verifying your name and details to the vaccine queue for the day at a specific clinic. Has the regular add / edit as currently implemented.

2. Filament probably..., people in a waiting area, you pull your name off the queue send them to another space for an injection its just a click questions. You don't have add rights, and you are not supposed to be editing. You are taking temperatures and asking specific questions. Instead of an edit link on the side each row you might have an "confirm" or "re-book" if they are currently ineligible for the vaccine. Each might open up a different modal 1 saying 1 room they were sent to or even telling them where to send the next person and the other a quick and easy way to rebook them for another date. So we've removed links from the rows and added two buttons.
   This example could just as easily have been the dropdown menu if there were more options involved or a modal with a few text and buttons, it's just a control flow example.

3. Not sure maybe Filament but in a more livewire way, something like a moving nurse or doctor doing appointment or rounds, they have ward index and specific order of people great we are at a table, but the information is too varied to be mobile tabular, so they would click on a person and instead of a modal move to some full component that is the home base for that person on that visit, the chart, with some options, view history, current stuff, order stuff etc... a place for them to move around from component to component, before doing something or nothing, and then back to that original table.

These are super contrived examples to try and illustrate use cases where I might choose one over the other in handling mobile screens. If you think one example is dumb and they are, make up a better one and substitute it when you answer :)

The idea is handling the action on the row itself should be programatic. In 70% of the rows, edit / delete might be good enough. (on mobile I'd always default to either a row click or a icon indicating but I prefer the whole row) for the left over edge cases it just depends what they are doing, and what makes sense in that situation. I hope this clarifies. There is no one good answer. And Ideally there should be some options.

That was long I need a coffee! 😁

[danharrin]

Thanks for these examples Roni, we'll keep these in mind when planning that feature and make sure to get back to you if we end up extending the customization options there.

[raphael-evolutap]

Maybe export(csv, xlsx, etc) option to table using https://github.com/Maatwebsite/Laravel-Excel or other package

[sbc640964]

@danharrin What about this feature, oh how important it is to me now

[danharrin]

You can do this already, using a bulk action and any existing Excel package :)

[danharrin]

Just return your file from ->action(), afaik

[sbc640964]

@danharrin
In action in the head is it possible to get the query without the paginate?

[danharrin]

Yeah, $livewire->getFilteredTableQuery()

[johncarter-]

Can you tell me a bit more about the "Style customisation using Tailwind plugins, rather than overriding Blade views."?

I've not seen this done before and like to understand it before I wade in with some FRs for layout / colour / font customisations.

[johncarter-]

Anyone else who didn't know: https://tailwindcss.com/docs/plugins#adding-components

[danharrin]

At the moment, all styling is in the markup as it relies on utility classes. This is problematic to customise, as you need to copy the entire Blade view and lose improvements that Filament provides when you upgrade.

Instead, we'd look at creating Tailwind plugins for Filament, which allow you to customise the styling of the dashboard using tailwind.config.js. Instead of utility classes used in Blade, we'd use new customised classes generated by the Tailwind plugins.

Hopefully this clears things up a little!

[MACscr]

Not sure if laravel spotlight can do both, but global search would be nice. Something like so: litstack/litstack#196

[danharrin]

Added to the list!

[tanthammar]

Add "firstDayOfWeek(1)" method to date picker. Where I'm from "Monday" is the first day of week :)

[danharrin]

Thank you Tina!

[tanthammar]

I can make a PR?

[danharrin]

I think we should make it a configuration option of the forms package instead of a method, what do you think? I would accept a PR :)

[tanthammar]

Did a PR #409 that also removes the need for manual translation files.

[danharrin]

Awesome, thanks!

[pqr]

Ability to reorder (move left or right) and show/hide columns in table via UI. So each user could setup table layout based on his needs.

Also nice useful feature I saw in different admin panels: ability to save table layout setup under given name and then quickly switch between saved layouts.

For example I cloud setup two table layouts (via UI for my particular user):

[assume we have Invoices CRUD module]

1. Layout name = Financial
   Columns = Inv No | Doc Date | Customer | Invoice Amount | Outstanding Amount | Paid Status

2. Layout name = Management
   Columns = Inv No | Doc Date | Customer | Paid Status | Customer's responsible manager | Our responsible manager | Last contact date | Dispute comments

[rabol]

Option to have 'read-only' list
e.g. for viewing logs or activities

Sure I can create a resource and then just don't hit create :)

[rabol]

the problem with Filament::can() is that it returns true if you are admin :)

 public function can($action, $target)
    {
        $user = $this->auth()->user();

        if ($user->isFilamentAdmin()) {
            return true;
        }
        
...

[mahmoud-m-abadi]

when you set canCreate = false; nobody can create in the resource!

[rabol]

no. and that is the whole point

here is the solution:override the canCreate() of the list page

<?php

namespace App\Filament\Resources\AuditLogResource\Pages;

use App\Filament\Resources\AuditLogResource;
use Filament\Resources\Pages\ListRecords;

class ListAuditLogs extends ListRecords
{
    public static $resource = AuditLogResource::class;

    public function canCreate()
    {
     return false;
    }


}

[ryangjchandler]

Filament admins have all permissions by default. This is intentional and we believe perfectly normal.

[rabol]

Yes, that is perfectly okay, and documented if I'm not mistaken

I was just looking for a way to make 'read-only' list where nobody could create or delete

[ralphjsmit]

Wow, there's a ton of good ideas here already and I'm happy to see that you're adding them to your roadmap.

I'd like to propose one new thing in addition to the other proposals: adding a new component to Forms: buttons. The concept would be very simple, e.g. a user clicks a button on the frontend (edit form / table) and a PHP function runs in the backend. This would be very useful for things like a button to send a certain sort of notification.

Essentially it would boil down to just wire:click="function", but it would allow a lot of versatility.

Would be great if this could be considered.

[danharrin]

Ah also, you can add a new action button to the form's footer, but this process requires a bit of digging to do as it's not documented. Will be a good future docs section & video tutorial.

[ralphjsmit]

Thanks for coming back to me! Yes, I knew that it was possible with a custom element, but I thought that a native element could be integrated better and easier in the UI, plus perhaps in the table.

Totally understand it this doesn't come on the roadmap, it was just a suggestion.

[danharrin]

Ah, we also have table support already! Check out recordActions().

[ralphjsmit]

Ah, that's cool! Is that perhaps documented already somewhere?

[titantwentyone]

@danharrin I'm just looking into this side of Filament and making some headway into figuring out how this is all wired up. Is the current way of this working likely to change in v2? If not, I can (when I have time!) put together some docs on how to add custom buttons inc creating actions etc?

[fawzanm]

It'd be nice to have permission library added. Spatie's package has a nova package, if we can mimic it, we could have an awesome scaffolding.

[danharrin]

Could you point me towards which Nova package you mean? I found a couple.

[bernhardh]

Spatie has only one I think: https://spatie.be/docs/laravel-permission/v4/introduction

[fawzanm]

This is the nova package. https://novapackages.com/packages/insenseanalytics/laravel-nova-permission

[ManojKiranA]

Check the below plugins

1. https://github.com/reksmeysrey/filament-spatie-roles-permissions
2. https://github.com/bezhanSalleh/filament-shield

[Blackpig]

Hi,

Not sure if this has been suggested or not - but the ability to add configurable action buttons to a form/page - preferably at the top. At the moment, with a bit of hack, I can add buttons next to the 'Save' & 'Cancel' at the bottom of the form but it would be good to have a kind of configurable 'Actions' bar - next to the 'Delete' button.

[rabol]

Keep the original css and add filament 'theme'
If one copy paste some components they normally does not look correct as the original tailwind classes has been modified.
I do appreciate the theme of Filament, but it would be great to be able to use standard Tailwind components, and then add the Filament theme to them when needed.

[ryangjchandler]

https://tailwindcss.com/docs/just-in-time-mode

The Tailwind CDN does use the JIT mode.

[ryangjchandler]

@ryangjchandler could you elaborate on what is a 'pretty big hit on page speed'? Did it went from say 1s to 3s? Or even worse?

It went from 150ms load times to about 4s on a larger application I tested it on.

[ryangjchandler]

@rabol We're hoping to improve the extensibility of Filament's styles in v2. The issue with the current version is that we purge the Tailwind file, removing all the classes (we don't actually modify any Tailwind classes).

@ryangjchandler Can't you provide an artisan command in the Filament package to run after the package is installed?

I'd say that making the Tailwind config a publishable resource would make sense.

[rabol]

As a workaround now:
What about adding a @stack('before-styles')
I have just tried to include a tailwind.css - full, not purged - before the filament.css and that seems to have a okaysish effect

I'm trying to use a accordion component, and standard filament css somehow screws it up

here is the component

<div x-data={show:false} class="rounded-sm">
    <div class="border border-b-0 bg-gray-100 px-10 py-6" id="headingOne">
        <button @click="show=!show" class="underline text-blue-500 hover:text-blue-700 focus:outline-none" type="button">
              {{$entry->header}}
         </button>
        </div>
        <div x-show="show" class="border border-b-0 px-10 py-6">
             {{$entry->body}}
        </div>
</div>

[HollyIT]

A little late to the party here, but I went ahead and made a package that actually accomplishes this. It's a little hackish, in that I have to decorate the FilamentManager, but in a nutshell, it simply copies the files over to public/filament/assets. There are also directions to run the command in composer.json scripts when you do an update, plus some cache-busting stuff and events to alter the files.

https://github.com/HollyIT/filament-static-assets

It also provides a couple of events to alter the files before rendering out their tags in the template. The main reason for this was limiting what assets get loaded on each page, especially heavy things like WYSIWYG editors.

I'm sure there are better ways to accomplish this, but I've been using this for a couple of months in some client projects and figured I would go ahead and split it out into its own package for others to use.

[martinmildner]

It would be super helpful if you could use attributes of a related model as the "BelongsToSelect" field label:

// form
BelongsToSelect::make('game_id')
    ->relationship('game', 'title')

// game model
public function getTitleAttribute()
{
    return $this->home . ' vs. ' . $this->away;  
}

[danharrin]

This is a very requested feature, but the reason this is not already implemented is because attributes are not performant with many records. I will create a video tutorial about populating the normal select with custom options. You could probably work it out yourself too, pass a key => value array to Select::make()->options().

[martinmildner]

Thanks, that's exactly how I did it.

[ralphjsmit]

I love the package, but one thing that I find very tedious is having to add Columns and Input fields for every model. If I have 5 or more models that I want to make, this is a very boring and slow task.

It would be great if Filament could automatically detect all the models properties and already scaffold out the tables and fields. This would allow to tweak it a little afterwards, but remove a lot of the very boring work.

As an example, the Invoker Laravel tool automatically discovers all the columns belonging to a certain model.

I dearly hope you can implement this, as it would reduce the very biggest pain point for me when using Filament.

[rabol]

Make is a command to scaffold and not a runtime thing

[ryangjchandler]

Most admin panel packages for Laravel will required you to build out the fields & columns yourself (e.g. Nova). I agree with @rabol that we could make this a generator command or similar, perhaps even do it as part of the filament:resource command.

[bernhardh]

This should be a artisan command not a runtime magic. Maybe an extra param to filament:resource. In most cases you do not want all db fields in your lists (or forms) an form type guessing will not result in perfect results.

[MACscr]

Nova is awful and most people hate it. Definitely don't use it as an example of doing things right. Litstack is one of my favorites when it comes to its field layouts and options: https://litstack.io/docs/3.x/fields/input

[ralphjsmit]

Agree with @rabol, I absolutely had this in mind as an artisan command. So I think that performance shouldn't really be a thing if you ask me.

@bernhardh I disagree with you, I too don't want all fields. But I want most of them. And deleting a few fields and tweaking some others is just not as much work as creating all the fields and table columns manually.

I'm not asking for anything superspecial, but if you'd get the below two rows for each field, automatically detected, that would save me tons of time.

Components\TextInput::make($fieldname),

// Perhaps even detect ->required() from NULL / NOT NULL columns, would be extra awesome. Or things like ->unique() for UNIQUE columns.
// Or something else appropriate

And:

Columns\Text::make($fieldname),

// Or whatever is appropriate, but it will mostly be Text.

Then you have something scaffolded out very fast and you only need to tweak it a little – saving you hours in total.
Of course you could make this optional by adding it as a parameter to the artisan command, so you can choose.

[raphael-evolutap]

IDK if already have these options.

Option to enable Query String (https://laravel-livewire.com/docs/2.x/query-string) on resources. It could have default options with all possible variable like 'search', 'sortColumn', 'filter', etc, or we can pass an array.

It is usefull to share links with params.

[danharrin]

On your List page class, you could add the query string array with those property names :)

But I agree, it would be nice to have that as a default. Feel free to PR.

[titantwentyone]

I might be a little late to the party and couldn't see this mentioned before but a "Dark Mode" would be great. Most of my dev environment is in dark mode and Filament (as beautiful as it is!) is a little jarring. Just trying to save my eyes...!

[danharrin]

This is definitely something that would be nice to have, but it would be too much work to get done in time for the v2 release. It would also require contributions from the community, as I only have limited time to work on the project myself.

If anyone is interested in working on this, the first step is to submit a PR that adds dark mode to filament/forms v2.

[martinmildner]

The possibility of deciding for each resource relationship whether the edit screen should be opened in a modal or on a separate page.

[robertorinaldi-dev]

Hi, is there also a plan to add drag & drop sorting to multiple upload?
Thanks!

[MACscr]

Whats the point of sorting during upload?

[robertorinaldi-dev]

Obviously not during upload, but on edit page it could be useful in my opinion

[roni-estein]

I may have replied in the wrong area 😳 on a mobile 🤫

[roni-estein]

That other thing I just did never happened 😬 ... moving on

I brought this up briefly in person Dan, and have talked about it with a few other people since, but I think we are all denying ourselves the benefits of widely used library browser caching in favour of our build processes. I'd love to see an extracted filament.js served from a cdn. But it would be even better to have the option of also using the cdn for itemized component's where possible.

I've been toying with this for a couple of days and the build speed is insane only compiling my local js and css. The server load seems to be lighter and there isn't much of a downside. Though I do use cloudflare and varnish and other such services for asset caching speed, there is a nice benefit to it already just being on your local machine because another site also used alpine or livewire etc...

[MACscr]

Definitely don't want to use any CDN's for admin dashboards. Little to no benefit and more a security concern than anything. CDN's aren't automatically the best thing to use. They are great for frontend sites that need to offload the http requests, but in general, its definitely not always the best route to go. I would definitely disable CF proxy for any backend interfaces as well.

[molcsab]

Another nice feature would be the ability to create inline relations, like in Nova:
Creating Inline Relations

[egyjs]

I recommend to add spatie/laravel-translatable package support

[danharrin]

We've already built this into v2 :)

[egyjs]

I tried to build a project yesterday with admin V1 , but unfortunately Many Fields doesn't exist in version 1 so I must wait until v2

Keep the good work ❤️

[danharrin]

What do you mean by many fields?

[egyjs]

For example repeater field doesn't exist

[danharrin]

Ah, yes. The repeater field is in v2 👍

[chiiya]

Maybe this is already possible in V2, but one thing we definitely need is easily customizable search. I'll give a few example use cases:

• Large datasets. In one of our projects we have 1M+ records that need to be searchable through the admin. At least with MySQL you can't use LIKE %search% queries with that amount of rows, because indexes won't be used. Best you can do is LIKE search%.
• Searching through fields not listed in the table, though I could solve that with hidden columns on the table.
• Searching through relationships, or other custom search functionality.

In general, any database queries (e.g. index query) should be easily customizable.

[danharrin]

Hey! This should all be possible now in v2. If you're unsure how to override a specific query, please open a separate discussion :)