Nova Font Awesome Field Laravel Package

Getting Started

Install the package and confirm the field class name from its README or vendor/mlsolutions/nova-font-awesome-field/src:

composer require mlsolutions/nova-font-awesome-field

Publish any package config/assets using the provider or tag documented by the package, then clear caches:

php artisan vendor:publish --provider="MlSolutions\NovaFontAwesomeField\FontAwesomeFieldServiceProvider"
php artisan config:clear
php artisan view:clear

Add a string column to the model’s table if you do not already have one:

$table->string('icon')->nullable();

The first practical use case is replacing a free-text “icon class” input on a Nova resource — for example a Category, MenuItem, or NavigationLink resource:

use MlSolutions\NovaFontAwesomeField\FontAwesome;

public function fields(NovaRequest $request): array
{
    return [
        FontAwesome::make('Icon')
            ->rules('nullable', 'string', 'max:255')
            ->help('Choose the Font Awesome icon used in the front end.'),
    ];
}

Store the full CSS class string, such as fa-solid fa-house or fas fa-user, so the value can be rendered directly in Blade without a lookup table.

Look first at:

1. The package README for the exact field class and config keys.
2. vendor/mlsolutions/nova-font-awesome-field/src to see which Font Awesome versions/styles it supports.
3. The published config to restrict the icon set to the styles your application actually loads.

Implementation Patterns

Basic resource field

Use the picker as a normal Nova field and keep the database column as a nullable string:

FontAwesome::make('Icon', 'icon')
    ->rules('nullable', 'string', 'max:255')
    ->hideFromIndex();

If the field supports configuration methods for icon style or version, set them explicitly rather than relying on package defaults:

FontAwesome::make('Icon')
    ->style('solid')       // confirm supported methods in the package source
    ->version('6');        // confirm supported methods in the package source

Display the icon on index/detail

Because the stored value is just a CSS class string, render it yourself for consistent presentation:

FontAwesome::make('Icon')
    ->displayUsing(function ($value) {
        return $value
            ? "<i class=\"{$value}\" aria-hidden=\"true\"></i> <span>{$value}</span>"
            : '—';
    })
    ->asHtml()
    ->onlyOnIndex();

For detail views, either render the icon with a custom displayUsing, or show the raw class string and let the front end handle rendering.

Normalize before saving

Icon values are easy to enter inconsistently. Normalize on fill so production data stays predictable:

FontAwesome::make('Icon')
    ->fillUsing(function ($request, $model, $attribute, $requestAttribute) {
        $value = $request->input($requestAttribute);

        $model->{$attribute} = $value ? trim($value) : null;
    });

If the field emits only an icon name rather than a full class, convert it to a canonical class in fillUsing and keep the full class string in the database.

Restrict choices to a known set

If the package exposes an options/config list, narrow it to the families and styles your site loads. This avoids invalid values and makes the picker faster:

// Example shape only — confirm the actual config keys.
'styles' => ['solid', 'regular', 'brands'],
'version' => 6,

For stricter control, validate against an allowlist:

use Illuminate\Validation\Rule;

FontAwesome::make('Icon')
    ->rules([
        'nullable',
        'string',
        Rule::in(config('app.allowed_icons', [])),
    ]);

Front-end rendering

In Blade, use the stored class directly:

@if ($category->icon)
    <i class="{{ $category->icon }}" aria-hidden="true"></i>
@endif

Keep the Font Awesome CSS version in the front end aligned with the version used by the Nova picker.

Reuse across resources

If many resources need the same picker, wrap it in a helper or trait:

protected function iconField(string $label = 'Icon'): FontAwesome
{
    return FontAwesome::make($label)
        ->rules('nullable', 'string', 'max:255')
        ->help('Select a Font Awesome icon.');
}

Gotchas and Tips

• Confirm the actual class and method names. The package is very small and low-adoption, so do not assume the namespace or fluent methods match other Nova icon pickers. Check the README and vendor source before rolling it out.
• Font Awesome CSS is the usual failure point. If icons appear as blank squares, the Nova front end or your application layout is not loading the matching Font Awesome CSS. Verify the CSS version (fa-solid/fas naming differs between Font Awesome 5 and 6) and that brand icons use the correct family.
• Validate before rendering as HTML. A stored class string rendered with asHtml() is an XSS vector if users can submit arbitrary values. Constrain the picker and validate against a known list.
• Normalize null vs empty string. Decide whether “no icon” is null or '', and normalize in fillUsing so queries and Blade conditionals behave consistently.
• Do not rely on index sorting/searching for icon classes. A CSS class string is not meaningful in a table column. Prefer hideFromIndex() and show the rendered icon or a short label instead.
• Clear caches after publishing config. Run php artisan config:clear and, in production, rebuild any cached config. Nova asset caching can also make the picker appear unchanged after an upgrade.
• Pin the version. With zero stars and no dependents, treat upgrades as code reviews. Commit the lockfile change and test the field in a staging Nova instance before production.
• Check Nova version compatibility. Confirm the package supports your Nova major version and PHP version. Nova 4/5 custom fields depend on the package’s compiled assets; if assets are missing or stale, the picker component may not load.
• Restrict large icon sets. A picker that loads every Font Awesome icon can feel sluggish. Limit styles/families to what the application actually uses.
• Extension point: fork or override. If the package lacks the exact behavior you need — custom icon sets, different value format, or a custom display — the stored value is simple enough that forking the field or writing a thin custom Nova field is usually cheaper than fighting the package.
• Test the stored value, not just the UI. Add a feature test that saves a resource with a known icon class and asserts the database value and rendered output.