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.

Return an empty string from the filter — WordPress will render the footer area with no text.

Yes — search $classes with array_search() and unset() the key, then return the array.

Only if something still links to it directly. This filter changes what wp_login_url() outputs; it doesn't disable the real wp-login.php endpoint.

No — this fires before wp_insert_attachment() creates the post, so there's no attachment ID available yet.

It helps, but deliverability mainly depends on SPF/DKIM/DMARC records and your mail sending method — this filter alone won't fix a misconfigured domain.

No — it only changes what's rendered on display. The database row is untouched.

No — it only affects images processed after the filter is added; existing attachments aren't retroactively rescaled.

No — only for actual blocks. Classic editor HTML that isn't parsed into blocks goes through the_content filters instead.

No — only for scripts registered via wp_enqueue_script()/wp_register_script(). Manually echoed <script> tags aren't touched.

Yes — it runs regardless of whether the excerpt was typed in the editor or auto-generated from content.

No — only images rendered through WordPress's own attachment image functions (wp_get_attachment_image and friends), not raw <img> HTML.

No — set the DISABLE_WP_CRON constant to true for that. This filter only adjusts the self-spawned HTTP request's arguments.

No — only when metadata is generated or explicitly regenerated (new upload, or a 'Regenerate Thumbnails' action), not on normal display.

Return a WP_Error object. Returning null lets WordPress continue checking other registered authenticate callbacks instead of stopping the login outright.

Check $args->theme_location (or $args->menu) inside the callback and return $items unchanged for every other menu.

manage_posts_columns only adds the header. You also need add_action( 'manage_posts_custom_column', … ) to echo the actual value for each row/column combination.

No — pair it with an SVG sanitizer library or plugin. The raw filter only changes what's accepted, not what's safe.

The wp_title() template tag is legacy — modern themes render titles via wp_get_document_title() and the document_title_parts filter. wp_title only fires if a theme still calls wp_title() directly in header.php.

Yes — it's the standard extension point for custom REST authentication schemes like API keys or signed requests.

body_class targets the <body> tag once per page; post_class targets each individual post wrapper and runs once per post in the loop.

register_rest_field is the documented way to add a field with schema support; rest_prepare_post is a lower-level filter for quick tweaks or removing/reshaping existing fields.

single_template (and its siblings like page_template) only affect one specific query type; template_include is the catch-all that runs regardless of query type.

null means 'no opinion, defer to other checks'; a WP_Error means 'block this request with this specific error'.

The attachment loses its generated sizes and dimension data — always return $metadata, even unmodified.

2560 pixels on the long edge, introduced in WordPress 5.3.

'upload' is a direct user file upload; 'sideload' is a file pulled in programmatically, such as an image imported from a URL.

permission_callback runs per-route after matching, for auth checks on that specific endpoint. rest_pre_dispatch runs before routing even happens and can intercept every request site-wide.

A the_content callback must return the string. Echoing instead of returning wipes the post body.

The post already has a manually written excerpt, or the theme calls a hardcoded wp_trim_words() instead of get_the_excerpt() — this filter only affects the auto-generation path.

The filter runs anywhere get_the_title()/the_title() is called, including some menu-label code paths. Check the post type or scope the condition more tightly.

Usually cron_schedules wasn't hooked before wp_schedule_event() ran, or the interval key name doesn't match exactly — WordPress silently ignores unknown interval names instead of throwing an error.

Those are block delimiters the block editor saves into post_content. Each one already passed through the render_block filter before reaching the_content, so by the time your filter runs it's rendered HTML with block comments still attached — not raw block JSON.

It only applies to auto-generated excerpts. A manually written excerpt is used exactly as typed, with no trailing string appended.

Modern themes render the title via wp_get_document_title(), which uses document_title_parts — wp_title() usually isn't called at all.

High-traffic sites often disable the default request-triggered cron and drive wp-cron.php via a real system cron instead — this filter is mostly relevant when you still rely on WordPress's own self-ping.