Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
Laravel Blade On Demand

Laravel Blade On Demand Laravel Package

protonemedia/laravel-blade-on-demand

protonemedia/laravel-blade-on-demand lets you compile and render Blade templates on the fly—including strings and dynamically generated views—without creating view files. Ideal for user-defined templates, CMS content, and email builders, with caching for performance.

View on GitHub
Deep Wiki
Context7

Compile Blade templates in memory

Frequently asked questions about Laravel Blade On Demand
How do I install protonemedia/laravel-blade-on-demand?
Install it with Composer using composer require protonemedia/laravel-blade-on-demand. The package supports Laravel auto-discovery, so the service provider and facade are registered automatically without editing config/app.php. There are no migrations, published config files, or external services to set up, which keeps the integration to a single dependency. After that you can call the facade or hit the bundled endpoint from your front-end JavaScript.
Which Laravel and PHP versions does this package support?
Confirm the exact constraints in the package's composer.json and on Packagist before adding it to your lock file, since support windows move over time. The package is most compelling for Laravel 8-era applications, because Laravel 9 and later ship a native Blade::render() for string templates. On Laravel 9+ you should only adopt it if you need behavior that native rendering does not provide. If the install fails, inspect the constraint output to see which PHP or Laravel version is blocking it.
What is the difference between this package and Laravel's native Blade::render()?
Laravel 9+ includes Blade::render(), which compiles a Blade string to HTML without any extra dependency. laravel-blade-on-demand predates that and adds a facade plus an HTTP endpoint aimed at letting front-end JavaScript request server-rendered markup on demand. Evaluate whether you actually need the endpoint and any extra view resolution or caching behavior, because if you only need to render a string with data the native API is the safer choice. For Laravel 8 or earlier, the package is a reasonable convenience layer.
Is it safe to let users or tenants author Blade templates with this package?
No, not without a separate security architecture. Blade compiles to plain PHP, so directives such as @php and unescaped echoes can execute arbitrary code on your server. Rendering tenant- or user-authored templates effectively grants privileged PHP execution unless you sandbox it, and Blade provides no sandbox natively. Restrict template authoring to trusted internal users or privileged admins, and validate or sanitize any template content that originates outside that group.
How are compiled templates keyed, cached, and invalidated?
Compiled views are written to the framework's compiled view path and are typically keyed by a hash of the template contents. Because the key derives from the string, editing a template generally produces a new compiled file rather than serving stale output, but verify this behavior in the source for your pinned version. Highly dynamic templates can cause unbounded growth in the compiled view directory, so plan a cleanup or pruning strategy. Clearing the view cache with php artisan view:clear remains the safe fallback for suspected stale output.
Does it support @include, @extends, Blade components, slots, and custom directives?
Standalone strings compile through the normal Blade compiler, so most directives work as expected, but includes and layouts that reference files on disk depend on the view finder resolving those paths correctly. Component and slot support depends on the package version and how it constructs the compiler, and gaps with newer Blade features are a known compatibility concern. Test representative templates that use every directive and component your product relies on before committing to a migration.
What are typical use cases for rendering Blade strings in memory?
The common cases are CMS blocks, tenant-specific email and notification templates, dynamically generated PDFs, and admin-editable content where a deploy per template change is unacceptable. Anywhere you want markup to stay in Blade while the template body itself lives in a database or arrives from an API, this package fills that gap. It is also useful for AJAX-driven UI updates where you want to inject server-rendered markup without a page reload. It is not a general replacement for file-based views.
Where are compiled views written, and does it work with Laravel Octane or ephemeral containers?
Compiled templates go to the same storage path Laravel uses for compiled views, storage/framework/views by default, so that directory must be writable by the application. In containerized or ephemeral environments, that path needs to be a persistent volume or be repopulated per request, otherwise every request recompiles the template. Under Octane, watch for workers holding stale in-memory state and for cache-key collisions across tenants. Clear the view cache during deploys to stay safe.
How do I test templates rendered by laravel-blade-on-demand?
Wrap the package behind your own adapter, for example a TemplateRenderer::render(string $template, array $data): string interface, and assert against that in unit tests. That keeps your assertions stable if you later swap to native Blade::render() or a forked compiler. For the HTTP endpoint, use standard Laravel feature tests with postJson and assertSee to check the returned markup. Also add tests covering your highest-risk directives so regressions surface before production.
Is the package still maintained, and what are the alternatives?
It has a small ecosystem footprint of roughly 62 GitHub stars and no dependents, so bus-factor and battle-testing are legitimate concerns even though a recent release exists. The main alternative is Laravel's native Blade::render() on Laravel 9+, which covers simple string rendering without an extra dependency. You can also fork the compiler logic yourself for full control over caching and sandboxing. Pin a version and isolate it behind an interface so switching away later is cheap.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
robertmarney/lara-hierarchial-collections
simonschaufi/rule-doc-generator
emissaoja/emissaoja
blackbricksoftware/gravityforms-civicrm-form-processor
al-rahabi/fancy-crud
jinas/dhivatar-component
mltstephane/laravel-quality
bernskiold/laravel-talentlms
bernskioldmedia/laravel-form-architect
youbar/easy-crud
c-point-labs/laravel-hostyourai
dbravoan/dbcms-admin-theme-dbcms
dbravoan/dbcms-theme-db-cyber
dbravoan/dbcms-blocks-basic
dbravoan/dbcms-module-content-audit
dbravoan/dbcms-module-ai-assistant
paygate-to/paygate-php
padosoft/askmydocs-connector-base
defstudio/supercharged-carbon
bernskioldmedia/laravel-matomo