- What is litecms/block and what does it do?
- LiteCMS Block is a Laravel package that adds named, reusable content blocks to the LiteCMS ecosystem so banners, sidebars, and promotional snippets can be edited outside Blade templates. It stores blocks in the database behind an Eloquent model and repository layer and provides Blade-friendly rendering helpers. It is a host-dependent CMS module rather than a general-purpose blocks library.
- How do I install litecms/block in a Laravel application?
- Install it with Composer, then publish the package config and migrations, run the migrations, and render named blocks from your application. Because it is built for LiteCMS, confirm your app already runs the LiteCMS or Lavalite core and that its service provider and admin routes register correctly. Do not treat a bare Laravel install as a supported target without a source audit.
- Which Laravel and PHP versions does litecms/block support?
- The package's supported PHP, Laravel, and LiteCMS core versions are defined in its composer.json constraints, not in the public overview. Check those constraints against your locked stack before installing, because packages in this lineage often pin tightly to a framework major. If the constraints exclude your current Laravel version, plan to fork or skip it.
- Do I need LiteCMS or Lavalite core to use litecms/block?
- Yes. litecms/block is a module for applications built on LiteCMS in the Lavalite lineage, not a standalone Laravel package. If you are starting greenfield Laravel without LiteCMS core, adopting the surrounding CMS costs more than building a simple blocks table and Blade component yourself. The decision is binary: you are on LiteCMS and need editorial blocks, or this package is out of scope.
- How do I render a block in Blade with litecms/block?
- The package provides Blade-friendly rendering helpers and directives for outputting named blocks, keeping layout fragments out of templates. You define a named block in the admin or database and then reference that name where it should render. Exact helper signatures and directive syntax should be confirmed from the package source or README, since the public overview only describes the capability.
- Where and how are block contents stored?
- Blocks are stored in the database and accessed through Eloquent models and a repository layer. The overview does not specify whether content is stored as JSON, typed rows, or pre-rendered HTML, so inspect the migrations and model casts before relying on it. The storage format affects validation, indexing, and cross-block querying.
- Is litecms/block safe for production use?
- Treat block content as untrusted editorial input and review the storage and rendering path before production use. If content is persisted as pre-rendered HTML, that is a direct XSS surface unless the package sanitizes output or restricts editing to trusted admins. Also verify that admin routes and middleware are guarded by default rather than exposed publicly.
- Does litecms/block include caching for rendered blocks?
- The package overview does not promise built-in caching, and the technical assessment flags caching as something to verify. Check whether every render is a fresh database query and, if caching exists, whether it is invalidated when a block is saved. For high-traffic pages, add your own cache layer around block rendering if needed.
- Does litecms/block have tests and is it actively maintained?
- There is no observable ecosystem signal: the repository shows zero stars, zero dependents, and a composite score of 0, which suggests an abandoned or scaffold-stage package. The overview does not state that tests ship with it, so assume your test surface may be the whole package. Check the last commit date, whether the maintainer is active on sibling LiteCMS packages, and whether tests exist before committing.
- Can I fork litecms/block or use it as a private dependency?
- Forking is the safer integration path: confirm the license permits modification, then fork into a private VCS or vendor the code under your application namespace with a path repository. Record the upstream commit SHA in your repository for provenance. Taking the public package as a live Composer dependency is risky given the lack of maintenance signal.