{"id":11396,"date":"2026-05-30T18:30:21","date_gmt":"2026-05-30T10:30:21","guid":{"rendered":"https:\/\/aeosub.com\/zero-blocks-given\/"},"modified":"2026-05-30T18:30:21","modified_gmt":"2026-05-30T10:30:21","slug":"zero-blocks-given","status":"publish","type":"post","link":"https:\/\/aeosub.com\/zh\/zero-blocks-given\/","title":{"rendered":"Zero Blocks Given"},"content":{"rendered":"
\"Zero<\/div>\n
\n\n\n\n\n\n\n\n
Developer<\/th>\nMythThrazz<\/a><\/td>\n<\/tr>\n
Version<\/th>\nv1.2.2<\/td>\n<\/tr>\n
Active Installs<\/th>\n0 +<\/td>\n<\/tr>\n
Requires \/ Tested<\/th>\n6.0 \/ 7.0<\/td>\n<\/tr>\n
Last Updated<\/th>\n2026-05-30 10:26am GMT<\/td>\n<\/tr>\n
Official Link<\/th>\nView Details \u2192<\/a><\/td>\n<\/tr>\n<\/table><\/div>\n
Turn off WooCommerce \/ WP block frontend output at the code level. Four tiers, optional one-click settings, no paywall.<\/div>\n

Most WooCommerce stores ship 80-150 KB of block CSS and JS that the store never actually renders. The WC 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 global-styles<\/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>\n

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 wp-config.php<\/code>, pick a tier, done.<\/p>\n

How it works<\/h3>\n

Here’s the thing – WC registers its block hooks as closures wrapping instance methods on container-managed objects. So you can’t 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>\n

$bp = AutomatticWooCommerceBlocksPackage::container()->get( BlockPatterns::class );\nremove_action( 'init', [ $bp, 'register_block_patterns' ] );\n<\/code><\/pre>\n
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>\n
Four modes. Three ways to set them.<\/h3>\n
  Mode
\n  What it turns off
\n  When to use it<\/p>\n
  patterns<\/code>
\n  WC BlockPatterns<\/code> directory scanner only
\n  Block-based Cart\/Checkout – keeps all blocks rendering, just skips the file-I\/O scan<\/p>\n
  blocks<\/code>
\n  patterns<\/code> + BlockTypesController<\/code> + Notices<\/code> styles + wc-blocks-style<\/code> handle
\n  Classic-shortcode WC stores<\/p>\n
  all<\/code>
\n  blocks<\/code> + WP global-styles<\/code> pipeline + theme.json<\/code> + font-faces + head <style><\/code> strip
\n  Sites with no Gutenberg frontend at all<\/p>\n
  nuclear<\/code>
\n  all<\/code> + unregister_block_type()<\/code> for every core block
\n  Page-builder sites – strips the editor inserter clean<\/p>\n
Default is all<\/code>. Set the mode you want with any of these:<\/p>\n
    \n
  1. The <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>\n
  2. A constant in wp-config.php<\/code> – define( 'ZEROBLG_MODE', 'patterns' );<\/code>. This wins over the dialog. Good devops escape hatch.<\/li>\n
  3. A filter in a theme or mu-plugin – add_filter( 'zeroblg\/mode', fn() => 'blocks' );<\/code>. Used when neither the constant nor the dialog set a value.<\/li>\n<\/ol>\n
    Resolution order: constant, then settings, then filter, then all<\/code>. An invalid value at any step just falls through to the next.<\/p>\n
    A few real cases<\/h3>\n