Resources Laravel Package

Getting Started

crudadmin/resources is a support package for the CrudAdmin admin-panel generator. It ships the field/resource types and Blade partials that CrudAdmin renders into your Model UI (index tables, create/edit forms, show pages). You normally don't install it directly — it arrives as a transitive dependency of the core crudadmin package — but you do interact with it every time you customise a generated admin screen.

Minimal steps:

composer require crudadmin/resources
php artisan vendor:publish --provider="CrudAdmin\Resources\ResourcesServiceProvider"

Then in order:

1. config/resources.php (name may differ — check config/ after publishing) is the contract between this package and your app: field definitions, view paths, asset paths.
2. resources/views/ inside the package — these are the templates that render each field type. If your admin form looks wrong, the bug is almost always here.
3. src/ — the field/resource classes. Skim for an abstract base class (Field, Resource, AbstractField or similar); that's what you extend for custom field types.

First real use case: change how a single column renders in the admin index table. Publish the views, copy the relevant partial into resources/views/vendor/crudadmin/..., and override it. That's a 5-minute win and confirms the publish paths are correct before you attempt anything bigger.

Because the package has essentially no documentation and zero visible adoption, treat the source as the spec. Read composer.json first to see the Laravel version constraint and the auto-discovery provider — it tells you immediately whether the package is even compatible with your app version.

Implementation Patterns

Override, don't fork. Publish assets/views into resources/views/vendor/crudadmin/ and customise there. Laravel's view namespace resolution means your copy wins without touching vendor/. This survives composer update.

Register a custom field type. The common pattern in this family of packages is a config-driven field registry:

// config/resources.php
'fields' => [
    'text'     => CrudAdmin\Resources\Fields\Text::class,
    'textarea' => CrudAdmin\Resources\Fields\Textarea::class,
    'currency' => App\Admin\Fields\Currency::class, // your own
],

Extend the package's base field class, implement the render method, and point it at your own Blade partial:

namespace App\Admin\Fields;

use CrudAdmin\Resources\Fields\AbstractField;

class Currency extends AbstractField
{
    protected string $view = 'admin.fields.currency';

    public function format($value)
    {
        return number_format((float) $value / 100, 2);
    }
}

Column-to-field mapping. In practice you declare admin resources per model (often via an artisan generator) and the resource package resolves each attribute name to a field class. Keep field names byte-identical to migration columns — the package does not fuzzy-match, so published_at ≠ publishedAt.

Layout composition. Index/show/create/edit screens are assembled from partials. If you need a two-column form, don't rewrite the whole view — publish just the form wrapper partial and inject your own grid markup around the existing field partials.

Integration with the parent panel. The core CrudAdmin package resolves routes/controllers; this package only renders. Keep concerns split: put authorisation and validation outside these field classes. Do not stuff $request->validate() into a field type.

Asset pipeline. If the package ships JS/CSS, publish them and then route them through Vite rather than the package's raw <script> tags, so they participate in your build hash and cache-busting.

Gotchas and Tips

• Version lockstep. This is a sub-package of a monorepo-style project. Pin both crudadmin/* packages to matching versions ("crudadmin/resources": "1.x" alongside the same core major) or you'll get mismatched field class signatures and silent Class not found errors at render time.
• Silent rendering failures. Admin tables often swallow exceptions inside the Blade partial, so a broken field shows as a blank cell rather than a stack trace. When something renders empty, Log::debug() inside the field's format()/render() and check storage/logs/laravel.log — the view exception may be there even though the page is 200.
• View cache. After publishing or editing vendor views: php artisan view:clear. This alone fixes a large share of "my override isn't taking effect".
• Asset publishing is a one-shot copy. Re-publishing overwrites your edits. Keep published views in git and never run vendor:publish --force in CI.
• Validation lives in your FormRequest, not in the field definition. The package renders inputs; it does not enforce rules. Don't assume a select field restricts submitted values server-side.
• File uploads typically need a explicit disk: check the package config for a disk/directory key. Defaults often point at public with no symlink — run php artisan storage:link or images 404 in the admin preview.
• Extension points to probe first (in this order): config file → abstract base field class → published views → service provider bindings. If there's no documented extension hook, the service provider's register()/boot() usually reveals a singleton or a Field::extend() macro you can hook.
• Low-signal package. Zero dependents and no stars means no community answers when it breaks. Before building heavily on it, grep the core crudadmin package for how it imports these classes; a small adapter layer in app/Admin/ that wraps the package's field API will let you swap it out later without rewriting your admin screens.
• Debugging tip: dump the resolved field map with dd(config('resources.fields')) and dd(app(SomeFieldClass::class)) to confirm the container is wiring the class you think it is — auto-discovery occasionally fails silently in package-heavy apps.
• Localisation: labels are usually derived from the column name by the field class. Publish the partial and swap in __('admin.fields.'.$name) early if the app is non-English; retrofitting this across generated resources later is tedious.