No — this action fires as notification, not permission. It can't stop the delete from proceeding.

Not yet — metadata generation happens afterward. Hook wp_generate_attachment_metadata if you need sizes or EXIF data.

Yes — hook wp_logout (or the logout_redirect filter for more control over the target URL) and call wp_safe_redirect() followed by exit.

Yes, that's a very common pattern — check current_user_can() and wp_redirect() + exit if the check fails, being careful to allow admin-ajax.php requests through.

Yes, but it's primarily meant for themes. Plugins usually use plugins_loaded or init instead.

No — regular (non-mu) plugins have not loaded yet at this point. That is exactly what plugins_loaded is for.

Only if you need the REST request object itself — headers, route, or client-specific data that save_post doesn't expose.

No — a block (FSE) theme has no footer.php to edit. WordPress calls wp_footer() automatically after the block template renders, so anything hooked here still prints right before </body>.

Yes — it fires from wp_insert_attachment() regardless of whether the upload came from wp-admin, the REST API, or a programmatic call.

No. Moving a post to Trash fires wp_trash_post instead. before_delete_post only fires for a permanent/hard delete — either from Trash or via force-delete.

No — that path fires rest_insert_attachment instead. edit_attachment is specific to the classic wp-admin edit form.

No — this hook is editor-only, even in a block theme. For assets needed both in the editor and on the front-end (e.g. a block's own styling), use enqueue_block_assets instead.

Yes — WordPress calls this hook unconditionally on every request, whether the mu-plugins folder has files in it or not.

No — both fire. rest_insert_post adds the request context on top of what save_post already gives you.

Yes — any path that goes through wp_insert_user() triggers it, including admin-created accounts and REST API user creation.

Yes. WordPress auto-inserts wp_head()/wp_footer() around the block-based template output, so every callback you register still runs — you just never see or edit the call site yourself.

No — it fires only for the standard wp_signon() cookie-based login flow, not REST authentication.

Check that $new_status === 'publish' && $old_status !== 'publish' inside transition_post_status.

Add error_log($hook_suffix) inside the callback and check your PHP error log while on the target screen, or use get_current_screen()->id.

Add the is-dismissible CSS class to the notice div and enqueue wp-admin's built-in dismiss script, or track dismissal yourself via user meta.

Once daily, as one of WordPress's built-in scheduled events.

Not if it's synchronous — save_post runs inside the save request itself, so slow logic on a large database can lock tables and delay the editor's save response. Offload it to a queue or scheduled event (e.g. Action Scheduler or wp_schedule_single_event) instead.

Yes for some setups — use init instead; plugins_loaded is for dependency checks, not registering WordPress objects.

Yes — the file and its generated sizes are still present; this is the last point where get_attached_file() returns a valid path.

No — that's enqueue_block_editor_assets (editor only) or enqueue_block_assets (editor + front-end). wp_enqueue_scripts only runs for the public front-end.

block.json's style/editorStyle properties are the modern, preferred way for a registered block's own CSS. enqueue_block_assets is better for shared/global styling that isn't tied to one specific block registration.

No. Hook wp_enqueue_scripts, then let core print the tags during wp_head.

Use save_post for editor-driven saves; use wp_insert_post if you also need to catch posts created programmatically outside the editor.

1 for approved, 0 for pending moderation, or the string 'spam' — check it before triggering notifications so you don't email admins about spam.

save_post also fires for attachments since they're a post type, but edit_attachment is scoped specifically to the dedicated media-edit admin screen.

init runs first and is where you register things; wp_loaded runs after all init callbacks finished, so it's safer for code that reads what other plugins registered.

Set proper dependency arrays (e.g. ['jquery']) in wp_enqueue_script() instead of relying on hook priority to control load order.

You likely modified every WP_Query, not just the main one. Add $query->is_main_query() to the condition.

WP-Cron is pseudo-cron — it only checks for due events on incoming site requests, so timing depends on traffic unless a real system cron drives it.

The REST server object doesn't exist yet on earlier hooks like init; rest_api_init is where WordPress builds it before dispatching the request.

Once for the autosave/revision and once for the real post. Guard with wp_is_post_autosave() and wp_is_post_revision().

The main query hasn't executed yet on init. Use template_redirect, where the query is finalized and conditional tags are reliable.

add_menu_page() must be called on admin_menu, not admin_init or plugins_loaded — those run before the menu system is ready.

register_sidebar() must run on the widgets_init hook — calling it earlier or later means WordPress never registers the widget area.

Large synchronous <script src> tags echoed in wp_footer still delay paint — add the async/defer attribute instead of a raw echoed tag.

It usually means register_post_type() ran on a hook earlier than init, or the CPT registration code never executed on that request.

init fires on every request type. Guard expensive logic with is_admin(), wp_doing_ajax(), or wp_doing_cron() so it only runs where it's actually needed instead of on every hit.

comment_post is specific to the standard front-end submission flow and gives you the approval status directly. wp_insert_comment fires for every insert path (including REST/import) and gives you the full WP_Comment object.