Twitter Bootstrap Bundle Laravel Package

Getting Started

1. Install the package (typically composer require <vendor>/<package>) and let Laravel auto-discover the service provider, or register it manually if the package predates discovery.
2. Publish the package assets/config:

   php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider"
   

   Look first at the published config/<package>.php and public/vendor/<package>/ directories.
3. Include the bundled Bootstrap 2.3.2 assets in your main Blade layout instead of a CDN:

   <link rel="stylesheet" href="{{ asset('vendor/<package>/css/bootstrap.min.css') }}">
   <link rel="stylesheet" href="{{ asset('vendor/<package>/css/bootstrap-responsive.min.css') }}">
   ...
   <script src="{{ asset('vendor/<package>/js/jquery.min.js') }}"></script>
   <script src="{{ asset('vendor/<package>/js/bootstrap.min.js') }}"></script>
   

4. First use case: scaffold a legacy admin/settings layout using Bootstrap 2.3.2’s .row-fluid, .span*, .navbar, .table, and modal/dropdown JS plugins without pulling assets from a CDN.

Implementation Patterns

• Asset publishing workflow: Publish once in development, commit published assets only if your deployment forbids vendor:publish, otherwise run vendor:publish --force during deploy and rely on asset() URLs.
• Layout composition: Keep the package’s CSS/JS includes in a base layout (resources/views/layouts/app.blade.php) and push page-specific scripts with @push('scripts') / @stack('scripts').
• CDN/local toggle: If the package config exposes a cdn or use_local flag, drive it from .env so local development uses bundled assets and production can opt into a CDN.
• Form integration: Bootstrap 2.3.2 expects markup like control-group, control-label, controls, and help-inline. Wrap Laravel’s Form::* / @error output in those classes; do not use Bootstrap 3/4/5 form-group / is-invalid markup.
• JavaScript plugins: Initialise Bootstrap 2.3.2 plugins explicitly where needed ($('.dropdown-toggle').dropdown(), $('#myModal').modal()) and ensure jQuery is loaded exactly once before bootstrap.min.js.
• View overrides: Publish package views (--tag=views) and override partials rather than editing vendor files; this keeps upgrades to the bundled Bootstrap version manageable.
• Migration path: Treat the bundled Bootstrap 2.3.2 as a compatibility layer. If you are incrementally moving to a newer Bootstrap, isolate package includes behind a config flag and avoid mixing grid classes across layouts.

Gotchas and Tips

• Package version ≠ Bootstrap version: Release 2.3.2 means the package bundles Bootstrap 2.3.2; it does not imply Bootstrap 3/4/5 compatibility. Do not copy modern Bootstrap examples into these views.
• Legacy grid: Bootstrap 2.3.2 uses .row-fluid / .span*, not .row / .col-*. Mixing them silently breaks layout.
• Responsive CSS is separate: You must include bootstrap-responsive.css; otherwise mobile/tablet behaviour will be missing.
• jQuery compatibility: Bootstrap 2.3.2’s plugins predate jQuery 3. Some plugins can break with newer jQuery. Pin a compatible jQuery version or test modal/dropdown/tooltip behaviour after upgrading jQuery.
• Glyphicons paths: The icon sprite is loaded relative to the CSS file. If you move or rename the published CSS, icons may 404. Keep the img/ directory alongside css/.
• Asset caching: After vendor:publish --force, clear caches and use versioned URLs (asset() with a query string or Mix/Vite) to avoid stale legacy CSS in browsers.
• Config caching: If you change the package config, run php artisan config:clear locally; in production, re-run config:cache.
• Debugging missing assets: Check public/vendor/<package>/, confirm the publish tag, and inspect the rendered HTML for the actual asset() path. A 404 usually means assets were never published or the provider tag changed.
• Extension points: Prefer the package config file, published views, and a custom CSS file loaded after bootstrap.min.css. Avoid editing public/vendor/... directly because the next publish or deploy can overwrite it.