- How do I install ojessecruz/simple-blog in a Laravel app?
- Run composer require ojessecruz/simple-blog, then php artisan simple-blog:install. That install command is idempotent and safe to re-run: it publishes config/blog.php and the migrations, adds the Tailwind source import to resources/css/app.css, and offers to run the migrations for you. Afterward you protect the admin routes with your own middleware and run npm run build. You can also install manually by publishing the simple-blog-migrations and simple-blog-config tags and running php artisan migrate.
- Which Laravel, PHP, and Livewire versions does simple-blog support?
- The package requires PHP 8.3+, Laravel 11, 12, or 13, and Livewire 3.5+ or 4. Those are hard floors, so an app still on PHP 8.2 or Laravel 10 cannot use it without upgrading first. Verify the exact Livewire point release and Laravel 13 support against your own dependency matrix before committing, since the package is pre-1.0 and its version matrix is worth spiking in a branch.
- How do I secure the simple-blog admin routes?
- The package ships no authorization logic on purpose; admin access is whatever you configure in admin_middleware in config/blog.php. That can be a Gate check, a guard, or a full middleware stack such as auth plus a role or permission middleware, so it aligns with your existing RBAC model. The trade-off is that there is no safe default: if you leave admin_middleware empty, the Livewire admin CRUD is reachable by anyone who knows the URL, so set it before deploying.
- Why does my simple-blog page render unstyled?
- The package ships Tailwind utility classes but does not compile its own CSS, so your host app's Tailwind build must scan the package views. On Tailwind v4, import the package CSS entrypoint from resources/css/app.css right after @import 'tailwindcss'. On Tailwind v3, add ./vendor/ojessecruz/simple-blog/resources/views/**/*.blade.php to the content array in tailwind.config.js. Then rebuild assets with npm run build.
- Does simple-blog escape raw HTML in Markdown posts?
- Yes, Markdown rendering in the package is configured with HTML escaping, which reduces the XSS surface if untrusted users can write posts. Because your admin middleware decides who can author content, escaping is a defense-in-depth layer rather than your only control. If you need to allow raw HTML, treat that as an explicit override and document it, since the default configuration is the safe one.
- Can I preview a draft post before publishing it?
- Yes. Draft preview opens the post in a new tab so you can read it in the public layout without publishing it to the listing. Public queries use the published() scope on the Post model, so unpublished posts stay out of the index while preview links still render. That makes it practical to review formatting and SEO meta before flipping a post live.
- How do I make my User model compatible with simple-blog authors?
- Your App\Models\User must implement the package's Author contract. It is a small, additive change to an existing model with low integration risk, and it keeps the package from forcing a specific users table or auth scaffold on you. Implement the contract on whichever model represents your authors, then the Livewire admin components can resolve the current author normally.
- Is simple-blog a full CMS with comments, feeds, and sitemaps?
- No. It is deliberately a lightweight blog, not a CMS: there is no multi-author editorial workflow, approval queue, comments, sitemap, or RSS/Atom feed generation. The Post and PostCategory models are exposed with scopes such as published(), so you can build those features yourself. Sitemap and robots output plus meta and JSON-LD are also delegated to your host layout, which must provide @stack('head') and @yield('content') for SEO tags to render.
- Is simple-blog safe to use in production given it is pre-1.0?
- The architecture is conventional and low-risk, but the project is early: version 0.4.3, a single apparent maintainer, and few dependents, so minor releases may carry breaking changes. There is no visible CI or coverage signal beyond a composer test script, and changelog entries are mostly cosmetic polish rather than hardened edge-case work. Pin the version in composer.json, review upgrades, and be prepared to vendor or fork the package if it goes quiet.
- What happens if I publish the simple-blog views, and how do I upgrade later?
- Publishing the simple-blog-views tag copies the Blade views into your resources/views, which lets you change markup freely but permanently forks the UI from upstream. From that point, package updates no longer reach your templates and you must port changes by hand. Publish only the views you actually need to change, and if you are only adjusting styling, prefer overriding with your own CSS or a thin wrapper layout. Also check the published migrations before running them, since posts and post_categories table names could collide with an existing schema.