A GeneratePress site’s customizations don’t live in one place. They live wherever a developer decided to hook in: a line in a child theme’s functions.php that targets generate_before_content, another targeting generate_after_entry_content, a third wired to generate_before_footer, and so on, built up one add_action() call at a time over however many years the site has existed. If you’re moving that site to Brndle, the free Sage/Acorn/Blade theme this site maintains, the uncomfortable truth is that none of those callbacks move with it. Not because the migration is badly executed, but because Brndle’s templates never call do_action( 'generate_before_content' ) in the first place. A GeneratePress-specific hook on a non-GeneratePress theme doesn’t throw an error and doesn’t get ignored with a warning. It just never fires. Silently. Forever.

That’s the real shape of this migration, and it’s a different shape from the one we covered in migrating a Kadence site to Brndle. Kadence’s extension model is a block library, so that migration is a block-by-block translation: a Kadence Row Layout becomes a core Columns block, a Kadence Accordion becomes brndle/tabs-accordion, and so on. GeneratePress’s extension model is PHP hooks fired from inside the theme’s own template files, which is a fundamentally different kind of problem. There’s no block tree to walk and no attribute schema to remap. There’s a set of named insertion points in GeneratePress’s PHP, a set of callbacks a developer wrote against them, and a Brndle theme that has no concept of “insertion points” at all – because in Brndle, the thing you’d normally hook into is the actual Blade view, open and editable, not a template tag that fires an action and moves on.

This post is the concrete version of that difference: GeneratePress’s real hook list (pulled directly from the free theme’s own PHP source, not guessed from documentation), a translation framework for deciding whether a given hook becomes a Brndle token-panel setting or a hand-written Blade edit, a worked example rebuilding a common conditional hook callback as Blade logic, and a realistic time estimate. We covered the pricing and philosophy differences between the two themes in GeneratePress vs Kadence vs Brndle: Hooks, Blocks, or Blade; this is the migration itself.

In this guide

Two different places to put the same customization

GeneratePress’s template files call do_action() at dozens of fixed points as they render – before the header, after the logo, before the loop, after each entry’s title, before the footer widgets, and many more. A developer who wants to add something at one of those points writes a plain add_action() call, usually in a child theme’s functions.php or a site-specific plugin, and GeneratePress’s own template code runs it at the right moment:

add_action( 'generate_before_content', function () {
    echo '<div class="promo-bar">Free shipping over $50</div>';
} );

Nothing about that line lives in a template file. The customization is a detached callback, registered against a named location, and GeneratePress’s header.php, content templates, and footer.php are what actually decide when it runs. GP Premium’s Hooks element (Appearance → Elements) extends this further for non-developers: the same named hook locations, but with a plain admin screen for pasting HTML or a shortcode and setting display rules, no code required.

Brndle doesn’t have an equivalent concept, by design. The theme is built on Acorn, Roots’ Laravel component bridge for WordPress, and every template renders through Blade views under resources/views/ – layout shells in resources/views/layouts/ (app.blade.php, landing.blade.php), header and footer sections in resources/views/sections/, and archive/single-post partials and the 20 native blocks’ own views under resources/views/partials/ and resources/views/blocks/, per the theme’s own GitHub source. There’s no detached callback layer sitting between a developer’s customization and the markup, because the Blade view is the markup. If you want a promo bar above the content, you don’t register a hook, you open header.blade.php (or whichever section file your build renders that area from) and add the line.

That’s not a worse system or a better one, it’s a different one, and the difference is exactly why this isn’t a find-and-replace job. A GeneratePress hook callback and a Brndle Blade edit don’t share a format any more than a Kadence block and a Brndle block do. What you’re doing is reading each hook callback, understanding what it’s actually trying to accomplish, and deciding where that intent lives in Brndle: a token the theme already exposes, a line added directly to the relevant Blade view, or genuine custom logic that has to be written because nothing like it exists yet. The rest of this post is that decision, made concrete.

GeneratePress’s real hook system, region by region

GeneratePress’s hook names aren’t officially published as a single canonical list in one place that stays current release to release, so we pulled them the reliable way: downloaded the current free theme straight from WordPress.org’s theme repository and grepped every do_action() call in the source. That’s the actual, shipping hook list, not a paraphrase of it. Grouped by the region of the page they fire in:

RegionHooks (verbatim from the theme source)
Header & logogenerate_before_header, generate_before_header_content, generate_after_header_content, generate_after_header, generate_before_logo, generate_after_logo, generate_minimal_header
Navigation & mobile menugenerate_before_navigation, generate_inside_navigation, generate_after_navigation, generate_after_primary_menu, generate_inside_mobile_menu, generate_inside_mobile_menu_bar, generate_inside_mobile_menu_control_wrapper, generate_after_mobile_menu_button, generate_menu_bar_items
Content wrapper (every template)generate_before_content, generate_after_content, generate_before_main_content, generate_after_main_content, generate_before_do_template_part, generate_after_do_template_part, generate_inside_container, generate_inside_site_container
Post/archive loopgenerate_before_loop, generate_after_loop, generate_before_page_title, generate_after_page_title, generate_before_archive_title, generate_archive_title, generate_after_archive_title, generate_after_archive_description, generate_paging_navigation
Single entry (post/page)generate_before_entry_title, generate_after_entry_title, generate_after_entry_header, generate_after_entry_content, generate_post_meta_items
Commentsgenerate_before_comments, generate_before_comments_container, generate_inside_comments, generate_below_comments_title, generate_before_comment_text, generate_after_comment_text, generate_after_comment_author_name
Sidebarsgenerate_before_left_sidebar_content, generate_after_left_sidebar_content, generate_before_right_sidebar_content, generate_after_right_sidebar_content
Footergenerate_before_footer, generate_before_footer_content, generate_after_footer_content, generate_after_footer_widgets, generate_after_footer, generate_minimal_footer, generate_before_copyright, generate_credits
Core WordPress (not GP-specific)wp_body_open – a WordPress core hook GeneratePress calls at the standard location, same as any modern theme

That’s roughly 50 action hooks in the free theme alone, before counting the ~124 apply_filters() calls layered on top for things like generate_header_class, generate_container_class, generate_footer_class, and generate_copyright – filters that let a developer adjust an HTML attribute or a string GeneratePress already outputs, rather than inject new markup. The action hooks are the ones a migration has to actually account for, because each one represents a point where a child theme or snippet plugin may have injected real content.

The translation approach: token setting, Blade edit, or custom logic

Every add_action() callback hooked into one of the names above falls into one of three buckets once you actually read what it does. Sorting your site’s hooks into these three buckets, before touching any code, is the single most useful thing you can do before estimating this migration.

Bucket one: pure presentation, already covered by a token. A callback that changes a color, a header height, a container max-width, a border radius, or a font pairing is doing something Brndle’s design-token system was built to do without any custom code at all. GeneratePress ships this kind of thing as filters (generate_header_class, generate_container_class) that a developer uses to swap in a different value computed from theme options or hard-coded CSS. Brndle exposes the equivalent surface through theme.json settings, the admin token panel, and documented filters like brndle/color_presets, brndle/font_pairs, and brndle/css_variables. If a GP hook callback’s entire job is “change how something already on the page looks,” it very often becomes a Customizer setting or a filter call instead of a Blade edit – genuinely less code than the GeneratePress version, because the token system already has an opinion about where that value lives.

Bucket two: static content injection. A callback that echos a fixed block of HTML – a promo bar, a trust badge row, a “back to top” link, a fixed newsletter signup snippet in the footer – isn’t dynamic at all. It runs the same way on every page load for every visitor. This is the bucket that maps most directly to “edit the Blade view”: open the section file that corresponds to where the hook fired (header, footer, the single-post partial, the archive partial) and add the markup inline, styled with the theme’s existing Tailwind utility classes instead of a separate CSS file. There’s no hook name to target and no priority argument to get right, because the content lives exactly where it displays.

Bucket three: conditional or dynamic logic. A callback that checks is_user_logged_in(), has_term(), current_user_can(), a custom field, a date comparison, or anything else that changes what renders based on who’s looking and when, is doing real application logic, not presentation. GP Premium’s Hooks element display rules (specific post types, user roles, logged-in state) live in this same bucket, just configured through a UI instead of code. This is the bucket with no shortcut: the condition and the markup both have to be rebuilt as actual Blade/PHP control flow – @if, @foreach, a real WordPress conditional – written directly inside whichever view renders that part of the page. It’s also the bucket where GP Premium’s non-developer audience loses the most: a marketer who could paste HTML into the Hooks element’s display-rule UI now needs a developer for the same change, because Brndle doesn’t ship a visual “insert content into this slot, under these conditions” admin screen. That’s a real, honest gap, not a detail to gloss over.

What the GP hook callback doesBrndle translationTypical effort
Changes a color, spacing value, border radius, or font via a filter (generate_header_class, generate_container_class, theme option CSS)Token-panel setting or a brndle/color_presets / brndle/css_variables filter callLow – often faster than the GP version
Echoes fixed HTML at a fixed location (promo bar, badge row, static CTA, copyright line addition)Direct edit to the relevant Blade view (sections/header.blade.php, sections/footer.blade.php, or the single/archive partial)Low to moderate – one-time edit, no hook to wire up
Checks role, login state, post type, taxonomy, custom field, or date before rendering contentCustom Blade/PHP logic (@if and a real WP conditional) written inline in the relevant viewModerate to high – genuine logic has to be rebuilt, not just moved
GP Premium Hooks element entry with a no-code display rule (role/post-type targeting via the admin UI)Same as above, but now requires a developer where it previously didn’tModerate – the content is simple, the loss of the no-code path is the real cost
Hooked into a sidebar region (generate_before_left_sidebar_content and similar)Likely no direct equivalent – see “What doesn’t translate at all” belowDepends entirely on what lived there

A worked example: a conditional after-content hook, rebuilt in Blade

Bucket three is where migrations actually take time, so it’s worth walking one all the way through. Say a GeneratePress site has this in its child theme, added at some point to put a newsletter CTA under tutorial posts, but only for visitors who aren’t already logged in:

add_action( 'generate_after_entry_content', function () {
    if ( ! is_singular( 'post' ) || is_user_logged_in() ) {
        return;
    }

    if ( ! has_tag( 'tutorial' ) ) {
        return;
    }
    ?>
    <div class="newsletter-cta">
        <h3>Want more tutorials like this?</h3>
        <p>Get a new one in your inbox every other week.</p>
        <a href="/subscribe" class="button">Subscribe</a>
    </div>
    <?php
} );

Three things are bundled into that one callback: a hook registration (generate_after_entry_content, which fires right after the post body on singular content), a two-part condition (singular post, tagged “tutorial”, and not already a logged-in visitor), and a block of markup styled by a .newsletter-cta class defined somewhere in the child theme’s separate style.css.

In Brndle, there’s no hook to register, because the single-post partial that renders a post’s content is itself the extension point – whatever view your build’s brndle/single_layout filter points at for singular posts. The condition and the markup move there directly:

@if (is_singular('post') && ! is_user_logged_in() && has_tag('tutorial'))
    <div class="mt-8 rounded-xl bg-surface-2 p-6 text-center">
        <h3 class="text-xl font-semibold text-ink">Want more tutorials like this?</h3>
        <p class="mt-2 text-ink-muted">Get a new one in your inbox every other week.</p>
        <a href="/subscribe" class="mt-4 inline-block rounded-lg bg-brand px-5 py-2.5 font-medium text-on-brand">
            Subscribe
        </a>
    </div>
@endif

Two differences are worth calling out, because they’re the pattern for every bucket-three hook, not just this one. First, the WordPress conditionals themselves (is_singular(), is_user_logged_in(), has_tag()) carry over completely unchanged – Blade is a templating layer on top of plain PHP, so any WordPress function call that worked in the GP callback works identically inside an @if. Nothing about the condition logic itself needs to be relearned. Second, the markup’s styling moved from a hand-written .newsletter-cta class in a separate stylesheet to Tailwind utility classes that read Brndle’s existing design tokens (bg-surface-2, text-ink, bg-brand, text-on-brand). That’s a real, if modest, win: the CTA now inherits whatever color scheme and spacing scale the rest of the site uses, automatically, instead of carrying its own fixed hex values that drift the moment the site’s brand colors change.

What this worked example does not show is a shortcut. The developer still has to read the original callback, understand its condition, find the right Blade view, and write equivalent markup. The time saved is in not needing a hook registration, a priority argument, or a separate stylesheet entry – not in the thinking required to get the condition right.

What doesn’t translate at all

Three categories of GeneratePress hook usage hit a real wall in Brndle, and it’s worth being direct about each one before anyone commits to this migration.

Sidebar-region hooks have nothing to port to on a typical Brndle build. generate_before_left_sidebar_content, generate_after_left_sidebar_content, and their right-sidebar equivalents exist because GeneratePress supports classic PHP widget areas. Brndle, as a block theme built around the native block editor and server-rendered blocks, isn’t built around classic sidebar widget areas the same way – if your specific build doesn’t register one, content that lived in a GP sidebar via these hooks (a widget-area-adjacent CTA, a persistent “related posts” box) has no slot to move into. It becomes content placed directly on the page with blocks, which is a real information-architecture change, not a one-line Blade edit. Confirm whether your Brndle build registers any sidebar before assuming these hooks have somewhere to go.

GP Premium’s Hooks element loses its entire audience, not just its UI. The reason the Hooks element exists is to let a non-developer – a marketer, a site owner, a junior team member – add or change hook-location content without touching code. Every one of those entries, once migrated, needs a developer to open a Blade view and add the equivalent logic. If the GP site’s non-technical team was actively using the Hooks element for ongoing changes (seasonal banners, promo content, role-based messaging), that workflow doesn’t survive the migration in any form. Plan for who does that work going forward, because it won’t be the same person it was on GeneratePress.

GenerateBlocks content inserted through a hook location is two migrations stacked, not one. Some GP Premium sites use the Hooks element or a direct hook callback to inject a GenerateBlocks pattern (a Container/Grid/Headline composition) at a specific location, rather than plain HTML. That content needs the same hook-to-view translation covered in this post, plus a separate block-level rebuild in whichever Brndle block or core block the pattern maps to – the same kind of block-mapping work covered for Kadence Blocks in our Kadence migration guide, just triggered from a hook instead of placed in the main content area.

What does carry over cleanly: wp_body_open itself, since it’s a WordPress core hook both themes call at the same standard location, not a GeneratePress invention – any plugin hooked into it (most tracking-script and consent-banner plugins use it) keeps working without any migration effort at all. Post and page text, images, and anything that was never hook-dependent content in the first place also move through standard WordPress export/import untouched.

The migration process, step by step

  1. Inventory every generate_* hook callback registered on the site. Search the active child theme’s functions.php and any site-specific or snippet plugin for add_action( 'generate_, and separately list every entry configured in GP Premium’s Hooks element (Appearance → Elements) if that’s installed. For each one, note the hook name, what it outputs, and whether it’s conditional. Skip this step and every later estimate is a guess.
  2. Sort every callback into bucket one, two, or three using the translation table above – token setting, static Blade edit, or custom logic. This single sort is what turns a vague “we use a lot of hooks” into an actual scope.
  3. Stand up Brndle on a staging clone, not the live site. Same rule as any theme switch: clone first, do all rebuild work on the clone, keep the live site untouched until cutover.
  4. Rebuild the token-driven items first (bucket one). Pull brand colors, fonts, and spacing choices into Brndle’s token panel and theme.json settings before touching individual hook callbacks – every later Blade edit should read from these tokens, not hard-coded values.
  5. Rebuild static content hooks (bucket two) directly in the relevant Blade view. Header and footer items go in resources/views/sections/; content-area items go in the archive or single-post partial under resources/views/partials/. Match the original hook’s position (before/after the equivalent region) as closely as the Blade view’s structure allows.
  6. Rebuild conditional hooks (bucket three) as real Blade/PHP logic, one at a time, testing each condition against the same scenarios the original callback handled (logged in vs. logged out, each relevant post type or taxonomy term).
  7. Flag every sidebar-region and Hooks-element item explicitly and decide, in writing, where that content lives now – a page block, a different template region, or genuinely dropped. Don’t discover a sidebar dependency mid-rebuild.
  8. Test every migrated condition at the actual states it depends on – logged in and logged out, each post type or tag the logic checks, mobile and desktop if the original callback had responsive behavior baked into its CSS.
  9. Cut over on a quiet window, and keep the old child theme (deactivated, not deleted) around for a defined period so you can re-read any hook callback you missed without restoring from backup.

A realistic time and effort estimate

The variable that actually predicts how long this takes is the bucket-three count, not the total number of hooks. A site with twenty hook callbacks that are all bucket-one color tweaks rebuilds in an afternoon. A site with five callbacks, three of which carry real conditional logic, takes longer. Use the inventory from step 1, sorted by bucket, against this table rather than a flat per-hook number.

ScopeRealistic estimateWhy
Hook inventory and bucket sort (step 1–2)2–4 hoursReading every callback and the Hooks element entries, one by one – the step that makes every later number real instead of guessed.
Token panel + theme.json setup, covering all bucket-one items3–6 hours, one-timePulls colors, fonts, and spacing into Brndle’s system once; every later Blade edit depends on this being right.
Per bucket-two hook (static content, direct Blade edit)20–60 minutes eachMostly markup re-entry into the right view, styled with existing token classes instead of new CSS.
Per bucket-three hook (conditional logic rebuilt in Blade/PHP)1–4 hours eachWide range because it depends entirely on how many conditions the original callback checked and how it interacts with other logic in the same view.
Per Hooks-element entry with a no-code display rule1–3 hours eachSame rebuild work as a bucket-three hook, plus the overhead of translating a UI-configured rule into explicit code for the first time.
Sidebar-region content, if any exists and has no sidebar to move to2–6 hoursThis is page-architecture work, not a hook translation – deciding where the content lives now, then building it there.
QA pass per migrated condition (both states, mobile and desktop)15–30 minutes per conditionNon-negotiable for bucket three specifically – a condition that silently shows to the wrong audience is worse than one that’s simply missing.

Put concrete numbers on it: a mid-sized agency site with 15–20 registered generate_* hooks, where roughly a third are bucket-one style tweaks, half are static bucket-two content, and the remainder are genuinely conditional, lands somewhere around 20–35 hours of focused work from inventory to cutover. A site leaning heavily on GP Premium’s Hooks element for ongoing marketer-driven content, or with sidebar-dependent widgets, moves past that range because of the architectural decisions those two categories force, not because the code itself is harder to write.

Pre-migration checklist

  • Full backup of the live site (database and files), taken and verified restorable, before any staging work begins.
  • Complete hook inventory: every add_action( 'generate_ callback in the child theme and any snippet plugin, plus every GP Premium Hooks element entry – not an estimate.
  • Every item sorted into bucket one (token), bucket two (static Blade edit), or bucket three (conditional logic), in writing.
  • Every sidebar-region hook explicitly flagged, with a decision made for where that content lives in the Brndle build – not deferred.
  • A named owner identified for any content that previously went through GP Premium’s Hooks element UI – since that self-service path doesn’t carry over, decide now who handles the equivalent change requests going forward.
  • Brand colors, fonts, and spacing values pulled out of GeneratePress’s Customizer and filters, written down as a starting Brndle token palette.
  • Staging environment cloned from production, with outgoing email disabled on the clone.
  • Any plugin that hooks into GeneratePress-specific actions or filters (not just WordPress core ones like wp_body_open) identified and checked – it will silently stop firing on Brndle unless rebuilt.
  • A rollback plan: the old child theme and GeneratePress stay installed and inactive for a defined window after cutover, not removed on day one.

Questions about migrating from GeneratePress to Brndle

Will old GeneratePress hook callbacks throw an error on Brndle if I leave them in a plugin?

No, and that’s exactly what makes them easy to miss. A GeneratePress-specific add_action() call sitting in an active plugin on a Brndle site doesn’t error, doesn’t warn, and doesn’t appear anywhere in the debug log. It simply never executes, because nothing in Brndle’s Blade views calls do_action( 'generate_before_content' ). If you don’t inventory hooks before cutover, you won’t find out content is missing until someone notices it’s gone.

Is there an automatic converter from GeneratePress hooks to Brndle Blade views?

No. Nothing in Brndle’s source or documentation converts hook callbacks automatically, and a hook-to-template translation isn’t the kind of thing a tool can safely automate anyway – deciding whether a callback’s logic belongs in a token, a static edit, or custom code requires understanding what it’s actually for, which a script can’t infer from the PHP alone.

Do I need to know Laravel to rebuild these hooks as Blade views?

You need comfort with Blade’s syntax (@if, {{ }}) and standard WordPress conditionals (is_singular(), has_tag(), and the rest), which carry over from PHP unchanged. You don’t need deep Laravel framework knowledge – Brndle uses Acorn specifically to bring Blade’s templating syntax into WordPress, not a full Laravel application stack. The learning curve is closer to “a new templating syntax” than “a new framework.”

What happens to GP Premium’s Hooks element content specifically?

Every Hooks element entry needs the same bucket sort as a coded hook callback, then the same rebuild: static content becomes a direct Blade edit, content with display rules becomes conditional Blade/PHP logic. What doesn’t carry over is the no-code editing workflow itself – once rebuilt, future changes to that content require a developer opening a Blade view, not a marketer editing an admin screen.

Does Brndle have anything like GeneratePress’s Hooks element for non-developers?

No. Brndle’s customization surface for non-developers is the block editor (composing pages from the 20 native blocks) and the admin token panel for colors, fonts, and layout settings. Neither one is a general-purpose “inject arbitrary content at a named location, with display rules” tool the way the Hooks element is. If that specific no-code capability is load-bearing for your team, it’s a real gap worth weighing before migrating.

What about hooks that insert GenerateBlocks content instead of plain HTML?

That’s two migrations in one: the hook-to-view translation covered in this post, plus a block-level rebuild of whatever GenerateBlocks pattern was being inserted, in whichever Brndle block or core WordPress block it maps to. Treat it as a bucket-two or bucket-three hook (depending on whether it’s conditional) that also needs its content rebuilt as blocks, not just markup.

Do hooks like wp_body_open still work on Brndle?

Yes. wp_body_open is a WordPress core hook, not a GeneratePress-specific one, and Brndle calls it at the same standard location every modern theme does. Any plugin hooked into it – most analytics, tag-manager, and consent-banner plugins use it – keeps working with no migration effort. The hooks that break are specifically the ones prefixed generate_, because those only exist because GeneratePress’s own template files call them.

What happens to content injected via GeneratePress’s sidebar hooks?

Check first whether your Brndle build registers a classic sidebar widget area at all – many block-theme builds don’t, since the native block editor and server-rendered blocks cover what a sidebar traditionally did. If there’s no equivalent region, content that lived there via generate_before_left_sidebar_content or similar needs to be re-architected as blocks placed directly on the page, which is a content-placement decision, not a code translation.

Can I run GeneratePress and Brndle side by side during a phased migration?

Not in the sense of partial activation – a WordPress site has one active theme at a time, so this is a full theme switch, not an incremental rollout. What you can phase is the rebuild work itself: do the bucket sort and build out Brndle on staging over time, then cut over once every bucket-three item has been tested, the same discipline as any theme migration.

How is this different from migrating a Kadence Blocks site to Brndle?

The mechanics are different because the source extension model is different. A Kadence migration is a block-to-block translation – matching attribute schemas and content fields between two block libraries, covered in our Kadence migration guide. A GeneratePress migration is a hook-to-view translation – reading PHP callbacks registered against named insertion points and deciding whether each one becomes a token, a static edit, or real logic in a Blade file. Neither is faster or slower across the board; it depends on how much of each site’s customization is bucket three (conditional logic) versus bucket one or two (style and static content).

Should you actually do this?

If your GeneratePress site’s hook usage is mostly bucket one and two – style tweaks that already have a Brndle token to land in, and static content that’s a straightforward Blade edit – this is a reasonable, well-scoped migration, and it closes with a real payoff: a theme-native design system with nothing to license, ever, and customization that lives in version-controlled template files instead of a scattered set of detached callbacks. If your site leans on bucket-three conditional logic, GP Premium’s Hooks element for non-developer content changes, or genuine sidebar-dependent widgets, be honest about that cost going in: each of those needs real development work to rebuild, and the Hooks element specifically means losing a no-code workflow your team may actively rely on.

Either way, start with the inventory, not the rebuild. Read every hook callback before estimating what it costs to move, because “we use GeneratePress hooks” can mean five trivial style filters or fifteen conditionals wired to user roles and taxonomy terms, and those are very different projects wearing the same description. Brndle’s source is free on GitHub, so you can install it on a staging clone and test the bucket sort against your own real hooks before touching the live site. And if a bucket-three rebuild turns out to need functionality beyond what a Blade view and a filter expose, our walkthrough on registering a custom Brndle block covers the next step past a template edit.