Acorn Prettify Laravel Package

Getting Started

Install

composer require roots/acorn-prettify

Acorn's package discovery handles the service provider registration in most setups. If your theme's config/app.php maintains an explicit provider list (or you've disabled discovery), add the package's PrettifyServiceProvider there.

Publish and read the config first

wp acorn vendor:publish --tag=prettify   # check `wp acorn vendor:publish --list` if the tag differs

That drops config/prettify.php into your theme. This file is the whole API surface: an array of module class names, each commented in or out. Read it before reading anything else. The module list changes between releases, so the authoritative answer to "what can this do?" is the published config plus vendor/roots/acorn-prettify/src/Modules/ — the package is small enough to skim end-to-end in under an hour, which is the right investment given its size and activity level.

First use case: kill the WordPress bloat

Enable the cleanup-style modules (emoji script, oEmbed discovery links, generator meta, RSD/wlwmanifest, block library CSS on non-block pages — naming varies by version), then verify with view-source: on the front end and the network tab. This is the lowest-risk, highest-signal introduction: it's pure output filtering, breaks nothing transactional, and confirms the provider is booting and the config is being read.

If nothing changes, run wp acorn config:clear — a stale cached config is the single most common "the package isn't working" cause.

Implementation Patterns

Config as the switchboard. Treat config/prettify.php as your front-end behaviour manifest. Comment modules in per project rather than deleting lines, so diffs stay readable and you can point at a line when a client asks why something changed.

Environment-aware toggles. Because the config is plain PHP, you can gate noisy development-only modules:

'modules' => array_filter([
    Roots\AcornPrettify\Modules\CleanUp::class,
    Roots\AcornPrettify\Modules\NiceSearch::class,
    app()->isLocal() ? Roots\AcornPrettify\Modules\DebugSomething::class : null,
]),

Use this sparingly — it hides behaviour from production config review. Prefer explicit per-environment config files if your Acorn version supports them, or a small PRETTIFY_* env flag.

Extend, don't fork. Each module is a small class that hooks into WordPress during boot. When you need a variation, subclass the module, override the specific add_action/add_filter call, and swap the class name in the config array. Your subclass lives in app/ (or app/Prettify/) and is version-controlled with the theme, while the vendor package stays upgradeable.

Check for module filters before subclassing. Well-behaved modules expose apply_filters hooks around their output. Grep the module source for apply_filters — if there's a hook, use it; that's a one-line change versus a class you now own forever.

Pair with Blade, don't duplicate it. These modules are theme-agnostic by design, which means they should only touch WordPress's own output — <head> contents, nav markup, query behaviour. Your theme's markup belongs in Blade components. The moment you're using a module to shape something you already control in a view, you've added a second place to look for a bug.

Integrate deliberately with plugins. Before enabling a module, ask which plugin already owns that concern: SEO plugins own <title> and canonical tags, cache plugins own asset URLs, security plugins own REST API access. Pick one owner per concern. Duplicated ownership is the source of nearly every "this module broke the site" report.

Ship the config with the theme. Because the package is installed per theme, config/prettify.php is the natural place to record per-site front-end decisions — it travels with the code through Deployer and shows up in code review, unlike a wp-admin toggle.

Gotchas and Tips

Modules are global side effects. Every module hooks WordPress on boot. On a multisite network, confirm whether the theme (and therefore the package) is active per-site or network-wide before assuming scope.

Relative URLs and nice search are the risky ones. Relative-permalink modules interact badly with feeds, sitemaps, JSON-LD, canonical tags, and any consumer that expects absolute URLs — including a CDN or reverse proxy in front of the site. Nice-search modules hook pre_get_posts and can change results for REST consumers and search plugins. Enable these on a staging copy and test search, feeds, and the sitemap, not just the homepage.

Don't fully disable the REST API if the block editor, Acorn's own tooling, or a headless front end depends on it. Restrict unauthenticated access instead of removing the endpoints.

Config caching will bite you on deploy. If your pipeline caches config at build time, module changes require a rebuild/redeploy, not just a file edit. Locally, wp acorn config:clear after every config change. Make this a reflex.

Filter priority collisions. When a module and your own filter target the same hook (the_content, wp_head, nav_menu_args), the module's hardcoded priority determines who runs first. Inspect with has_filter() / global $wp_filter or Query Monitor rather than guessing from output order.

Debugging checklist, in order: is the provider registered (wp acorn about or the container bindings in wp acorn tinker)? Is config('prettify.modules') what you expect? Is config cached? Is a plugin already doing the same thing? Only then read the module source.

Version-pin and lock. At 62 stars this is a small, low-traffic package in a pre-1.0 lifecycle where class names and module lists have moved between releases. Pin a compatible constraint, commit composer.lock, and read the changelog before every bump. Budget for the occasional upstream rename rather than assuming API stability.

Upgrade strategy: the package is small — diff src/Modules/ between versions before upgrading, and keep your subclassed modules listed in one place so you can verify each override still matches the parent's hook signatures.