Gumby2 Laravel Package

Getting Started

This is a Laravel 4-era wrapper that bundles the Gumby 2 responsive front-end framework (Sass/Compass + jQuery plugins) so its assets, config, and possibly view partials can be consumed from a Laravel package. With 10 stars, 0 dependents, and a score of 0.24, treat it as a legacy convenience package, not infrastructure.

Minimal setup:

1. Confirm the project is Laravel 4.x on PHP 5.4–5.6. The package has no Laravel 5+ support and will not install cleanly on modern PHP/Composer constraints.
2. Require it:

   composer require caouecs/gumby2
   

3. Register the service provider in app/config/app.php under providers, typically:

   'Caouecs\Gumby2\Gumby2ServiceProvider',
   

4. Publish package assets and config:

   php artisan asset:publish caouecs/gumby2
   php artisan config:publish caouecs/gumby2
   

   Assets normally land under public/packages/caouecs/gumby2/; config under app/config/packages/caouecs/gumby2/.
5. In your master Blade layout, pull in the published CSS/JS (jQuery first) and initialize Gumby:

   {{ HTML::style('packages/caouecs/gumby2/css/gumby.css') }}
   {{ HTML::script('//ajax.googleapis.com/ajax/libs/jquery/1.11.0/jquery.min.js') }}
   {{ HTML::script('packages/caouecs/gumby2/js/libs/gumby.min.js') }}
   <script>gumby.init();</script>
   

Where to look first: the package's src/ for the service provider (what it registers and publishes), its public/ directory for the exact asset filenames, and any views/ or config/ directory for overridable defaults. Verify the actual file names against the repo — this package is small and undocumented enough that you should not assume paths.

First use case: swap an existing Blade master layout onto the Gumby grid and navigation, then progressively adopt components (forms, modals, tabs) page by page rather than rewriting everything at once.

Implementation Patterns

Master layout + section yields. Keep one layouts/master.blade.php that includes Gumby CSS/JS once, then use @yield('content') and @section('scripts') so page-specific Gumby JS (modals, tabs) is only loaded where needed.

Component partials over inline markup. Gumby markup is verbose (grid rows, nested columns, data attributes). Store reusable chunks in app/views/partials/ — navbar.blade.php, modal.blade.php, alert.blade.php, pagination.blade.php — and @include them with data. This keeps controllers/views clean and makes framework upgrades or replacements a single-file change.

Grid usage in Blade. Use Gumby's .row / .columns / width classes and responsive modifiers directly in templates. Keep the grid in the view layer only; never build class strings in controllers.

Forms with the Laravel form builder. Combine Form::open() with Gumby's input classes and render validation state through Gumby's error classes:

{{ Form::open(['route' => 'users.store', 'class' => 'form']) }}
  {{ Form::text('name', null, ['class' => 'input', 'placeholder' => 'Name']) }}
  @if ($errors->has('name'))
    <span class="danger label">{{ $errors->first('name') }}</span>
  @endif
{{ Form::close() }}

Flash messages as Gumby alerts. Centralize session flash rendering in the layout using Gumby's alert/message classes so success/error feedback stays consistent across controllers.

Pagination presenter. Laravel 4 lets you swap the pagination presenter; implement one that emits Gumby pagination markup so $users->links() renders correctly without per-view overrides.

JS lifecycle. Gumby's plugins bind on DOM ready via gumby.init(). For content injected by AJAX, re-run the relevant initializer after insertion rather than re-calling full init. Load jQuery exactly once, before Gumby.

Customization via Sass, not overrides. Gumby 2 is built with Compass. For real theming (colors, breakpoints, grid widths), compile your own Gumby build from Sass and point the layout at the compiled file — this is the only sane extension point for design changes.

Integration tips. Wrap Gumby behind your own partials so the rest of the app depends on partials.navbar, not Gumby classes. That makes a future migration to Bootstrap/Tailwind a view-layer change rather than a codebase-wide sweep.

Gotchas and Tips

• Laravel 4 is end-of-life (2015) and this package is abandoned. No security patches, no Laravel 5/6/7/8/9/10/11 support, no tests. Only use it on an existing L4 app; do not introduce it to anything new.
• PHP compatibility. L4-era packages frequently break on PHP 7+ (removed/deprecated functions, old dependency constraints). Expect to run PHP 5.6 or patch the package. composer require may fail outright on modern PHP due to platform constraints — check composer.json's require block before attempting.
• Asset publishing is the #1 source of "it looks unstyled" bugs. If CSS 404s, confirm php artisan asset:publish caouecs/gumby2 ran and inspect public/packages/caouecs/gumby2. Paths and command flags differ slightly across L4 minor versions.
• Config publishing path. Published config goes to app/config/packages/caouecs/gumby2/, not app/config/. Editing the vendor copy is pointless; edit the published one.
• jQuery ordering. Gumby's JS depends on jQuery; loading Gumby before jQuery, or having two jQuery versions, produces silent plugin failures. Check the rendered <head> order.
• Initialization timing. gumby.init() called before DOM ready (or before scripts at the bottom) leaves modals/tabs inert. Put initialization after the script include, or wrap in $(function(){ gumby.init(); }).
• CSS override fights. Don't patch Gumby with !important sprinkled in views. Use Sass variables/partials, or scope overrides in one dedicated stylesheet loaded after Gumby.
• View overrides. In L4, package views can typically be overridden by placing matching files under app/views/packages/caouecs/gumby2/ (verify what the provider actually registers). If the package ships no views, you're writing partials yourself.
• No test suite, no CI, minimal docs. Validate behavior manually. Keep a smoke checklist: assets load, grid responds at breakpoints, modals open/close, forms validate, pagination renders.
• Dependency hygiene. Old packages can drag in outdated transitive dependencies. Run composer show caouecs/gumby2 and review the tree; isolate the app if it's internet-facing.
• Debugging workflow. Check app/storage/logs/laravel.log, render the raw HTML to confirm class names, use browser devtools to confirm the CSS file actually loaded, and confirm app/config/app.php provider registration if the publish commands don't appear in php artisan list.
• Extension points that matter: the service provider (registration/publishing), the published config, your own Blade partials, and a custom Sass build. There is no meaningful plugin/event surface beyond that.
• Exit strategy. Because the package is a thin asset wrapper, plan to replace it by dropping Gumby's compiled CSS/JS into public/ directly, or migrate to a maintained framework with a Vite/asset-pipeline setup on a supported Laravel version.