- How do I install jeffersongoncalves/laravel-knowledge-base?
- Install it with Composer using composer require jeffersongoncalves/laravel-knowledge-base. The package ships a service provider, publishable configuration, migrations, and an Artisan command, so the next step is publishing the config and running your migrations. Then set your attachments disk and route options in the published config and create your first categories and articles. Because routes are registered by the package, check the published route prefix and middleware before going live.
- Which Laravel and PHP versions does this knowledge base package support?
- The package is a native Laravel package with a service provider, publishable config, and package-registered routes, so it follows standard Laravel conventions. Exact Laravel and PHP constraints live in the package composer.json and the README, and you should confirm them before upgrading an existing app. Pin the version you tested with in composer.json so a minor release cannot change your asset-serving behavior unexpectedly.
- How does private asset delivery work in version 2.1?
- Assets are stored on a configured disk defined by the attachments.disk setting rather than being dropped into public/storage with a hardcoded URL. Requests are served through a package-owned route named knowledge-base.assets.show, which re-evaluates article visibility on every request and can issue signed URLs. The route block controls whether it is enabled, its prefix, its middleware stack, signed URL lifetime, and the cache max age. This is the right model for a knowledge base where draft or internal articles must not leak.
- Why are my internal or draft knowledge base files still reachable at /storage after upgrading?
- The upgrade itself does not revoke anything: files you already had on the public disk stay reachable at their /storage/... URLs until they are physically deleted. Assets moved to the private disk work correctly through the new route, but the copies left behind still expose the content. This is the highest-risk item in the migration and it is an operator action, not package behavior. Add an explicit deletion step for the old public files to your release checklist and verify with a direct URL request.
- What does the kb:move-assets command do and is it safe to run in production?
- The command is the supported way to migrate existing knowledge base assets onto the configured disk, and it supports a --dry-run flag so you can review the manifest before anything changes. Run the dry run first, then execute it in staging and verify a sample of public, internal, draft, and archived articles. Confirm whether your version moves or copies files, because a copy leaves the original public file in place. Also check partial-failure and idempotency behavior before running it against production storage.
- How do I put the knowledge base asset routes behind auth or tenant scoping?
- The attachments.route block exposes a middleware stack for the asset route, so adding web, auth, or a tenant-scoping middleware is a configuration change rather than a code change. That makes it straightforward to slot the route behind your existing authorization conventions. Verify that visibility is resolved from your article scopes or policies rather than a package-internal check that could diverge from app authorization. Test with a real internal article and a real user before rolling out.
- Can I keep the old 2.0 file behavior instead of the mediated asset route?
- Yes. Setting attachments.route.enabled to false preserves the 2.0 behavior, so you are not forced into a big-bang cutover. This dual-mode switch is useful when you need more time to move storage or adjust middleware. Remember that disabling the route also means you give up the per-request visibility re-check for those assets. Plan the switchover as a separate, deliberate release.
- Does the package handle PDFs and other non-image attachments safely?
- The route serves files from a configured disk, so non-image types such as PDFs and office documents are the case to test explicitly. Check that responses include sane Content-Disposition and X-Content-Type-Options headers and that downloads behave as expected in browsers. Serve untrusted uploads with a restrictive disposition rather than inline rendering. Run a quick check with each file type your help center actually publishes before launch.
- What happens when a signed asset URL expires on a long-lived open page?
- Signed URLs are only valid for the duration set by signed_url_minutes, so a page kept open longer than that can fail to load its assets. Set a lifetime that comfortably exceeds realistic session lengths, and check the documented default in the published config. For internal assets, make sure responses are marked Cache-Control private, no-store so an edge cache cannot serve a signed response past its validity. If you front the app with a CDN, treat both of these as documented residual risks.
- What are the performance implications of serving knowledge base assets through Laravel?
- Private assets stream through a controller, which means bytes traverse the app tier rather than being served directly by the web server or CDN. That is acceptable for moderate traffic but needs a load and bandwidth sanity check against your expected help center usage. cache_max_age applies to the public branch, so tune it deliberately and purge caches when an article becomes internal. Any CDN in front introduces a revocation lag you should document rather than ignore.