Blogetc Laravel Package

Getting Started

The fastest path from zero to a working blog:

composer require webdevetc/blogetc
php artisan vendor:publish --provider="WebDevEtc\BlogEtc\BlogEtcServiceProvider"
php artisan migrate

Then hit two URLs: /blog/admin (the built-in admin panel) and /blog (the public index). If you get a 403 or a redirect loop on the admin URL, that's the auth middleware talking — see Gotchas.

Look here first, in this order:

1. config/blogetc.php — the whole package is effectively driven from this file. Read it top to bottom before anything else; it controls route prefixes, pagination, comments, upload paths, editor settings, and the middleware/gate used for admin protection.
2. The published views directory (resources/views/vendor/blogetc/) — every public and admin view is publishable, which is the main customization lever.
3. WebDevEtc\BlogEtc\Models\BlogEtcPost — the model you'll query if you ever want to surface posts outside the package's own routes.

First use case: log into /blog/admin, create a category, create a post with an uploaded featured image, and confirm it appears at /blog and at /blog/{slug}. This exercises the upload path, the rich-text editor, the slug generator, and the view rendering in one pass — if all four survive, the install is healthy.

Implementation Patterns

Publish selectively, not wholesale. vendor:publish with the tag for config, then separately for views and assets. Publishing views you never touch means you inherit a maintenance burden the day you upgrade (or fork) the package. Publish the config always; publish only the two or three views you actually restyle.

Treat the admin panel as a staging surface, not a CMS. The panel is functional but thin — no revisions, no scheduling, no roles beyond "can access admin." For anything beyond basic authoring, create posts programmatically:

BlogEtcPost::create([
    'title' => '...',
    'slug' => Str::slug($title),
    'post_body' => $markdownOrHtml,
    'category_id' => $cat->id,
    'user_id' => $author->id,
    'is_published' => true,
]);

This is the pattern for importing an existing blog, generating posts from another system, or wiring up a queue-based draft pipeline.

Customize the admin access check, don't rebuild the panel. The config exposes the middleware stack guarding /blog/admin. For a single-admin site, ['web', 'auth'] is enough. For anything with multiple users, layer your own gate or middleware on top so that being logged in isn't synonymous with being an author — the package's default does not know about roles.

Embed recent posts in your own pages. Query the model directly in a controller or view composer:

$recent = BlogEtcPost::where('is_published', true)
    ->orderByDesc('created_at')
    ->limit(3)
    ->get();

Pair this with a published-and-restyled partial so your homepage and the /blog index share one card component.

Comments as a moderation queue. Enable comments in config, then use the admin panel as a pending-approval inbox. If you want them off entirely, disable at the config level rather than hiding the form in views — the config toggle also removes the POST route, which is what actually matters for spam.

Route integration. The package registers its own route group under the configured prefix. If your app already owns /blog, either change the package prefix in config or accept that your routes must be registered before the service provider's so yours win. Prefer changing the prefix — first-match routing is a debugging trap six months later.

Gotchas and Tips

It is unmaintained. Last release September 2020, which lands it squarely in the Laravel 6/7 era. On Laravel 8+ you should expect friction around namespace-based route registration, the $namespace property on RouteServiceProvider, and possibly facades or helpers that were deprecated and then removed. Do not assume composer require on Laravel 10 will work — check the constraint in composer.json and be prepared to fork. Budget for a fork rather than being surprised by one.

The admin panel is the security boundary. The default middleware is authentication, not authorization. On a fresh install with registration enabled, any registered user can reach /blog/admin. Verify the admin URL while logged out and while logged in as a non-author account before you ship.

Uploads need a storage link and a writable path. Featured images and inline editor images land in a configured upload directory that is served directly, not through Laravel's storage:link necessarily. If images 404 after deploy, check (a) the upload path in config, (b) directory permissions on the server, and (c) whether .gitignore/deploy scripts are wiping the directory on each release. This is the single most common "it worked locally" failure.

Asset publishing is a separate step from view publishing. The admin panel's CSS/JS comes from the package's public/ directory. Skip that publish (or forget to re-publish after an update) and you get an unstyled but functioning panel — easy to misdiagnose as a broken install.

Clear config cache after every config edit. php artisan config:clear — the config file is read at boot and cached configs silently ignore your changes. Same for views if you've published them and are confused about why edits don't appear.

Slug collisions and URL stability. Slugs are generated from titles. Editing a title in the admin panel may or may not regenerate the slug depending on version behavior — check before you let authors rename published posts, or you'll break inbound links. For anything SEO-sensitive, treat the slug as immutable once published.

Comment spam is real and the captcha is dated. The bundled captcha predates current bot sophistication. If comments are enabled on a public site, put them behind moderation (default off/pending) rather than trying to tune the captcha.

View overrides follow Laravel's vendor namespace precedence. resources/views/vendor/blogetc/... beats the package view, but only if the path matches exactly. If your override "isn't taking effect," you almost certainly have a filename or subdirectory mismatch — dump the view path with View::getFinder()->find('blogetc::...') to confirm.

Extension points are limited to config, views, and the models. There's no event system worth relying on and no repository/DI seam for swapping the persistence layer. If your requirements diverge meaningfully from "posts, categories, comments, images," the honest assessment is that you'll spend more time bending the package than writing a small CRUD app — the package's value is the admin panel and public views you get for free on day one, not as a long-term framework to build on.

Pin the version and document the fork. Given the release date, add an explicit version constraint in composer.json and note in your README which commit you forked from. The repository is a liability if you let it float.