Skip to content
Managing Blocks

Blocks Screen

WordPress Admin → Lazy Blocks → Blocks lists every block on the site. Its columns are Icon, Title, Slug, Category and Description, there is no Quick Edit on a row, and Add Block opens the block builder.

Active and inactive

A block has two usable states. publish means active, draft means inactive, and every other status is reset back to draft when the post is saved, so Pending, Private and Scheduled never apply to a block.

The view links above the table read Active and Inactive rather than Published and Draft, and an inactive block carries an Inactive label after its title.

Each row carries one link for the switch, Deactivate while the block is active and Activate otherwise. It takes the edit_lazyblock capability for that block. Both are bulk actions as well, so a whole selection flips at once.

After the redirect the screen prints a notice. A single block gives Block "Pricing Table" activated successfully., a selection gives Activated 3 blocks.

What an inactive block stops doing

Deactivating is not a soft switch. An inactive block is never registered at all, in the admin as well as on the front end.

Three things follow:

  • The block is missing from the editor inserter.
  • Posts that already use it hold a block name that is no longer registered, so the editor cannot render it.
  • On the front end those posts print the block's inner blocks and nothing else, because a lazy block saves no markup of its own.

A block you saved but never published is inactive, which is the usual answer to a block that will not show up in the inserter.

Duplicate

Duplicate is a row action with no bulk equivalent. It takes the edit_lazyblocks capability and reports Added new block 'Pricing Table (Copy)'.

The copy takes the original's post fields, every taxonomy term and its post meta. Three things change:

  • post_author becomes the user who clicked, not the original author.
  • The title gains a (Copy) postfix, and only when it does not already contain one. Duplicating a copy therefore leaves two blocks under the same title.
  • The copy gets a slug of its own, so the two blocks never register under one name.

A copy of lazyblock/my-block registers as lazyblock/my-block-2 and arrives Inactive. With Pro the prefix can be something other than lazyblock, which Collections & Namespaces covers.

Export

Export on a row downloads that one block as JSON, and it is a bulk action too. Both need edit_lazyblocks. The full Export / Import screen under the same menu is gated separately on manage_options, so a user who can build blocks may still be unable to open it.

Clear Cache

Clear Cache sits with the view links above the table and empties the blocks cache. It needs manage_options. Saving a block clears the same cache on its own, so this link is for the cases where something else changed. Performance lists them.

Who can build blocks

The lazyblocks post type declares its own capabilities instead of reusing the ones for posts:

CapabilityStandard capabilityNeeded for
edit_lazyblocksedit_poststhe Blocks menu, the list screen, and adding a block
edit_lazyblockedit_postopening one block in the builder, and the row switch
publish_lazyblockspublish_postspublishing a block from the builder
edit_other_lazyblocksedit_others_postsblocks another user created
read_lazyblockread_postreading one block
read_private_lazyblocksread_private_postsreading private blocks
delete_lazyblocksdelete_postsdeleting blocks
delete_lazyblockdelete_postdeleting one block

The plugin hands these out on activation:

CapabilityAdministratorEditorAuthorContributorSubscriber
edit_lazyblocksyes----
edit_lazyblockyes----
edit_other_lazyblocksyes----
publish_lazyblocksyes----
read_lazyblockyesyesyesyes-
read_private_lazyblocksyesyesyesyes-
delete_lazyblocksyes----
delete_lazyblockyes----

Only the Administrator can build a block out of the box. Editor, Author and Contributor get the two read capabilities and nothing else, and Subscriber gets none. There is no screen for changing this, and the plugin only ever adds capabilities, so anything you take away stays away.

Grant the rest in code. add_cap() writes to the database, so guard it rather than running it on every request:

PHP
function my_lzb_grant_editor_caps() {
  if ( get_option( 'my_lzb_editor_caps_done' ) ) {
    return;
  }
 
  $role = get_role( 'editor' );
 
  if ( ! $role ) {
    return;
  }
 
  // Enough to open the Blocks screen, add a block, save it and publish it.
  $role->add_cap( 'edit_lazyblocks' );
  $role->add_cap( 'edit_lazyblock' );
  $role->add_cap( 'publish_lazyblocks' );
 
  update_option( 'my_lzb_editor_caps_done', 1 );
}
 
add_action( 'init', 'my_lzb_grant_editor_caps' );

Add edit_other_lazyblocks when the user should work on blocks somebody else built, and delete_lazyblocks with delete_lazyblock when they should be able to remove blocks. The lazyblocks_templates post type declares the same eight capabilities, so the Templates screen follows the Blocks screen with no extra grants.

Leave publish_lazyblocks out and the builder offers no Publish button, so a new block stays inactive. The row Activate link takes edit_lazyblock alone and still switches the block on.

Was this article helpful?

Copyright © 2026 Lazy Blocks.