Weave Code
Posts For Laravel Laravel Package
roundly-consulting/posts-for-laravel
A Laravel package for adding blog-style posts to your application, with models, migrations, and a straightforward API for creating, publishing, and managing content. Quickly integrate post management without building it from scratch.
A modern, multilingual, SEO-ready blog/posts engine for Laravel with translatable content, a publishing lifecycle, categories, and tags.
Frequently asked questions about Posts For Laravel
- How do I install roundly-consulting/posts-for-laravel?
- Install it with Composer using composer require roundly-consulting/posts-for-laravel. Laravel package auto-discovery should register the service provider, so no manual provider entry is normally required. After installing, publish any config and migration files, review the diff, then run php artisan migrate against a scratch database first. Pin an exact version during the spike so the lockfile change is easy to audit.
- Which Laravel and PHP versions does this package support?
- The release notes do not publish an explicit support matrix, so treat composer.json constraints as the source of truth. The package family targets modern PHP 8.x and standard Laravel, with no new runtime services implied. Before adopting, compare the family's framework constraint against the exact Laravel minor your application runs. If you are on an older Laravel release, test the install in a branch rather than assuming compatibility.
- Are the migrations publish-only or auto-loaded?
- The notes do not state whether migrations are publish-only or loaded directly from the package, and version 1.0.1 gives no additional signal. Publish them into your application and diff the output so you know exactly which tables and columns you own. Then run the migrations against a throwaway database and inspect the polymorphic columns and indexes before touching production. Also check whether publish tags change between patch releases, since that affects future upgrades.
- Does this package include a UI, like Blade, Livewire, or Inertia views?
- Nothing in the package description suggests a front end ships with it. It is described as models, migrations, and structure for creating and managing posts, so plan on owning the presentation layer entirely. If you are scoping front-end work, confirm this directly against the repository before committing estimates. The integration surface is the Eloquent models and whatever API the package exposes.
- What other packages get installed with posts-for-laravel?
- This package is a thin orchestration layer over several first-party roundly packages: package-toolkit, enums, approvals, likes, media-library, reports, and sluggable. That means one composer require onboards roughly eight versioned artifacts, all with caret constraints. Your upgrade cadence is therefore set by the family rather than this package alone. Review the lockfile diff after install to see exactly what arrived.
- Can I install it if I already use approvals, likes, media-library, or reports?
- Probably, but coexistence is the real gate. Version 1.0.1 bumps dependency floors (for example ^1.2.3, ^1.1.0, ^1.1.2, ^1.1.0), which can conflict with versions already locked in your app. Run composer why-not against each sibling package before committing, and resolve conflicts on a branch. A constraint clash here can otherwise block an unrelated security patch later.
- How do I create, slug, and publish a post with this package?
- You create posts through the provided Eloquent model after publishing and running the migrations. Slugs come from the sluggable dependency, so slug-based routing is part of the design rather than something you build. Publishing workflows tie into the approvals dependency, but the exact behaviour should be verified with integration tests in your own app. Extend the model with your own fields and relationships rather than forking the package.
- Is it suitable for multi-tenant applications or custom authorization?
- Multi-tenancy and policy hooks are not documented in the release notes, so assume you must add scoping yourself. The polymorphic relations used by approvals, likes, and reports mean you should check how tenant isolation interacts with those tables. Confirm the user model assumptions too: guard name, polymorphic user relations, and soft deletes. Write a policy layer around the models before exposing them to tenants.
- Does it register events, jobs, or queues that require workers?
- Nothing in the notes indicates background jobs or queues, and approvals, likes, and reports are typically synchronous Eloquent concerns. That said, this is unconfirmed, so inspect the service provider and any event listeners after installing. If events are dispatched, decide whether they are queued or handled inline. Booting the app in a branch spike is the fastest way to see registration side effects.
- How do I upgrade to 1.0.1 and how risky is the package long term?
- The 1.0.1 release contains no code changes: it bumps dependency floors and repoints composer.json homepage and support.docs metadata, plus an absolute README image URL. Treat the upgrade as a lockfile change, then diff composer.lock to see which sibling packages moved. Long term, the family is pre-2.0 semver, so assume minor releases may change behaviour and expect the sibling packages to move faster than this one. Documentation lives off-site at support.docs, so link to it rather than copying it into your own docs.
Weaver
How can I help you explore Laravel packages today?