MythThrazz

<p>Most WooCommerce stores ship 80-150 KB of block CSS and JS that the store never actually renders. The WC <code>BlockPatterns</code> scanner is the one that bugs me most – it hits the filesystem on every request to scan a directory of pattern templates you don’t use. Then add core WP <code>global-styles</code>, <code>wp-block-library</code> and font-faces on top, and you’re loading a Gutenberg frontend you probably switched off a long time ago.</p>
<p>Zero Blocks Given turns it off at the source, through WooCommerce’s own dependency injection container. No CSS dequeue band-aid, no UI checkboxes, no PRO upsell. One constant in <code>wp-config.php</code>, pick a tier, done.</p>
<h3>How it works</h3>
<p>Here’s the thing – WC registers its block hooks as closures wrapping instance methods on container-managed objects. So you can’t <code>remove_action()</code> them by string. You have to fetch the same instance back from the DI container and pass it in as the callable. That’s what this does:</p>
<pre><code>$bp = \Automattic\WooCommerce\Blocks\Package::container()->get( BlockPatterns::class );
remove_action( 'init', [ $bp, 'register_block_patterns' ] );
</code></pre>
<p>The DI-container path is the one that survives WC upgrades cleanly. String-callback matching and dequeue tricks tend to drift every release, so I went with the container.</p>
<h3>Four modes. Three ways to set them.</h3>
<p>  Mode<br />
  What it turns off<br />
  When to use it</p>
<p>  <code>patterns</code><br />
  WC <code>BlockPatterns</code> directory scanner only<br />
  Block-based Cart/Checkout – keeps all blocks rendering, just skips the file-I/O scan</p>
<p>  <code>blocks</code><br />
  <code>patterns</code> + <code>BlockTypesController</code> + <code>Notices</code> styles + <code>wc-blocks-style</code> handle<br />
  Classic-shortcode WC stores</p>
<p>  <code>all</code><br />
  <code>blocks</code> + WP <code>global-styles</code> pipeline + <code>theme.json</code> + font-faces + head <code><style></code> strip<br />
  Sites with no Gutenberg frontend at all</p>
<p>  <code>nuclear</code><br />
  <code>all</code> + <code>unregister_block_type()</code> for every core block<br />
  Page-builder sites – strips the editor inserter clean</p>
<p>Default is <code>all</code>. Set the mode you want with any of these:</p>
<ol>
<li>The <code><dialog></code> settings – click the Settings link on the Plugins screen. Native HTML dialog, four radios, save. No menu items, nothing else added to your admin.</li>
<li>A constant in <code>wp-config.php</code> – <code>define( 'ZEROBLG_MODE', 'patterns' );</code>. This wins over the dialog. Good devops escape hatch.</li>
<li>A filter in a theme or mu-plugin – <code>add_filter( 'zeroblg/mode', fn() => 'blocks' );</code>. Used when neither the constant nor the dialog set a value.</li>
</ol>
<p>Resolution order: constant, then settings, then filter, then <code>all</code>. An invalid value at any step just falls through to the next.</p>
<h3>A few real cases</h3>
<ul>
<li>Service-form site on WC. You sell consultations, not products – no cart, no checkout. <code>mode=all</code> strips every block stylesheet across the site.</li>
<li>Classic-shortcode WC store. You use <code>[woocommerce_cart]</code> and <code>[woocommerce_checkout]</code>, no block UI. <code>mode=blocks</code> turns off the block frontend without touching your classic flow.</li>
<li>Block-checkout store with bloated patterns. You run the new Cart/Checkout blocks but never the WC pattern library. <code>mode=patterns</code> skips just the directory scanner – saves the disk hit, leaves your checkout alone.</li>
<li>FrankenPHP / worker mode. All hooks are idempotent, no <code>$GLOBALS</code> writes, <code>\Throwable</code> catches around the DI lookups. Safe in a worker.</li>
<li>Elementor / Divi WC stores. The page builder renders its own checkout, so <code>mode=all</code> clears the WC and WP block CSS your theme never uses anyway.</li>
</ul>
<h3>Why I built it this way</h3>
<ul>
<li>Activate it and it works – <code>mode=all</code> is the default, no setup needed.</li>
<li>No settings page to learn. One constant or one filter is the whole API.</li>
<li>Pure PHP. No database rows, no admin scripts, no frontend JS.</li>
<li>No external requests, no tracking, nothing phoning home. GDPR is a non-issue.</li>
<li>It uses the same <code>Package::container()</code> lookup as WC core, so it follows WC’s own object lifecycle instead of guessing.</li>
<li>Worker-safe – FrankenPHP, Roadrunner, Swoole. No <code>die</code>, no <code>exit</code>, no session writes.</li>
<li>mu-plugin friendly. Drop the folder into <code>wp-content/mu-plugins/</code> and it loads itself.</li>
<li>GPL, no upsells. No PRO tier, no Freemius, no admin notice nagging you for a review.</li>
</ul>
<h3>From the maker of WP Multitool</h3>
<p>This plugin handles the frontend block bloat. If you also want the backend cleaned up, that’s what <a href="https://wpmultitool.com/" rel="nofollow ugc">WP Multitool</a> does – slow queries, autoload bloat, the database bottlenecks that caching plugins just hide instead of fixing. Most optimization plugins guess at the problem. WP Multitool runs <code>EXPLAIN</code> and shows you. 14 tools in there – slow-query analyzer, autoload optimizer, index suggestions, fatal-error recovery – and a free site scanner if you want to see what’s slow before paying for anything. If Zero Blocks Given earned a spot in your stack, that one probably will too.</p>


Zero Blocks Given

Turn off WooCommerce / WP block frontend output at the code level. Four tiers, optional one-click settings, no paywall.

atomjb

<p>Rootstuff Block Permissions is a lightweight block manager that lets you hide or disable Gutenberg blocks and block patterns per user role and per post type. Tick what you want hidden, save, and your clients only see the blocks they actually need.</p>
<p>Unlike generic block managers, every rule is scoped by <strong>role</strong> and <strong>post type</strong>, so editors can have a different toolkit on Pages than on Posts, contributors can be locked down further, and administrators can be exempt entirely (or included for previewing the client experience).</p>
<h4>What it does</h4>
<ul>
<li>Hide any registered block from the inserter — core, theme, plugin, ACF blocks, anything.</li>
<li>Hide block patterns the same way.</li>
<li>Optional per-role overrides (Editor, Author, Contributor, custom roles).</li>
<li>Optional per-post-type overrides (Posts, Pages, custom post types).</li>
<li>Combine both: e.g. “Editor on Page only” gets a different set than “Editor on Post”.</li>
<li>Disable the WordPress.org remote pattern directory.</li>
<li>Disable WordPress core patterns entirely.</li>
</ul>
<h4>Why a separate plugin</h4>
<p>Most block-management plugins are global — they hide a block for everyone, everywhere. That breaks down the moment you have multiple client roles or different post types with different needs. Rootstuff Block Permissions lets you say “hide the Cover block for Authors on Pages, but keep it for Editors on Posts” without writing any code.</p>
<h4>Mental model</h4>
<p>The plugin is a <strong>denylist</strong>. An empty list means nothing is blocked. You tick what you want to hide. New blocks added to the site later are automatically allowed unless you come back and tick them.</p>
<p>A <strong>default rule</strong> applies to everyone unless you create an override. Overrides are matched most-specific-first:</p>
<ol>
<li>Exact role and exact post type</li>
<li>That role on any post type</li>
<li>Any role on that post type</li>
<li>The default rule</li>
<li>None of the above — no restrictions</li>
</ol>
<p>Multi-role users get the <strong>least restrictive</strong> of their roles’ resolved rules: a block is hidden only if every one of their roles’ rules hides it.</p>
<h4>Administrators</h4>
<p>By default, administrators bypass all restrictions. There’s an “Apply to administrators” toggle so you can preview the client experience without switching accounts.</p>
<h4>Privacy</h4>
<p>The plugin stores its configuration in a single WordPress option (<code>rootstuff_bp_settings</code>). It does not connect to any external service, send analytics, or store data about your users.</p>
<h4>Development</h4>
<p>Source code is available on GitHub: <a href="https://github.com/rootstuff/rootstuff-block-permissions" rel="nofollow ugc">https://github.com/rootstuff/rootstuff-block-permissions</a></p>
<p>The <code>build/admin.js</code> file is generated from the <code>src/</code> directory using <code>@wordpress/scripts</code>. To rebuild from source:</p>
<ol>
<li>Clone the repository.</li>
<li>Run <code>npm install</code>.</li>
<li>Run <code>npm run build</code>.</li>
</ol>


Rootstuff Block Permissions

Block manager for the WordPress block editor: disable or hide Gutenberg blocks and patterns per user role and post type.

Zero Blocks Given vs Rootstuff Block Permissions