Wp Eloquent Models Laravel Package

Getting Started

This package scaffolds a Laravel User model (plus its supporting migration/config) so you don't hand-roll auth plumbing. Release 0.4.5 is a small, non-breaking change: the published User stub now ships a $fillable array instead of relying on $guarded.

1. Install: composer require <vendor>/<package> and confirm the service provider is auto-discovered (php artisan about or php artisan package:discover).
2. Publish what you need, tag by tag — typically config first, then migrations/model stub:

   php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider" --tag=config
   php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider" --tag=migrations
   php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider" --tag=model
   

3. First place to look: config/<package>.php — it usually controls the model class, table name, and whether the stub is used at all.
4. Run php artisan migrate and you have a working users table.
5. First use case: replace the stock App\Models\User with the published one (or point the package config at your own class), then register a user through your auth flow and verify mass assignment works:

   User::create(['name' => 'Ada', 'email' => '[email protected]', 'password' => bcrypt('secret')]);
   

If you already published the model stub in an earlier version, 0.4.5 will not change your file — see Gotchas.

Implementation Patterns

Keep the model in your app, not in vendor. The standard pattern is: publish the stub once into app/Models/User.php, then own it. Treat the package's version as a reference implementation, not a runtime dependency.

Fillable as the single source of truth for mass assignment. With 0.4.5 the stub looks roughly like:

protected $fillable = [
    'name',
    'email',
    'password',
];

Add every column you intend to pass to create(), update(), firstOrCreate(), factories, and seeders. If you add a column to the migration, add it here in the same commit.

Extending rather than editing. If the package resolves the model from config, you can subclass instead of copying:

// config/package.php
'models' => ['user' => App\Models\User::class],

namespace App\Models;

use Vendor\Package\Models\User as BaseUser;

class User extends BaseUser
{
    protected $fillable = [...BaseUser::FILLABLE, 'company_id', 'timezone'];
}

Request-to-model flow. Use validated data plus fillable as the guard rail:

$data = $request->validate([
    'name'     => ['required', 'string', 'max:255'],
    'email'    => ['required', 'email', 'unique:users'],
    'password' => ['required', 'confirmed', 'min:8'],
]);

$user = User::create([
    ...$data,
    'password' => Hash::make($data['password']),
]);

Seeder / factory integration. The factory should only set fillable attributes so make() and create() behave identically; anything non-fillable (roles, flags) belongs in afterCreating() or explicit forceFill().

Auth stack integration. If you use Breeze/Fortify/Jetstream, point their config at the published model and make sure the registration payload keys match your $fillable exactly — mismatches silently drop fields.

Gotchas and Tips

• Published files are frozen. 0.4.5's $fillable only reaches new installs. On an existing app, compare the stub against app/Models/User.php and add the array manually. Re-publishing with --force will overwrite your customizations — diff first.
• $fillable vs $guarded. If your current model uses protected $guarded = [], it silently allows everything. Adding a restrictive $fillable is technically a behavior change for any code passing extra keys — audit calls to create()/update()/fill() after switching.
• Overly permissive fillable is a privilege-escalation vector. Never list is_admin, role_id, email_verified_at, or remember_token. Use forceFill()/forceCreate() for trusted server-side assignments, and $user->markEmailAsVerified() style APIs rather than mass assignment.
• Set the same fields on the model and the policy. Filling role_id because "it was in the request" is the classic bug; validated input ≠ authorized input.
• Catch silent drops early. In local/testing, enable:

  Model::preventSilentlyDiscardingAttributes(! app()->isProduction());
  Model::preventAccessingMissingAttributes(! app()->isProduction());
  

  This turns "my field didn't save" into a loud exception naming the missing $fillable entry.
• Config cache. After changing package config or the model class binding, run php artisan config:clear (and optimize:clear in CI) — stale cached config is the usual culprit when a model swap appears ignored.
• Migration conflicts. If the package migration and your own create_users_table both run, the second fails. Disable one via the package config flag or by removing the published migration; check php artisan migrate:status before assuming a schema problem.
• Upgrade checks. With each release, diff the published stub and config against the vendor copies:

  diff vendor/<vendor>/<package>/stubs/User.stub app/Models/User.php
  

  Small releases like this one are documentation-grade changes; the diff keeps you honest without re-publishing.
• Extension points to prefer. Config-based model/table swapping and model subclassing survive upgrades; editing vendor files does not.