Tags For Laravel Laravel Package

Getting Started

• Install with composer require for the package, then publish its assets: php artisan vendor:publish --tag="tags-config" and --tag="tags-migrations", followed by php artisan migrate. The migrations create the tags and taggables tables (plus a type column if you use typed tags).
• Add the HasTags trait to every model that can be tagged. This gives you attachTags(), syncTags(), tags(), and the query scopes used by the popularity endpoint.
• Look first at config/tags.php (model bindings, tag types, slug/name handling) and at the package's route/controller registration. The GET tags/{type}/popular?on= route is the fastest way to confirm the package is wired correctly.
• First use case: render a "popular tags" sidebar. Seed a few records, attach tags, then hit GET /tags/post/popular?on=App\Models\Post and verify you get an ordered list of tags with counts. That single request exercises tagging, the type filter, the on model resolution, and the counting query.

Implementation Patterns

• Typed tagging: Pass the type when attaching (attachTags(['laravel'], 'topic')) so {type} in the popular route has something meaningful to filter on. Keep tag types in config rather than scattering string literals across controllers.
• Using on= for per-entity popularity: The on parameter decides which taggable model the counts are derived from. Pass the morph alias (or FQCN, depending on your config) matching the resource being viewed. This lets one tags table serve posts, videos, and products with independent popularity lists.
• Tenant-scoped tag clouds: In a multi-tenant app, let your model's global scope do the work — as of 1.0.2 the popular query honours global scopes, so a tenant-aware Taggable model automatically excludes other tenants' rows. Do not hand-roll where tenant_id = ... on the tag table; the count is over the taggable side.
• Caching the response: Popular-tag payloads are read-heavy and write-light. Wrap the endpoint (or the resolver call) in Cache::remember() keyed by type + on + tenant, and invalidate on tag attach/detach via model events or an observer.
• Blending with your own queries: For custom "related tags" or "tags in this category" screens, reuse the package's popularity query builder rather than writing withCount('tags') by hand — you get consistent ordering, tie-breaking, and scope handling.
• API vs. Blade: For Blade sidebars, call the resolver directly in a view composer; for SPAs, expose the route as-is and let the front end pass on. Keep both paths pointed at the same underlying query so behaviour stays identical.

Gotchas and Tips

• 1.0.2 changes your numbers. The popular endpoint previously counted taggables that your model's global scopes exclude — soft-deleted posts and other tenants' records inflated counts. After upgrading, existing popular lists will show lower counts. That is a bug fix, not a regression, but it will be visible to users and to any snapshot tests or analytics dashboards keyed on those counts.
• Flush popularity caches on upgrade. If you cached the popular response, stale inflated counts will persist past the deploy. Clear the relevant cache keys as part of the release.
• Admin/reporting views still need explicit overrides. If you want deleted records included in an internal report, use withTrashed() / withoutGlobalScopes() on the taggable query explicitly. Do not assume the fix makes the endpoint unusable for auditing — it just defaults to scope-respecting behaviour.
• Validate on. An unrecognised or non-taggable model in on= should be treated as a 422 rather than silently returning an empty or global list. Guard it in a form request or at the route level.
• Performance: ensure indexes exist on taggables.taggable_type/taggable_id and on tags.type. The popular query groups over the pivot table; without those indexes it degrades quickly at scale.
• Extension points: most of this package's behaviour (model bindings, type list, ordering) is config-driven. Prefer overriding the config and the popularity resolver over forking the controller; keep customisations in a service provider so future patch releases (like 1.0.2) stay drop-in.
• Watch the changelog for scope-related changes. This fix touched the counting query specifically; if you have subclassed or copied that query, port the scope handling across or your custom variant will keep the old behaviour.