inly/core-web
inly/core-web is a Laravel/PHP package that provides reusable core web building blocks for Inly-based applications. It helps teams standardize shared components, integration points, and common infrastructure, reducing boilerplate and keeping project code consistent across web projects.
This package is a Statamic add-on configured mostly through feature flags (cloud, media, and friends) rather than one central config file, so start by reading the README sections for the features you intend to enable — the Laravel Cloud section in particular, because cloud intentionally changes behaviour rather than just adding it.
Minimal setup:
composer require <vendor>/<package>
php artisan vendor:publish # config + assets
Then look at, in this order:
config/statamic/assets.php — image_manipulation.cache (find it with grep -n "'cache' =>" config/statamic/assets.php). This is the setting cloud acts on.config/filesystems.php — favicons and social_images disks (grep -n "'favicons'\|'social_images'" config/filesystems.php). cloud + media remaps local-driver disks to the bucket.media.disks) — a disk listed there keeps its folder and needs no migration.First real use case: deploy to Laravel Cloud, then verify two things end-to-end — open a content page and confirm Glide URLs are /img/asset/...?s= (and render), and open a CP asset thumbnail. Then:
php artisan media:check --disk=favicons
php artisan media:check --disk=social_images
If the favicon link on a page answers a redirect to the bucket, you're wired correctly.
Treat cloud as an environment-shaped feature, not a switch you flip everywhere. On Cloud it disables Statamic's true and hybrid Glide caches so every /img/ URL is self-describing (signed, with secure on) and each container renders its own copies. Off Cloud, caching behaviour is unchanged. Consequence: never hardcode /img/containers/... in templates, tests, or CDN rules.
Keep Glide's cache on a disk of its own. That survives the cloud remap and is the sane default for multi-replica deployments; don't point it at a container-local public/img.
Generate favicons and social images into the bucket, not into git. With media on, local-driver favicons / social_images disks become media disks on the bucket under folders of the same name, and Peak's /favicons/... links redirect there. So the workflow becomes:
allow_uploads: true if it was turned off for Cloud).php artisan media:sync push --force once after the deploy.public/favicons.Roll the deploy command into your pipeline. core-web:deploy clears the static cache, which is required because image URL shape changes. If you're not using it, do the equivalent manually once per deploy.
Existing sites that already list these disks in media.disks keep their folders and need no changes — that's the "already correct" path and a good pattern to adopt deliberately.
/img/containers/... → /img/asset/...?s=. Anything matching /img/containers/ (static cache, CDN rules, tests, hardcoded markup) must be updated, then clear the static cache once.public/ wins over the bucket. Files committed to public/favicons are served before the redirect, silently masking the bucket copy. Delete them from git after media:sync push --force.true) on /img/ and 500s on CP thumbnails mean a stale Glide cache store being read by a different replica — not corrupt images. Check by hitting two containers or deploying twice.media:check --disk=favicons, media:check --disk=social_images, media:sync push --force. Grep the two config files above before assuming defaults; both behaviours are driven by those values.local driver. Renaming favicons / social_images, or keeping them out of media.disks, opts out of the remap if you genuinely need local-only behaviour on Cloud.How can I help you explore Laravel packages today?