Laravel Blog Laravel Package

Getting Started

Install the package and publish its assets before writing any code:

composer require binshops/laravel-blog
php artisan vendor:publish --provider="BinshopsBlog\BinshopsBlogServiceProvider"
php artisan migrate

The publish step matters more than usual here — it copies the binshopsblog config file, the Blade views you'll be overriding, the migrations, and the front-end assets. Run it once, then read the config file from top to bottom; it's the single source of truth for the route prefix, admin middleware, image upload directory, and caching behavior.

Where to look first, in order:

1. config/binshopsblog.php — route prefix (default blog), the middleware guarding the admin panel, and upload paths.
2. routes/ inside the package (or php artisan route:list | grep blog) — the front-end is a catch-all at /{prefix}/{slug} and the admin panel sits at /{prefix}/admin.
3. resources/views/vendor/binshopsblog/ — the published Blade files you're expected to edit.

First real use case: open /blog/admin as an authenticated user, create a category, then a post with an uploaded image, and confirm it renders at /blog. If the admin panel 403s, your admin_middleware in config doesn't match how your app guards privileged users.

Implementation Patterns

Keep the package for authoring, not for presentation. Most teams use the admin UI to write posts and then query the models directly for their own front end, so the blog inherits the site's layout instead of the package's.

use BinshopsBlog\Models\BinshopsPost;

$posts = BinshopsPost::where('is_published', true)
    ->with(['category', 'tags', 'user'])   // always eager load
    ->latest('posted_at')
    ->paginate(10);

Render your own card/list views from that. This avoids fighting the package's default CSS and lets you drop "latest three posts" into a homepage or sidebar without duplicating the blog index.

Override views, don't fork them. Publish views, edit the copies in resources/views/vendor/binshopsblog/, and leave the package files untouched. Wrap the default layout in your app's layouts.app by editing the single layout partial — everything else inherits it.

Author attribution. Posts link to a user via a user_id column. If your guard is not the default web guard, set the author explicitly on create, or add an accessor/mutator mapping your author model, otherwise the admin panel silently attributes posts to nobody.

Custom admin access. Rather than editing package code, change admin_middleware in config to something like ['web', 'auth', 'can:manage-blog'] and define that gate in your AuthServiceProvider. This is the clean extension point for role-based access.

Integration with an existing model. If posts belong to a tenant or team, add the foreign key through a follow-up migration and a global scope on BinshopsPost (via a small subclass, or addGlobalScope in a service provider) so the admin panel only lists that tenant's posts.

Caching. The config exposes cache settings; enable them for the front-end routes and bust the cache in an observer on BinshopsPost when a post is saved or deleted.

Gotchas and Tips

• Uploads fail silently in production. The image directory must be writable and, if you use the public disk, php artisan storage:link must have run. Check the configured upload path against your filesystem layout — a path that works locally often doesn't exist on the server.
• WYSIWYG output is unsanitized HTML. Post content is rendered raw. If more than a trusted handful of people can author, run the body through an HTML sanitizer before output; do not assume the editor is a security boundary.
• Full-text search is MySQL-centric. If you're on SQLite or Postgres, flip the full-text index option off in config or the search route will error; then rely on LIKE/where clauses or your own Scout integration.
• Route prefix collisions. If you already own /blog, change the prefix in config. Changing it after posts exist is safe (slugs are relative), but any hardcoded links in your own views are not.
• config:cache traps. Publish and edit config before caching, and re-run php artisan config:clear after any change. A stale cached config is the usual cause of "my middleware change did nothing."
• Slug collisions. Two posts with the same title will fight over a slug. Uniqueness is enforced, but generate slugs deliberately (append an ID or date) if you import content in bulk.
• Comments are off unless you want them. The comment model exists; enabling it means owning spam. For most sites, leave it disabled and point discussions at an external service.
• Upgrade discipline. This is a single-maintainer package. Pin the version in composer.json, and after upgrading, re-publish views and diff them — published views are not updated automatically, so template changes ship as silent breakage.
• Migrations are the package's, not yours. Don't edit published migrations after they've run in production; add new migrations for any schema changes you need.