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

Bootstrap Sandbox Bundle Laravel Package

mopa/bootstrap-sandbox-bundle

A Symfony sandbox bundle for MopaBootstrapBundle, providing demo pages and examples that showcase Bootstrap-integrated forms, templates, menus, and UI components for testing and learning.

View on GitHub
Deep Wiki
Context7

Getting Started

Treat this bundle as reference material, not a runtime dependency. It is the sandbox/docs half of the Symfony 2-era mopa/bootstrap-bundle (Separate live docs from code), so the value for a Laravel developer is the Twig markup it demonstrates, not a composer require.

Minimal steps:

  1. Do not install into a Laravel app. There is no Laravel binding, no service provider, and it is a symfony-bundle targeting Symfony 2.1/2.2 and PHP 5.3/5.4. Pull it with git clone https://github.com/phiamo/MopaBootstrapSandboxBundle instead.
  2. Look here first, in this order:
    • Resources/views/ — the actual examples. This is the product. Each demo page is a small Twig template showing one Bootstrap widget wired to the bundle's form theme/helpers.
    • Controller/ — a thin index of demo routes; read it as the table of contents for the view tree.
    • Resources/config/ — routing/services definitions, which show exactly which MopaBootstrap helpers each demo depends on.
    • The sandbox application files (app/config/config.yml, AppKernel.php) — the only place the full wiring (form theme registration, Assetic filters, menu builder) is visible end to end.
  3. First use case: you need to render a Bootstrap-styled form widget (input group, checkbox collection, date field) in a legacy Symfony app, or you are porting Bootstrap 2 form markup to Blade. Open the matching demo template, copy the markup contract, and rebuild it in Blade.

If you want it running rather than read, expect a time-box: Docker image with PHP 5.6, composer install, enable the bundle in AppKernel, assets:install --symlink, assetic:dump. Budget an afternoon, not five minutes.

Implementation Patterns

Pattern 1 — Reference-driven porting (the realistic one). Read a demo template, note the HTML contract, rewrite as a Blade component:

{# Resources/views/Forms/... in the sandbox #}
{{ form_row(form.name, { 'attr': {'class': 'input-xlarge'} }) }}

becomes, in Laravel:

{{-- resources/views/components/field.blade.php --}}
<div class="control-group @error($name) error @enderror">
    <label class="control-label" for="{{ $name }}">{{ $label }}</label>
    <div class="controls">
        <input type="text" name="{{ $name }}" id="{{ $name }}"
               class="input-xlarge" value="{{ old($name, $value) }}">
        @error($name)<span class="help-inline">{{ $message }}</span>@enderror
    </div>
</div>

The mapping is mechanical: Twig {% block %} → Blade @section/component slot, form_row() → your <x-field>, MopaBootstrap's attr array → a typed props bag.

Pattern 2 — Living spec for a legacy app. If you maintain a Symfony 2 app that already depends on mopa/bootstrap-bundle, run the sandbox as a second kernel/bundle in a dev-only environment to see how an upgrade or a form theme override should look, then diff against your app's rendering. This is the one scenario where the bundle earns its keep as an actual dependency — and only in dev.

Pattern 3 — Regression fixture. Save the rendered HTML of a few sandbox pages (curl the demo routes) as golden files. After you port markup to Blade or upgrade Bootstrap, diff your output against them to catch class-name drift (btn → btn btn-default, span6 → col-md-6).

Pattern 4 — Steal the repo structure, not the code. The stated purpose — "separate live docs from code" — is the transferable idea. A library repo plus a separate demo/sandbox app that consumes it keeps the package lean and makes the docs testable. That is the same split as a Laravel package with a workbench/tests/Fixtures app. Copy the layout, not the files.

Integration tips

  • If you must run it: pin the whole toolchain (php:5.6-cli, Composer 1.x), and only enable MopaBootstrapSandboxBundle in the dev kernel.
  • Asset pipeline is Assetic + LESS/Compass era. Don't try to wire it into Vite/Mix; render static HTML and read it.
  • When extracting markup, grep for the form theme blocks rather than reading templates top-down — the theme files hold far more reusable structure than the individual demo pages.

Gotchas and Tips

  • License is NOASSERTION. There is no recognized SPDX license declared. Before you copy templates or form theme blocks into a commercial codebase, read the LICENSE file in the repo and confirm with the author. This is the single biggest blocker on "leverage" — copying unlicensed Twig into production is a real risk, and 0 dependents / 24 stars means nobody has vetted it for you.
  • It is Bootstrap 2 markup. span* grids, btn, icon-*, control-group / controls / help-inline. None of it is valid Bootstrap 3/4/5. Do not paste it into a Tailwind or BS5 project and expect it to render — treat it as a historical reference for the structure of a form theme, not the class names.
  • Dead ecosystem. Symfony 2.1/2.2, PHP 5.x, Assetic, Compass. Modern Composer will refuse to resolve it against current Symfony constraints; --ignore-platform-reqs just moves the failure to runtime. Don't add it to require in any project you intend to keep.
  • It is a bundle, not a library. It expects to be registered in AppKernel and to be served by a host app with routes, assets, and MopaBootstrapBundle already configured. Standalone it does nothing.
  • Debugging, in the old idiom: app/console router:debug to enumerate the demo routes, app/console twig:debug to list the available templates/blocks, app/console assetic:dump --watch if styles are missing. Most "broken demo" reports are just un-dumped assets.
  • Config quirks: the interesting configuration is not in this bundle — it is in the sandbox app's config.yml (mopa_bootstrap: section: form theme selection, form_type, icons, navbar settings). Read that file first if a demo renders unexpectedly; the bundle itself is mostly views and controllers.
  • Extension points worth knowing: Twig form theme block overrides (the standard Symfony form_theme mechanism) and template overriding at app/Resources/MopaBootstrapSandboxBundle/views/.... Both are Symfony-generic — nothing here is a novel extension API you'd reuse.
  • Verdict for day-to-day use: low. Score 2.7, zero dependents, unmaintained, unclear license. Open it as a read-only reference for Bootstrap 2 form markup and the docs-vs-code repo split; do not depend on it.
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.
pharaonic/laravel-notification-dependencies
beautinow/translug
dev-brainiac/bot-cloaked
octoberrain/html
octoberrain/extension
octoberrain/exception
octoberrain/contracts
frankyso/ipaymu
3mdikram/worldmoneywords
snowsoft/config
itmosoft/laravel-subscriptions
larva/laravel-ai-qwen
adachsoft/api-version-bundle
cgv/localized-resource
noith/settings
kda/laravel-package
kda/filament-dynamic-navigation
bypersoft/signbox
pairus/product-data
fayne/laravel-filament-cms-core