DEV Community: Lucas Fenwick

WordPress tells you a comment is "In reply to A WordPress Commenter." That is a name, not an ID

Lucas Fenwick — Tue, 21 Jul 2026 09:29:40 +0000

Display comment ID and parent ID in the WordPress admin by enabling Custom Admin Columns in WP Adminify: go to WP Adminify > Productivity, turn on Custom Admin Columns, tick Show "Comment ID" Column for Comment, Also show "Parent ID", and save, and an ID column and a Parent ID column appear on the Comments screen, where Parent ID 0 means a top-level comment and any other number is the comment ID that comment replies to, because WordPress core never prints either number and instead prints the parent as an author name, "In reply to A WordPress Commenter.", which identifies nothing the moment one person replies twice in the same thread, leaving comment.php?action=editcomment&c=2 in the address bar as the only built-in way to read the real number.

That is the whole answer. The rest of this post is why the name is worse than a blank, what Parent ID 0 actually means, the code route, and a core behaviour around trash that silently breaks threads.

The substitution, not the omission

Every guide on this topic teaches the same thing. Click Edit under a comment, read the number after &c=. WPBeginner does it, and so does every page that followed it.

They all stop at the comment ID. None of them touch the parent, and the reason is that core appears to have already handled the parent. Here is what WP_Comments_List_Table::column_comment() actually emits:

printf(
    __( 'In reply to %s.' ),
    '<a href="' . $parent_link . '">' . $name . '</a>'
);

A display name, linked to the parent comment. Which is genuinely useful for a human reading one row, and useless for anything else, because $name is not unique inside a thread. Take a support post where one person replies four times:

ID 118  In reply to A WordPress Commenter.
ID 121  In reply to A WordPress Commenter.
ID 126  In reply to A WordPress Commenter.

Three rows, one string, three different parents. The admin cannot distinguish them and neither can you.

Meanwhile the row itself is built from a WP_Comment object that already holds comment_parent, and WP_Comments_List_Table prints the comment's own ID straight into the row element:

echo "<tr id='comment-$comment->comment_ID' class='$the_comment_class'>";

and into every row action URL:

Approve  -> comment.php?action=approvecomment&c=2&_wpnonce=...
Spam     -> comment.php?action=spamcomment&c=2&_wpnonce=...
Trash    -> comment.php?action=trashcomment&c=2&_wpnonce=...

So the comment ID is printed all over the markup, exactly like the post ID is on the Posts list. The parent ID is the interesting one, and that one is loaded and thrown away.

This is worth separating from the missing post ID column, because they fail differently. A missing column is an omission, and omissions get noticed eventually. This is a substitution. Something occupies the space where the answer belongs and reads like an answer, which is why a topic this old still has no good page written about it.

Parent ID 0 is a value, not a blank

First thing anyone asks once the column is on.

comment_parent defaults to 0, and 0 is what core writes for a top-level comment. Any other number is the comment_ID of the comment being replied to. That is the entire threading model. There is no separate tree table and no depth field on the row, just a self-referencing integer.

ID   Parent ID
1    0          <- thread opener
2    1          <- reply to 1
3    1          <- another reply to 1
4    3          <- reply to 3, depth 3

Which is exactly what the demo screen shows: ID 1 / Parent 0 for the original comment, ID 2 / Parent 1 for the admin's reply. Two integer columns and you have reconstructed every thread on the page without opening a single comment. Depth is not stored anywhere, it is derived by walking the chain, which is also why Settings > Discussion caps nesting with "Enable threaded (nested) comments N levels deep" rather than storing a level.

Do not carry the post ID explanation over

If you read the post ID version of this topic you learned that posts, pages, custom post types, attachments, revisions and autosaves all draw from one auto_increment in wp_posts, which is why a clean install hands you page IDs 6, 3 and 2.

None of that applies here. Comments live in wp_comments with their own comment_ID auto_increment. Nothing else shares it.

Comment IDs still have gaps, for a completely different reason: deleted spam and purged trash consume numbers and never return them. A site running Akismet for five years can be at comment ID 40,000 with two hundred real comments on the screen. Same symptom, different cause, and the wrong explanation is currently the popular one.

What it actually costs

One comment ID is a five second click into Edit. The pain shows up when the ID is not the thing you needed.

Auditing a thread that has been moderated for months, where "In reply to [same name]" appears on six rows
A parent or parent__in argument in WP_Query's comment counterpart, WP_Comment_Query
wp comment list --fields=comment_ID,comment_parent with WP-CLI to diff before and after a migration
Deciding what a bulk delete is about to take down with it
A support thread where two commenters share a display name, and the ID is the only unambiguous handle anyone has

And comment IDs fail the same silent way post IDs do. A wrong digit does not error. get_comment(1263) returns null or someone else's comment and the template renders happily.

The code route, and its fine print

// functions.php: ID + Parent ID columns on the Comments screen
add_filter( 'manage_edit-comments_columns', 'wpa_comment_id_columns' );
function wpa_comment_id_columns( $columns ) {
    // insert both right after the checkbox column
    return array_slice( $columns, 0, 1, true )
         + [ 'wpa_cid' => 'ID', 'wpa_cpid' => 'Parent ID' ]
         + array_slice( $columns, 1, null, true );
}

add_action( 'manage_comments_custom_column', 'wpa_comment_id_values', 10, 2 );
function wpa_comment_id_values( $column, $comment_id ) {
    if ( 'wpa_cid' === $column ) {
        echo (int) $comment_id;
    }
    if ( 'wpa_cpid' === $column ) {
        $comment = get_comment( $comment_id );
        echo $comment ? (int) $comment->comment_parent : 0;
    }
}

The hook reference is manage_comments_custom_column, and the object you are reading is documented under get_comment(). The fine print:

The value callback receives the comment ID, not the comment object, so the Parent ID column costs a get_comment() per row unless you prime the cache
Sorting is not included, that is a separate sortable-columns filter plus a query tweak
Both columns claim whatever width they like until you add admin CSS
It lives in functions.php, so it dies on theme switch unless you promote it to a must-use plugin

The checkbox route

I did this run with WP Adminify's Productivity module. Enable Custom Admin Columns, tick Show "Comment ID" Column for Comment, Also show "Parent ID", save.

ID and Parent ID appear on the Comments screen, no code, survives theme switches. Note it is one checkbox for both columns, you get the pair or neither
The same panel carries the rest of the list-screen columns people usually snippet in one at a time, Show Post/Page ID Column, Taxonomy ID, a URL Path column with per-post-type selection, and a Last Login column for users, all on the Custom Admin Columns docs page
If you outgrow fixed checkboxes, the standalone Admin Columns Editor builds columns for arbitrary fields
This rundown of necessary admin columns for WordPress is a decent map of which columns earn their width
On the comment side of the same product, hiding the Comments menu from the admin panel and removing the website field from the comment form are the two adjustments most sites make first, and there is a full guide to disabling WordPress comments if the answer is that you do not want them at all
It all sits inside the wider Productivity toolset

The caveats I will not skip. Two ID columns are display, not management. They print two numbers, they do not moderate, re-thread or repair anything, so treat "better comment management" as marketing rather than a feature. They cost two columns of horizontal space on a screen already carrying Author, Comment, In response to and Submitted on, and Screen Options is where you get that back. The docs do not document either column as sortable, so treat sorting by ID as unconfirmed. And it is a single checkbox for the pair, so there is no documented way to show ID without Parent ID.

The core behaviour that quietly breaks threads

This is the part I would put above the column itself.

wp_delete_comment() contains this, commented in core as "Move children up a level":

$children = $wpdb->get_col( $wpdb->prepare(
    "SELECT comment_ID FROM $wpdb->comments WHERE comment_parent = %d",
    $comment->comment_ID
) );
if ( ! empty( $children ) ) {
    $wpdb->update(
        $wpdb->comments,
        array( 'comment_parent' => $comment->comment_parent ),
        array( 'comment_parent' => $comment->comment_ID )
    );
}

Permanently delete a comment and its replies get re-pointed at the deleted comment's own parent. The thread survives, one level shallower. Good behaviour.

Trash does not run that block. Trashing sets the comment status and leaves comment_parent on every child exactly as it was, pointing at a comment that is no longer in the thread.

Those replies stay Approved. They render on the Comments screen looking completely ordinary. The conversation they belonged to is gone from the front end. Nothing errors, nothing is logged, and there is no admin surface that shows it, unless you can read the Parent ID column and notice a number that no longer resolves.

If you want to check a site right now:

SELECT c.comment_ID, c.comment_parent, c.comment_post_ID
FROM wp_comments c
LEFT JOIN wp_comments p ON p.comment_ID = c.comment_parent
WHERE c.comment_parent <> 0
  AND ( p.comment_ID IS NULL OR p.comment_approved <> '1' );

Every row that comes back is a reply whose parent is missing or not approved.

The same logic makes the migration case worse than it is for posts. Comment IDs belong to a database, not a site. Re-import comments and they renumber, and unlike a post ID, a comment ID is referenced by other comments. If the importer does not remap comment_parent alongside comment_ID, threads flatten or, worse, reattach to whatever comment happens to hold the old number now. Run the query above after every migration.

Short demo

Docs: Show Comment ID and Parent ID columns in WP Adminify

So: both columns on permanently, snippet, or still clicking Edit and reading &c=? And has anyone here actually run the orphan query on a site they inherited?

The WordPress post ID is already in every row of your admin list, core just never prints it

Lucas Fenwick — Mon, 20 Jul 2026 07:02:25 +0000

Show post and page IDs in the WordPress admin by enabling Custom Admin Columns in WP Adminify: go to WP Adminify > Productivity, turn on Custom Admin Columns, tick Show Post/Page ID Column, and save, and an ID column appears on the Posts and Pages list screens. WordPress core has never printed the ID in that list even though every row already carries it, because the list table renders each row as <tr id="post-123"> and every Edit link in the row already points at post.php?post=123, so the ID is loaded and printed into the page HTML while the only built-in way to read it is hovering a link and checking the browser status bar one post at a time.

That is the whole answer. The rest of this post is why the hover trick is evidence, why your IDs look random, the code route, and the migration warning nobody puts in these tutorials.

The workaround is the proof

Every guide on this topic teaches the same thing. Hover Edit, read post.php?post=123 off the status bar. Or open the post and read the ID out of the address bar.

Both work. Both also quietly admit that the ID is already rendered. Look at what WP_Posts_List_Table actually emits for one row:

<tr id="post-123"
    class="iedit author-self level-0 post-123 type-page status-publish hentry">
  <td class="title column-title">
    <a href="/wp-admin/post.php?post=123&action=edit">Sample Page</a>
    <div class="row-actions">
      <span class="edit"><a href="/wp-admin/post.php?post=123&action=edit">Edit</a></span>
      <span class="trash"><a href="/wp-admin/post.php?post=123&action=trash">Trash</a></span>
      <span class="view"><a href="/?page_id=123">View</a></span>
    </div>
  </td>
  ...
</tr>

The ID is the row's HTML id. It repeats in the row classes, courtesy of get_post_class(). It appears in four URLs. On a 20-row screen that is roughly a hundred printed copies of numbers you cannot read.

This is worth separating from the other famous admin blind spot. A missing featured image column is a genuine absence, the featured image is postmeta and the list table does not render postmeta. The post ID is the opposite, it is the primary key of the row the list table is already looping over. It is present and unprinted, because core treats the ID as a database internal rather than something a publisher needs.

Why your IDs look random

The most common follow-up question on this topic: why is my third page ID 6?

Because wp_posts has one auto_increment primary key, and everything lives in that table. Posts, pages, custom post types, attachments, revisions, autosaves, menu items, all of it draws from the same counter.

ID 1  -> "Hello world!" post
ID 2  -> "Sample Page"
ID 3  -> "Privacy Policy" (auto-draft)
ID 4  -> autosave / revision
ID 5  -> an uploaded image (attachment)
ID 6  -> "Home"

Which is exactly what the demo shows: Home 6, Privacy Policy 3, Sample Page 2. There is no per-post-type sequence, gaps are normal, and IDs are never guessable. Anybody who has tried to work out an ID by counting rows has learned this the slow way.

What it actually costs

One ID is a five second hover. The pain is bulk.

An Elementor or query loop excluding twelve specific pages
A gallery or posts shortcode taking a comma-separated ID list
A post__in / post__not_in argument in WP_Query
A wp post get 123 run against a client site with WP-CLI
Two pages both titled "Home", where the ID is the only unambiguous handle

Twelve IDs means twelve hovers and twelve hand transcriptions. And IDs are unforgiving in a specific way: a wrong digit does not error. post__not_in => [124] excludes some other post entirely and the loop renders happily. You find it when a client asks why the wrong page is showing.

The code route, and its fine print

// functions.php: ID column on posts and pages
add_filter('manage_posts_columns', 'wpa_id_column');
add_filter('manage_pages_columns', 'wpa_id_column');
function wpa_id_column($columns) {
    // insert ID right after the checkbox column
    return array_slice($columns, 0, 1, true)
         + ['wpa_id' => 'ID']
         + array_slice($columns, 1, null, true);
}

add_action('manage_posts_custom_column', 'wpa_id_value', 10, 2);
add_action('manage_pages_custom_column', 'wpa_id_value', 10, 2);
function wpa_id_value($column, $post_id) {
    if ($column === 'wpa_id') {
        echo (int) $post_id;
    }
}

The hook reference is manage_{$post_type}_posts_columns. The fine print:

Posts and pages take separate filter pairs, and every custom post type wants its own if you need per-type control
Sorting is not included, that is a third hook (manage_edit-post_sortable_columns) plus a pre_get_posts tweak
The column claims whatever width it likes until you add admin CSS
It lives in functions.php, so it dies on theme switch unless you promote it to a must-use plugin

The checkbox route

I did this run with WP Adminify's Productivity module. Enable Custom Admin Columns, tick Show Post/Page ID Column, save.

An ID column appears on the Posts and Pages lists, no code, survives theme switches
The same panel carries the rest of the list-screen columns people usually snippet in one at a time, Comment ID with parent ID, Taxonomy ID, a URL Path column with per-post-type selection, and a Last Login column for users, all on the Custom Admin Columns docs page
If you outgrow fixed checkboxes, the standalone Admin Columns Editor builds columns for arbitrary fields, and how to add an ACF field to an admin column is the worked example for meta fields
This rundown of necessary admin columns for WordPress is a decent map of which columns earn their width, and column customization for any post type covers the CPT side
It sits inside the wider Productivity toolset

The caveats I will not skip. An ID column is display, not magic, it does not validate anything and it does not make an ID portable. It costs horizontal space on a screen that is already tight, Screen Options is where you claw that back. The docs describe this checkbox as being for "post and page table lists", so I am not claiming custom post type coverage until someone verifies it on a real CPT. And the column is not documented as sortable, so treat sorting by ID as unconfirmed.

The warning that matters more than the column

A post ID is unique to one database, not to your site.

Export the content and re-import it, rebuild staging from a fresh install, migrate hosts with a content-level tool, and the same page comes back with a different ID. Every template, shortcode, exclude list and option row referencing the old number keeps running. Nothing throws. The wrong content renders.

So read IDs, use them, and prefer slugs wherever the API accepts one. Where you do hardcode, put the ID in a config constant or an option rather than scattered through templates, so the fix after a migration is one line and not a grep.

Short demo

Docs: Show Post/Page ID Column in WP Adminify

So: ID column always on, snippet it per post type, or still hovering the Edit link? And be honest, how many hardcoded IDs are in your production templates right now?

The WordPress admin never shows featured images, and the reason is a design decision worth knowing

Lucas Fenwick — Sun, 19 Jul 2026 05:17:37 +0000

Show featured images in the WordPress admin post list by enabling Custom Admin Columns in WP Adminify: go to WP Adminify > Productivity, turn on Custom Admin Columns, tick Show Post Thumbnails Column, and a Thumbnail column appears in your Posts list, with an optional default Column Thumbnail Image for posts that have no featured image set. WordPress core has never shown featured images in the Posts list because the featured image is a _thumbnail_id record in postmeta, and the admin list table renders posts-table fields and taxonomy links but never postmeta, so the only built-in way to check featured images is opening posts one by one.

That is the whole answer. The rest of this post is the why, the code route, and the audit trick, because the why is the part every tutorial skips.

The featured image was never in the post

Set a featured image and WordPress stores exactly one thing, a postmeta record:

_thumbnail_id = 42    // one meta row, pointing at an attachment ID

The post itself does not change. The image is a reference living in a side table, read on the frontend by get_the_post_thumbnail() and written by set_post_thumbnail().

Now look at what the admin Posts list renders: title, author, date from the posts table, categories and tags from taxonomy relationships. Postmeta is not on that list. The list table has no column for any meta field, and featured image is a meta field. So the frontend shows the image on every theme card, every share preview reads it for og:image, and the admin, the one screen where you manage the posts, shows nothing.

Why the gap actually costs something

A post with no featured image is not a cosmetic problem:

It shares blank or with a random fallback image on Facebook, X and LinkedIn
Most themes render it as an empty card in archives and related-post blocks
Google Discover favors large images, at least 1200px wide, so the post is effectively out of the Discover pool

And here is the trap: those posts are invisible in exactly the screen where you would catch them. No column, no signal, no audit. The broken posts surface one embarrassing blank share at a time.

The code route: five lines, plus fine print

Adding the column yourself is a filter and an action:

// functions.php: thumbnail column for posts
add_filter('manage_posts_columns', function ($columns) {
    return ['thumb' => 'Thumbnail'] + $columns;
});

add_action('manage_posts_custom_column', function ($column, $post_id) {
    if ($column === 'thumb') {
        echo get_the_post_thumbnail($post_id, [60, 60]);
    }
}, 10, 2);

The hook reference is manage_{$post_type}_posts_columns. The fine print is where the snippet stops being five lines:

Pages need manage_pages_columns and manage_pages_custom_column, separately
Every custom post type needs its own manage_{$post_type}_posts_columns filter if you want per-type control
A post with no featured image renders an empty cell, no fallback, so the audit signal is a blank you can miss
Column width needs a dab of admin CSS or the thumbnail column grabs whatever space it likes
It lives in functions.php, which means it dies on theme switch unless you move it to a must-use plugin

The checkbox route

I did this run with WP Adminify's Productivity module. What changed after enabling Custom Admin Columns and ticking Show Post Thumbnails Column:

A thumbnail column appeared on the Posts and Pages lists, no code, survives theme switches
The same settings screen offers a Column Thumbnail Image, a default image shown for any post with no featured image, and that default is the audit trick: every row showing it is a post that will share blank, so the gaps mark themselves on one scroll
It ships beside the other list-screen columns in the same panel, post and page ID columns, a last-login column for users, taxonomy IDs, the small stuff you otherwise snippet in one at a time, all documented on the Custom Admin Columns docs page
If you outgrow the checkbox, the standalone Admin Columns Editor builds columns for arbitrary fields, and this list of necessary admin columns for WordPress is a decent map of which ones earn their width
It sits in the wider Productivity toolset, and pairs naturally with the replace-image-without-changing-URL workflow once the column has shown you which images need swapping

The caveat I will not skip: the column adds one thumbnail request per row. WordPress serves the small registered thumbnail size so it is minor, but a 200-row list on slow hosting will feel it. And the default image marks a missing featured image, it does not set one, the post still shares blank until you fix it. The column finds the work. It does not do the work.

Short demo
Docs: Show Post Thumbnails Column in WP Adminify

So: do you run a thumbnail column, snippet it per post type, or audit featured images the hard way, one edit screen at a time?

Copy-pasting a WordPress post only copies a third of it. Here is what the other two thirds are

Lucas Fenwick — Sat, 18 Jul 2026 05:22:59 +0000

Here is a small thing that catches almost everyone the first time, and it is not really their fault, because the advice that ranks sets them up for it.

You want a copy of a post or page. Maybe a template for the next one, maybe an A/B variant of a landing page, maybe a backup before a big edit. WordPress has no duplicate button, so the standard advice is: open the editor, select all blocks, copy, paste into a new page.

You do that, and the copy arrives hollow. No featured image. No categories or tags. No SEO title or description. And if the page was built with Elementor, no page. The paste is blank.

Every tutorial that recommends copy-paste admits this in a footnote, "you will need to re-add the featured image and SEO settings manually." None of them explain why. Let me explain why, because once you see it you will never be confused by it again.

What a WordPress post actually is

A post is three kinds of database records working together.

The posts-table row. Title, content, excerpt, status, type. This is the only part the editor shows you and the only part a paste moves.
Postmeta rows. One row per setting, keyed to the post ID. See get_post_meta() for how WordPress reads them.
Taxonomy relationships. Categories, tags and custom taxonomies are term records linked to the post. They are not stored in the post at all.

Where the "lost" data lives

Everything the paste dropped is record type 2 or 3:

_thumbnail_id       = 42          // the featured image is postmeta
_yoast_wpseo_title  = "..."       // SEO title: postmeta
_yoast_wpseo_metadesc = "..."     // meta description: postmeta
_elementor_data     = "[{...}]"   // the ENTIRE Elementor layout, JSON in postmeta

The _elementor_data one is the fact worth keeping. On an Elementor page, post_content is nearly empty, a fallback render at best. The real design is serialized JSON in postmeta. So when you copy "the content" of an Elementor page, you are copying the one field that does not contain the page. That is why the paste lands blank.

Categories are the same story from the other side. They are relationships between the post and term records, so a brand-new pasted post has no relationships until you rebuild them by hand.

This is the core of it: duplicating a post is not copying text, it is copying a row, a stack of meta, and a set of term links. Copy-paste does the first part only.

Doing it correctly in code

If you script it, the shape is three passes, one per record type:

$src = get_post($post_id);

// Pass 1: the row
$new_id = wp_insert_post([
    'post_title'   => $src->post_title . ' (Copy)',
    'post_content' => $src->post_content,
    'post_type'    => $src->post_type,
    'post_status'  => 'draft',   // draft on purpose, see below
]);

// Pass 2: every meta, the part paste never does
foreach (get_post_meta($post_id) as $key => $values) {
    foreach ($values as $value) {
        add_post_meta($new_id, $key, maybe_unserialize($value));
    }
}

// Pass 3: the term links
foreach (get_object_taxonomies($src->post_type) as $tax) {
    $terms = wp_get_object_terms($post_id, $tax, ['fields' => 'ids']);
    wp_set_object_terms($new_id, $terms, $tax);
}

See wp_insert_post() for the first pass. And a warning on pass 2: serialized builder meta like _elementor_data is where hand-rolled duplicators break, the JSON needs correct unserializing and slashing or the clone's layout corrupts. It is the fiddliest part of the whole job, which is exactly why a maintained one-click tool beats a snippet here.

Gotcha one: the clone is an SEO twin until you edit it

A correct clone copies the SEO meta too, slug base, title, description. Which means until you change those, you have two pages targeting one query. Publish both and you have built keyword cannibalization by hand. This is why the clone should be created as a draft and stay one while you rewrite the slug, title and meta.

Gotcha two: WooCommerce already has this, for one post type

WooCommerce ships a Duplicate action for products, because stores clone configured products constantly. But it is products only. Posts, pages and custom post types are on their own.

The settings-panel version

I did this run with WP Adminify's Productivity module, which covers every post type from one place. 30 second demo below.

What changed after enabling Post Duplicator in Adminify > Productivity:

An Adminify Clone action appeared in the row actions of Posts, Pages and custom post types, next to Edit and Quick Edit, no code to add it
One click produced a (Copy) with the content, featured image, categories and settings intact, which is the exact part copy-paste drops
It works on custom post types too, which is where the free single-purpose plugins tend to get fussy
It sits alongside the rest of the same module, including the one-click menu duplication feature, same idea applied to navigation menus, and the wider Productivity toolset
Pair it with the Admin Columns Editor if you clone a lot, a custom column showing modified dates keeps originals and copies easy to tell apart, and Activity Logs records who cloned what on multi-author sites

The caveat I will not skip: a clone is a snapshot, not a live mirror, and it inherits everything, including stale meta you forgot was on the original. Clone posts you trust, keep the copy draft, fix the slug and meta, then publish.

Short demo

Feature page: Duplicate any WordPress post type with WP Adminify

So: do you duplicate with a tool, script the three-pass copy yourself, or copy-paste and rebuild the settings every time?

WordPress has no button to duplicate a menu, and rebuilding one by hand quietly breaks your dropdowns. Here is why

Lucas Fenwick — Thu, 16 Jul 2026 05:54:21 +0000

Here is a small thing that catches almost everyone the first time, and it is not really their fault, because the tooling sets them up for it.

You want a copy of a navigation menu. Maybe for a redesign, maybe a seasonal variant, maybe a backup before you start deleting items. So you open Appearance > Menus and look for a Duplicate button.

There isn't one. WordPress core has never had a way to copy a menu.

So you do the obvious thing and rebuild it by hand in a new menu, dragging items in one at a time. It works, until you look at the dropdowns and every nested item is now sitting at the top level. No error. Just a flat menu where your hierarchy used to be. Let me explain why, because once you see it you will never be confused by it again.

What a WordPress menu actually is

A menu is not a block of text. It is two kinds of database records working together.

The menu itself is a taxonomy term, in the nav_menu taxonomy.
Every item inside the menu is a separate hidden post, of type nav_menu_item, each with its own post ID.

The label, the URL, the link target, all of it lives in that item's postmeta. See wp_get_nav_menu_items() for how WordPress reads them back out.

Where the nesting lives, and why it breaks

The part that makes a menu a menu, the nesting, is stored as postmeta on each item:

_menu_item_menu_item_parent = 128  // "my parent is menu item #128"

That is the trap. The parent is saved as a menu item ID, not a name or a slug. So the whole hierarchy is a web of items pointing at each other by ID.

Now rebuild that menu by hand. Every item you recreate is a brand new post with a brand new ID. The old parent values still say things like 128, but item 128 no longer exists in the new menu. WordPress cannot resolve the reference, so it treats the child as a top-level item. Do that across a nested menu and the entire thing flattens.

This is the core of it: duplicating a menu is not copying text, it is recreating a set of posts AND remapping the parent pointers between them. Copy-paste does not do the second part. Naive export/import does not do the second part. That is why they lose your dropdowns.

Doing it correctly in code

If you were to script it, the shape is: create the new menu, then create each item with wp_update_nav_menu_item(), keep a map of old item ID to new item ID as you go, and set each new item's menu-item-parent-id to the mapped new ID rather than the old one.

// Pseudocode for the part that matters
$id_map = [];
foreach ($original_items as $item) {
    $new_id = wp_update_nav_menu_item($new_menu_id, 0, [
        'menu-item-title'  => $item->title,
        'menu-item-url'    => $item->url,
        'menu-item-status' => 'publish',
        // do NOT set the old parent here yet
    ]);
    $id_map[$item->ID] = $new_id;
}
// Second pass: now that every item exists, fix the parents
foreach ($original_items as $item) {
    if ($item->menu_item_parent) {
        update_post_meta(
            $id_map[$item->ID],
            '_menu_item_menu_item_parent',
            $id_map[$item->menu_item_parent] // remapped, not the old ID
        );
    }
}

Two passes, because you cannot set a parent to an ID that does not exist yet. This remap is exactly the work a one-click duplicator does for you.

Gotcha one: the copy is not assigned to a location

Even done correctly, a duplicated menu displays nowhere. It is not attached to any theme location. You assign it under Appearance > Menus > Manage Locations when you are ready.

That is not a missing step, it is the point. When you clone a menu to redesign it, you want the copy invisible to visitors until it is finished. Duplicate, rework the copy, swap the location at the end, and the live nav never breaks while you work.

Gotcha two: the copy is a snapshot, not a mirror

Once you duplicate, the two menus are independent sets of nav_menu_item posts. Editing the original later does not change the copy. Perfect for a backup taken before a risky edit. Not what you want if you assumed the two would stay in sync.

The settings-panel version

I did this run with WP Adminify's Productivity module, which adds the one-click duplicate right where you already are. 30 second demo below.

What one click gets you, and what it does not:

A full copy of the menu: every item, the exact order, and the nested dropdowns, with the parent IDs remapped so the hierarchy survives
The copy left unassigned, so it shows nowhere until you assign a location (the safe-redesign default)
What it does NOT do: keep the copy in sync with the original. It is a snapshot. Two separate menus from the moment you click
What to watch: orphaned items pointing at deleted pages get copied too, so tidy the menu around the clone

What changed after enabling Menu Duplicator in Adminify > Productivity:

A Duplicate Menu button appeared on the Appearance > Menus screen, next to the menu name, no code to add it
One click produced a (Copy) of a three-level menu with the nesting intact, which is the part hand rebuilds ruin
It sits alongside the rest of the same module, the dashboard widget cleanup and the admin notice hiding, so the admin you are working in is also the admin you cleaned
Pair it with the admin menu layout options if what you actually wanted was to reorder the WordPress admin sidebar, which is a different feature people confuse with navigation menus

The caveat I will not skip: duplication is a copy, not a link. The moment you click, you have two menus that drift apart independently. That is ideal for backups and variants, and wrong if you expected a live mirror. Match the tool to the intent.

Short demo

Step-by-step doc: One-click menu duplication in WordPress

More admin control in the same direction: remove unwanted dashboard widgets, hide admin notices, change the admin menu layout and width, and hide Screen Options and the Help tab.

So: do you duplicate menus with a tool, rebuild and re-nest them by hand, or spin up staging for every nav change?

You dragged your WordPress posts into order and the front end ignored you. Here is the step every tutorial skips

Lucas Fenwick — Wed, 15 Jul 2026 07:19:48 +0000

ere is a thing that trips up almost everyone the first time, and it is not really their fault, because the tutorials set them up for it.

You install a reorder plugin, or you enable drag-and-drop ordering. You go to the Posts screen, grab a row by its handle, drop it into a new position. The list reorders. It saves instantly, no Save button. The admin table looks exactly the way you wanted.

Then you open the live site and the posts are in the same order they always were.

No error. No warning. Just a quiet, complete lack of change. Let me explain why, because once you see it you will never be confused by it again.

What a drag-drop reorder actually does

When you drop that row, WordPress does exactly one thing. It writes a number to the menu_order column of that post's row in wp_posts.

UPDATE wp_posts SET menu_order = 3 WHERE ID = 421;

That is the entire operation. It is real, it is saved, and it is durable. But it is just a number sitting in a column.

Why the front end does not care

Your blog page, your archives, your category pages all run the WordPress main query, and the main query has a default sort:

// WP_Query defaults
'orderby' => 'date',
'order'   => 'DESC',

menu_order is not date. So the front end keeps serving posts newest-first and never looks at the column you just updated. This is the core of it: reordering in the admin and reordering on the site are two different jobs. The drag handle does the first. Nothing you dragged does the second.

Doing the second job

To make your hand-built order show on the front end, some query has to sort on menu_order. On a stock theme, that is one hook on the main query:

add_action('pre_get_posts', function ($q) {
    if (is_admin() || ! $q->is_main_query()) {
        return;
    }
    if ($q->is_home() || $q->is_post_type_archive() || $q->is_category()) {
        $q->set('orderby', 'menu_order');
        $q->set('order', 'ASC');
    }
});

Reference: pre_get_posts and WP_Query orderby parameters.

Gotcha one: posts do not even have an order field

Before you can drag anything, note that posts have no order field by default. Only pages ship with the Order attribute. The Posts list has no menu_order UI until something adds it:

add_post_type_support('post', 'page-attributes');

Reference: add_post_type_support(). This is why so many how-to posts open with a functions.php snippet before you can see a single drag handle. A reorder plugin adds this support for you, which is half of why people reach for one.

Gotcha two: the fix that works on a stock theme fails silently on a builder

pre_get_posts only reaches queries that respect filters. Two very common cases do not:

A theme or plugin that runs new WP_Query([... 'suppress_filters' => true]). That flag tells WordPress to skip the filter chain, so your hook never runs on that query.
A Gutenberg Query Loop block, which has its own Order and Order By controls in the block sidebar. It sorts by whatever the block says, not by your hook.

So the exact same code works perfectly on Twenty Twenty-Four and does absolutely nothing on a page builder page, and there is no error to point you at the cause. When you are on a builder, set the order in the block's own controls, or on the specific WP_Query you control.

The settings-panel version

I did this run with WP Adminify's Productivity module, which handles the drag-drop half across more than just posts. 30 second demo below.

What manual reorder gets you, and what it does not:

Drag-and-drop across Posts, Pages, custom post types, the Media library and taxonomy terms, saved on drop
The order field support added for you, so the handle is just there
What it does NOT do on its own: change the front end. That is still a query concern, orderby menu_order, and you own that part
On a builder, the Query Loop or the builder's own sort wins, so wire it there

What changed after enabling Post Types Order in Adminify → Productivity:

Posts, media and taxonomies all became sortable from the normal list screens, no snippet to add the handle
Nothing to re-paste after a migration, and it survives core updates
It sits alongside the rest of the same module, the dashboard widget cleanup and the admin notice hiding, so the admin you are ordering is also the admin you cleaned
Pair it with the admin menu layout options if what you actually wanted was to reorder the admin menu, which is a different feature people confuse with this one

The caveat I will not skip: manual order is a maintenance promise. Every new post arrives at menu_order 0 and lands at the top or the bottom, so someone has to place it. This is a great fit for small, stable sets, a portfolio, a services list, featured items, a staff page. It is a bad fit for a daily blog with hundreds of posts, where the order is stale before you finish arranging it. Match the tool to the set.

Short demo: [embed Post Type Sortable.mp4]

Step-by-step doc: Reorder posts by type in WordPress

More admin control in the same direction: remove unwanted dashboard widgets, hide admin notices, collapse and resize the admin menu, and hide Screen Options and the Help tab.

So: do you wire the front end query yourself after dragging, or do you reach for a plugin that does both halves, or do you keep posts on date order and control the display some other way?

adminify

Screen Options is the undo button on your client's dashboard, and the CSS fix everyone posts does not remove it

Lucas Fenwick — Tue, 14 Jul 2026 06:09:28 +0000

You clean up a client's WordPress admin. Remove the WordPress Events widget, the Activity feed, the three plugin promo boxes that appeared after the last update. Hide four columns off the Posts list so the table is legible. Collapse the custom fields panel so nobody nukes a meta value by accident.

Then you leave a button in the top right of the screen called Screen Options, and every single thing you just hid is sitting inside it behind a checkbox.

That is the part I want to argue about, because every article on this keyword frames Screen Options as clutter. It is not clutter. It is a permission. It is the undo button for the work you just did, handed to the person you did it for.

And directly beside it is the Help tab, which serves a non-technical client a panel of WordPress.org documentation and a link to the support forums. They ask strangers about a site those strangers cannot see, they come back with instructions that do not fit your build, and you spend a call unpicking it.

So, how do you actually remove them. There are two code paths here, and almost every guide covers one and calls it done.

Path one: Screen Options is a filter

add_filter('screen_options_show_screen', '__return_false');

That stops the panel being rendered at all. But do not ship it like that, because it takes Screen Options away from you too, and that is where the per-page pagination counts, the column toggles on every list table and the custom fields toggle in the classic editor live. Role gate it:

add_filter('screen_options_show_screen', function ($show) {
    return current_user_can('manage_options') ? $show : false;
});

Reference: screen_options_show_screen.

Path two: the Help tab is not a filter, it is a method on the screen object

add_action('admin_head', function () {
    $screen = get_current_screen();
    if ($screen) {
        $screen->remove_help_tabs();
    }
});

And here is the trap that takes sites down. A lot of published snippets hook this on admin_init. The global $current_screen is set right after admin_init has run, so at that point get_current_screen() returns null and you get:

Fatal error: Uncaught Error: Call to a member function remove_help_tabs() on null

The core docs say it outright: use it on the current_screen hook or later. admin_head is fine. admin_init is a white screen. See get_current_screen() and WP_Screen::remove_help_tabs().

Also, while we are here: stop reaching for the old contextual_help filter for this. The screen object methods replaced it years ago.

The answer that actually ranks, and why it is cosmetic

Search "remove screen options wordpress" and you will be handed this, over and over:

#screen-options-link-wrap,
#contextual-help-link-wrap { display: none; }

It hides the button. Open view-source on that same admin page and the whole #screen-options-wrap form is still there. Rendered. Present in the DOM. Still wired to the AJAX handler that writes those preferences to user meta. You have hidden a button that is attached to a working form.

Devtools, one property. A browser extension that strips styles. A stylesheet that 404s after a migration. Any of those, and the client has your cleanup back, plus the mild thrill of having found something you tried to hide from them. It is security theatre for the dashboard, and it is the top answer.

The thing nobody is saying: the block editor has no Screen Options tab

This is the one that changes what you do on Monday.

Gutenberg does not have Screen Options. It never did. The equivalent panel is the three dot menu in the top right → Preferences → Panels, and it is React. It does not read screen_options_show_screen. Your filter does not touch it.

Which means the normal workflow, paste the snippet, watch the tab vanish from the dashboard, close the ticket, has done exactly nothing to the screen the client spends their entire working day on. If your goal was "the client cannot re-enable the panels I hid", you are not finished, and worse, you believe you are. Handle the editor separately, or accept the gap and say so out loud.

The settings-panel version

I did this run with WP Adminify's Productivity module, which has both toggles in one place. 30 second demo below.

What Screen Options and Help actually cost you on a client site:

Every widget, column and meta box you hid is one checkbox away from returning, and the person holding the checkbox is the client
The Help tab routes a non-technical user to WordPress.org support instead of to you, and they come back with advice for a site nobody looked at
The most shared "fix" is a CSS rule that hides the button and leaves the form live in the page source
The second most shared "fix" hooks remove_help_tabs() on admin_init and fatals
And whatever you do to the classic screens, Gutenberg still has Preferences → Panels

What changed after ticking Hide Screen Options and Hide Help Tab in Adminify → Productivity:

Both tabs gone across the admin, from one screen, no snippet to remember
Nothing to re-paste after a migration, and it survives core updates
It pairs with the same module's admin notice hiding and dashboard widget removal, which is the actual cleanup that Screen Options was busy undoing
The cleanup finally stays cleaned, which is the entire point

The caveat I will not skip: keep Screen Options for administrators. You need the column toggles, the pagination counts, and the custom fields panel. This is a role decision, not a global one, and if you take it from every user including yourself you will be editing that snippet over SSH inside a month. Ask me how I know.

Short demo

Step-by-step doc: Hide Screen Options and Help Tab

More admin cleanup in the same direction: remove unwanted dashboard widgets, hide admin notices, collapse and resize the admin menu, and white label the editor logo.

So: do you remove Screen Options by role, hide it with CSS and hope, or leave it and quietly redo the cleanup every few months when the client finds the button?

adminify #WordPress

Removing the WordPress Site Health widget does not disable Site Health, and the four code paths nobody covers

Lucas Fenwick — Mon, 13 Jul 2026 06:04:51 +0000

Load the WordPress dashboard on any client site. The Site Health Status widget sits there with a green circle and the word "Good", then hedges immediately: your site's health is looking good, but there are still some things you can do. Underneath, three flagged rows. You should remove inactive plugins. You should remove inactive themes. Your site is set to display errors to site visitors.

Every article about this treats it as clutter to be swept away. I want to make a different argument: it is a performance problem, and the standard fix for it does not fix it.

Start with what the widget actually does. It is not rendering a cached score from an option. Loading the dashboard kicks off a set of async tests over the REST API, and among them is the loopback test, which asks WordPress to make an HTTP request to its own URL and wait for the response. Think about that on a shared host with a small pool of PHP workers. The request that is meant to test your site is queued behind, and competing with, the request that is trying to render the page you are staring at.

Then there is the bit almost nobody knows about. Core registers a weekly cron event, wp_site_health_scheduled_check, which runs the whole suite again in the background. It is on every site you have ever built. You have never seen it in a profiler because you have never looked.

Now the answers you get when you search for this.

Answer one, and it is the top result nearly everywhere: Dashboard → Screen Options → untick "Site Health Status".

That is a per-user preference. It is written to user meta. It hides the widget for the exact one person who clicked it, which is the author of the tutorial. Your client logs in and sees the whole panel, unchanged. As an answer to the question people are actually asking, which is almost always "how do I get this off my client's screen", it is wrong, and it has been the top answer for years.

Answer two, the snippet:

add_action('wp_dashboard_setup', function () {
    remove_meta_box('dashboard_site_health', 'dashboard', 'normal');
});

This one is real. The widget is gone, for every user. And it has stopped nothing. The cron is still scheduled. The tests still exist. You have hidden the readout, not the work. If you came here because the dashboard was slow, it is still slow, and you now think you fixed it, which is worse than knowing you didn't.

The Tools page is a third path. It never came from the widget, so it survives both of the above:

add_action('admin_menu', function () {
    remove_submenu_page('tools.php', 'site-health.php');
}, 99);

Worth being precise: that removes the menu item, not the page. Anyone who types /wp-admin/site-health.php still gets it. If you actually need it locked, gate on capability rather than hiding the link.

And the fourth path is the only one that stops the checks happening at all, the test registry itself plus the weekly event:

add_filter('site_status_tests', function ($tests) {
    $tests['direct'] = [];
    $tests['async']  = [];
    return $tests;
});

add_action('init', function () {
    $timestamp = wp_next_scheduled('wp_site_health_scheduled_check');
    if ($timestamp) {
        wp_unschedule_event($timestamp, 'wp_site_health_scheduled_check');
    }
});

Four hooks, four code paths, one feature. Every guide I read covers one. A couple cover two. None cover four, and the difference between the widget being hidden and the checks being off is the entire question.

What I will not do, and what people keep suggesting in the forum threads:

define('DISABLE_WP_CRON', true);            // to stop the weekly health check
// or: unhooking the REST API                // to stop the async tests

Killing WP-Cron to silence one weekly event takes scheduled posts, backups and update checks with it. Killing the REST API to stop the async tests takes the block editor with it. Both are amputations to treat a rash. If you find either in a client site, ask why.

I tested the settings-panel version with WP Adminify Pro. 25 second demo below.

What Site Health actually costs on a client site:

Async REST tests on every dashboard load, one of which makes the server call itself and wait
A weekly cron running the whole suite in the background, unnoticed and unattributed
A red-flagged security warning about display_errors shown to a person with no ability to act on it
The most common "fix" for it, Screen Options, is per-user and does nothing for the person who was actually meant to stop seeing it

What changed after ticking Site Health in Adminify Pro's Hide Admin Notices:

One option under Productivity → Hide Admin Notices → Other Notices covers the widget for every admin at once
The Tools → Site Health page goes with it, no separate remove_submenu_page to remember
The checks stop, which is the part remove_meta_box never did
The same module handles the update notice pile-up, so the dashboard opens to work rather than a stack of banners
Nothing to re-paste after a migration, and it survives core updates

The caveat I will not skip: disabling Site Health does not make your site healthy. It is the only thing on a stock install that will tell you your PHP is unsupported, your HTTPS is misconfigured, a required module is missing, or background updates have quietly stopped. Turning it off means nobody will ever hear those things again. That is right when you are monitoring them elsewhere, from a maintenance report, an uptime monitor, a staging pipeline, and it is wrong on a site nobody maintains, where that panel is the only warning system that exists.

And the option that should be the top answer and isn't: WordPress ships a capability, view_site_health_checks. Filter it away from every role except yours and Site Health stays fully alive for you while the client never sees it. When someone asks how to remove Site Health, that is very often the thing they actually wanted, and it is not on page one for any of these queries.

Short demo

Step-by-step doc: https://wpadminify.com/docs/adminify/productivity/hide-admin-notices

How do you handle Site Health on sites you maintain for other people: filter site_status_tests, gate it behind view_site_health_checks, disable it with a plugin, or leave it and field the phone calls?

adminify

Hiding the WordPress theme update notice takes three hooks, and the snippet every guide gives you does something else entirely

Lucas Fenwick — Sun, 12 Jul 2026 05:13:06 +0000

Open Appearance → Themes on a site that is a few weeks behind. There is a count badge on the Themes menu item and a box on the theme card: "New version available. Update now."

It reads like the mildest notice in WordPress. It is the one I most want off a client's screen, because of what the button does when the parent theme was customised directly. No child theme, edits made straight into the theme, which describes a very large number of the sites any of us inherit. Clicking update now replaces those files with the vendor's. Custom header, template edits, functions.php, replaced with defaults. The notice does not warn about that, and the client reading it has no way to know.

Most guides on this keyword hand you one line and stop. The line usually looks like this:

add_filter('site_transient_update_themes', '__return_null'); // please don't

That does not hide the notice. It empties the transient WordPress stores theme update results in, so core stops knowing that any theme has an update. The notice disappears as a side effect, because there is nothing left to render. You have not cleaned a dashboard, you have blinded the site, and the next developer to inherit it finds a quiet admin sitting on top of a year of unapplied releases. If you find that filter in a client site, take it out.

Here is what actually prints the notice. On the themes grid (themes.php) the theme cards are rendered from JS, and the update data comes from wp_prepare_themes_for_js(), which sets hasUpdate and update per theme. So you filter that:

add_filter('wp_prepare_themes_for_js', function ($themes) {
    foreach ($themes as $slug => $theme) {
        $themes[$slug]['hasUpdate'] = false;
        $themes[$slug]['update']    = false;
    }
    return $themes;
});

The notice is gone from the grid. The update check still runs, which is the point. Now load the screen and the count badge is still on the Themes menu item.

That badge never came from the notice. It is built by wp_get_update_data(), which counts pending core, plugin, theme and translation updates and feeds both the admin menu bubble and the toolbar. Second hook:

add_filter('wp_get_update_data', function ($data) {
    $data['counts']['themes'] = 0;
    $data['counts']['total']  = 0;
    $data['title'] = '';
    return $data;
});

And if you run multisite, the network Themes screen is a list table, not a grid, with its own update rows printed by wp_theme_update_rows() on admin_init at priority 20. Third hook, unhooked from an earlier priority on the same hook:

add_action('admin_init', function () {
    remove_action('admin_init', 'wp_theme_update_rows', 20);
}, 1);

Three code paths for one notice, and the published guides cover at most one of them. Then you want the same treatment for plugin update notices, and core, and each has its own removal. By the time you have covered them all you have a mu-plugin, and the mu-plugin has to travel to every site you build. Miss a hook on one and that client gets a half cleaned dashboard.

I tested the settings-panel version with WP Adminify Pro instead. 20 second demo below.

What the theme update notice actually costs on a client site:

A count badge plus an update box on a screen the client visits to change nothing
The button behind it is destructive on any directly-customised parent theme, and it does not say so
The notice is aimed at whoever does the updates, which on agency builds is not the person reading it
It cannot be dismissed, so it never clears until someone updates, and the someone who clicks is usually the wrong someone

What changed after enabling Hide Admin Notices in Adminify Pro:

One toggle under Productivity covers the theme update notice for every admin at once
The Themes count badge clears with it, no separate wp_get_update_data filter to remember
The same module handles the plugin and core notice pile-up, so the admin opens to work rather than a stack of banners
The update check keeps running, so a maintenance report still sees every pending theme update
Survives WordPress updates, no snippet to carry between sites

The caveat I will not skip: hiding the notice does not update the theme. Your version is unchanged and any security release you are behind on is still unapplied. This is right when the update has an owner and a schedule (you, your agency, a managed host, an automation with rollback) and when a child theme exists so the update is survivable when it does get run. It is wrong on a site nobody maintains, where that box is the only signal anyone will ever get. Decide who owns updates first. Then hide the notice. And whatever you decide, do not null the transient.

Short demo

Step-by-step doc: https://wpadminify.com/docs/adminify/productivity/hide-admin-notices

How do you handle theme update notices on sites you maintain for other people: filter wp_prepare_themes_for_js, hide them with a plugin, or leave them visible and accept the risk?

adminify #WordPress #productivity

Hiding WordPress plugin update notices takes two hooks, and the snippet everyone pastes does something else entirely

Lucas Fenwick — Sat, 11 Jul 2026 05:32:34 +0000

Open the Plugins screen on any WordPress site that is a few weeks behind. Under each outdated plugin, WordPress injects an amber row: "There is a new version of WooCommerce available. View version 10.9.4 details or update now." The Plugins menu item picks up a count badge. On a site with thirty plugins the table stops being scannable.

Most guides hand you one line and stop. The line usually looks like this:

add_filter('site_transient_update_plugins', '__return_null'); // please don't

That does not hide the notice. It empties the transient WordPress stores update results in, so core stops knowing that any plugin has an update. The rows disappear as a side effect, because there is nothing to render. You have not cleaned a dashboard, you have blinded the site, and the next developer to inherit it finds a quiet admin sitting on top of a year of unapplied security releases. If you find that filter in a client site, take it out.

Here is the actual thing that prints the rows. wp_plugin_update_rows() is hooked to admin_init at priority 20, and it loops the update_plugins transient adding a wp_plugin_update_row callback to after_plugin_row_{$file} for every outdated plugin. So you unhook the parent, from an earlier priority on the same hook:

add_action('admin_init', function () {
    remove_action('admin_init', 'wp_plugin_update_rows', 20);
}, 1);

The rows are gone. The update check still runs, which is the point. Load the Plugins screen and the count badge is still on the menu item.

add_filter('wp_get_update_data', function ($data) {
    $data['counts']['plugins'] = 0;
    $data['counts']['total']   = 0;
    $data['title'] = '';
    return $data;
});

Now the rows and the badge are both gone and the update check is intact. Then you want the same treatment for theme update notices, and core, and each one has its own removal. By the time you have covered them all you have a mu-plugin, and the mu-plugin has to travel to every site you build. Miss a hook on one and that client gets a half cleaned dashboard.

I tested the settings-panel version with WP Adminify Pro instead. 20 second demo below.

What plugin update notices actually cost on a client site:

One amber row per outdated plugin, plus a count badge, for every admin who logs in
The notice is aimed at whoever does the updates, which on agency builds is not the person reading it
Clients either learn to ignore amber warnings, or they run an update on production unsupervised
The rows cannot be dismissed, so they never clear until someone updates

What changed after enabling Hide Admin Notices in Adminify Pro:

One toggle under Productivity covers the plugin update rows for every plugin at once
The Plugins count badge clears with them, no separate wp_get_update_data filter to remember
The same module handles the rest of the notice pile-up, so the admin opens to work rather than a stack of banners
The update check keeps running, so a maintenance report still sees every pending update
Survives WordPress updates, no snippet to carry between sites

The caveat I will not skip: hiding the notice does not update the plugin. Your versions are unchanged and any security release you are behind on is still unapplied. This is right when the update has an owner and a schedule: you, your agency, a managed host, an automation with rollback. It is wrong on a site nobody maintains, where the amber row is the only signal anyone will ever get. Decide who owns updates first. Then hide the notice. And whatever you decide, do not null the transient.

Short demo

Step-by-step doc: https://wpadminify.com/docs/adminify/productivity/hide-admin-notices

How do you handle plugin update notices on sites you maintain for other people: unhook wp_plugin_update_rows, hide them with a plugin, or leave them visible on purpose?

adminify #WordPress #notices

Hiding the WordPress core update notice takes two hooks, not one (and why the badge survives)

Lucas Fenwick — Thu, 09 Jul 2026 05:06:15 +0000

Every admin on a WordPress site behind the current release sees the same box above every screen: "WordPress 6.5.3 is available! Please update now." The Updates menu item carries a red count badge next to it, and on a typical production site the plugin and theme update notices stack directly underneath.

Most guides give you one line for this and stop:

add_action('admin_init', function () {
    remove_action('admin_notices', 'update_nag', 3);
    remove_action('network_admin_notices', 'update_nag', 3);
});

update_nag() is what prints the core banner, hooked to admin_notices at priority 3, so unhooking it removes the banner. Load the dashboard and the banner is gone. The red badge is still there.

That's because the badge doesn't come from the notice at all. It's built from wp_get_update_data(), which counts pending core, plugin, theme, and translation updates and feeds both the admin menu bubble and the toolbar item. So you need a second hook:

add_filter('wp_get_update_data', function ($data) {
    $data['counts'] = [
        'plugins' => 0, 'themes' => 0, 'wordpress' => 0, 'translations' => 0, 'total' => 0,
    ];
    $data['title'] = '';
    return $data;
});

Now the banner and the badge are both gone, and you still have the plugin update notice and the theme update notice printing on their own hooks, each with its own removal. By the time you've covered all four you have a file, and the file has to travel to every site you build. Miss one hook on one site and the client's dashboard looks half-cleaned.

I tested the settings-panel version with WP Adminify Pro instead. 20-second demo below.

What the update notices actually cost on a client site:

A red badge and up to three warning boxes on every admin screen, for every admin
The notice is aimed at whoever does the updates, which on agency builds is not the person reading it
Clients either learn to ignore red warnings, or they run a core update on production unsupervised
Nobody can dismiss it, so it never clears until someone updates

What changed after enabling Hide Admin Notices in Adminify Pro:

One toggle under Productivity covers core, plugin, and theme update notices at once
The Updates count badge clears with them, no separate filter
The same module handles the rest of the notice pile-up, so the dashboard opens to the Adminify panel rather than a stack of banners
Survives WordPress updates, no snippet to carry between sites

The caveat I won't skip: hiding the notice does not update WordPress. Your version is unchanged and any security release you're behind on is still unapplied. This is right when the update has an owner and a schedule: you, your agency, a managed host, an automation with rollback. It's wrong on a site nobody maintains, where the banner is the only signal anyone will ever get. Decide who owns updates first. Then hide the notice.

Short demo

Step-by-step doc: https://wpadminify.com/docs/adminify/productivity/hide-admin-notices

How do you handle update notices on sites you maintain for other people, unhook update_nag, hide them via a plugin, or leave them visible on purpose?

The WordPress "PHP Update Required" notice has no dismiss button — here's how to remove it (and why hiding fixing)

Lucas Fenwick — Wed, 08 Jul 2026 08:01:57 +0000

Every admin on a WordPress site below the recommended PHP version sees the same red box on the dashboard: "PHP Update Required — Your site is running an outdated version of PHP (7.4.30), which does not receive security updates and soon will not be supported by WordPress." There's a "Learn more about updating PHP" button — but no Dismiss link.

WordPress renders that warning as a dashboard nag widget with the id dashboard_php_nag, registered in wp_dashboard_setup(). It shows for every admin, on every dashboard load. And you often can't clear it the "right" way on the spot: the PHP version is controlled by the host, a dependency plugin hasn't been tested against the newer build, or the upgrade is scheduled for a maintenance window.

The developer fix is to unhook the nag:

add_action('wp_dashboard_setup', function () {
    remove_meta_box('dashboard_php_nag', 'dashboard', 'normal');
});

This removes the PHP Update Required notice for every admin. But it's a snippet you drop into a mu-plugin and re-add on every install — and the moment you also want to clear the other admin-notice clutter (plugin promos, update nags, review requests), you're back to maintaining a growing list of remove_action/remove_meta_box calls.

I tested the settings-panel version with WP Adminify Pro instead. Short demo below (20s).

What the PHP notice actually costs on a real site:

Every admin — including clients — opens to a red "does not receive security updates" banner
It has no Dismiss button, so nobody can clear it from the UI
On client sites it generates "is my site broken?" support tickets for a warning you already know about

What changed after enabling Hide Admin Notices in Adminify Pro:

One toggle under Productivity — the PHP nag is hidden site-wide for every admin
The same module clears the rest of the admin-notice pile-up (plugin promos, review nags) from the top of every screen
Survives WordPress updates, no snippet to maintain across sites
Dashboard opens straight to Site Health / At a Glance

The important caveat: hiding the notice does not update PHP. It removes the alarm from the interface; your PHP version is unchanged. Only hide it once you've made an informed call — confirm your host's supported PHP, check plugin compatibility, and schedule the real upgrade. This is a cosmetic step for client peace of mind, not a security fix.

Short demo

Step-by-step doc: https://wpadminify.com/docs/adminify/productivity/hide-admin-notices

How do you handle the PHP update nag on client sites — unhook dashboard_php_nag, hide it via a plugin, or leave it until you can upgrade?