Getting Started

Install and confirm discovery.
```
composer require mortezamasumi/fb-profile
```
The package is Laravel-auto-discovered (check vendor/mortezamasumi/fb-profile/composer.json for the extra.laravel.providers entry). If it isn't listed, register the provider manually in bootstrap/providers.php.
Read the package before you write code. With no real docs, the source is the documentation. In vendor/mortezamasumi/fb-profile/ look at, in this order:
- src/ — the service class(es) you'll inject and the public methods that return profile data.
- config/ — the config filename and every key. This tells you what credentials, field lists, and cache settings exist.
- resources/views/ — the shipped Blade form/component, specifically the username input's autocomplete attributes (the v5.2.1 fix).
- routes/ — whether the package registers any endpoints you inherit.

Publish config (and views only if you must).

php artisan vendor:publish --provider="MortezaMasumi\FbProfile\FbProfileServiceProvider"
# or target the tag you find in the provider's publishes() array
php artisan config:clear && php artisan view:clear

Publish config first, leave views unpublished until you actually need to change markup.

First use case: an admin/user settings screen where someone enters their Facebook username or profile URL, rendered with the package's own form. Include the package view/component as-shipped, wire it to a controller that validates and calls the package service, and confirm in DevTools that the username input carries the autofill-suppressing attributes. That single screen exercises config, the service, and the view — the whole surface area — in about an hour.

Sanity-check the happy path with a tinker-style call to the service before building UI:

$profile = app(\MortezaMasumi\FbProfile\...\ProfileService::class)->fetch('someusername');

Implementation Patterns

Put the package behind your own interface. Inject the package service into a thin application-level class (App\Services\FacebookProfileGateway) and let the rest of the app depend on that. Benefits: easy to mock in tests, easy to swap for Laravel Socialite or a Graph API client if the package stalls, and a single place to normalize whatever shape the package returns into your own DTO.
Validate, then hand off. Use a Form Request for the username/URL, then pass only $request->validated('username') into your gateway. Facebook usernames have a narrow allowed format ([A-Za-z0-9.]); profile URLs need parsing. Don't let raw user input reach the package's fetch call.
Cache every remote lookup. Even if the package fetches fresh each time, wrap it:
```
return Cache::remember("fb-profile:{$username}", now()->addHours(6), function () use ($username) {
    return $this->gateway->fetch($username);
});
```
Profile data changes slowly; rate limits and transient API failures are the real risk. Cache null/failure results for a short window (60s) separately so a bad username doesn't hammer the API.
Isolate failures at the boundary. Return a ?ProfileData from your gateway, catching package/network exceptions there. Settings pages and onboarding steps should degrade to "couldn't load profile — enter details manually," never a 500.
Use the shipped view; override surgically. Start with the package include/component. If design demands changes, publish views and edit only the wrapping markup, copying the username input's attributes verbatim. Keep your published copy in git and diff it against vendor/ after every upgrade.
Settings-page integration pattern: controller validates → gateway fetches (cached) → view renders the package form pre-filled from your own DB, not from the package's response object. Persist the profile fields you need into your own table so reads never depend on a live call.
Testing:
```
$this->instance(ProfileGateway::class, $fakeGateway);
$this->get('/settings')->assertOk()->assertSee('name="username"', false);
```
Add one feature test asserting the rendered username input still has the autofill attributes — that's the regression guard for the v5.2.1 class of bug. Use Http::fake() if the package talks to the Graph API through the HTTP client.
Upgrade cadence: pin in composer.json ("mortezamasumi/fb-profile": "^5.2"), and on each bump run composer update mortezamasumi/fb-profile && php artisan view:clear && php artisan config:clear. Re-diff any published views.
Store only what you need. Map the package's profile response into explicit columns (fb_username, fb_profile_url, fb_avatar_url) rather than dumping the payload into a JSON blob. Reduces PII surface and makes deletion requests trivial.

Gotchas and Tips

Published views silently shadow package views. After v5.2.1, if you published the username field view earlier, you will not get the autofill fix. Your override sits at resources/views/vendor/fb-profile/... and wins forever. Diff your copy against the upgraded vendor file every time — this is the single most likely way to reintroduce the bug.
autocomplete="off" is not enough in Chrome. Chrome's password manager uses heuristics on field name, id, surrounding labels, and form structure. If autofill still fires: use a non-login-ish input name inside your form, add autocomplete="new-password" or a random token value, and keep 1–2 visually hidden decoy inputs. Test in a clean Chrome profile — saved credentials mask whether the fix works.
Config and view caches hide your changes. php artisan config:clear / view:clear locally; config:cache / view:cache in deploy scripts. A "config change did nothing" bug is almost always the cached config.
Credentials belong in .env, not in the published config. Published package configs frequently hardcode placeholders; replace them with env() calls so keys never land in git.
Check the pinned Graph API version. Facebook deprecates Graph API versions on a rolling schedule. If the package hardcodes a version string, note it in your dependency review and be ready to override it in config or patch it — an expired version fails with a generic OAuth error that looks like a credentials problem.
Timeouts and token expiry. Set an explicit HTTP timeout (5–10s) for any fetch path. Long-lived tokens still expire; handle a 190/OAuthException-style failure by clearing the stored token and prompting reconnection rather than retrying.
resources/views/vendor/<namespace> must match exactly. A typo in the namespace directory makes Blade fall back to the package view with no error — your customization appears to be ignored and you'll chase the wrong bug. Verify with php artisan view:clear then check which file Blade::getFinder() resolves (or just temporarily put  at the top of your override).
Zero stars, single maintainer, one-line release notes. Treat this as a vendored-risk dependency: pin the version, wrap it behind your own interface, and don't put it on a critical auth path without reading the token handling yourself. The v5.2.1 entry has no linked issue or upgrade guidance — assume you're the QA.
Debugging checklist for "the form looks wrong": confirm the view path in use (view:clear first), inspect the input in DevTools for autocomplete/name, test in incognito, and dump config('fb-profile') to confirm the right config file is loaded (a mis-named published file leaves the vendor defaults active).
Extension points, in order of safety: config values → container binding override ($this->app->bind(...) in a service provider, pointing the package's service contract at your subclass) → publishing and overriding views → forking. Stop as early as possible; each step down costs you upstream fixes.

Fb Profile Laravel Package

Getting Started

Implementation Patterns

Gotchas and Tips