DEV Community: Lucas Fenwick

Your WordPress "URL Path" column is not reading a slug, it is computing one

Lucas Fenwick — Mon, 27 Jul 2026 08:02:34 +0000

Add a URL Path column to the WordPress posts list by enabling Custom Admin Columns in WP Adminify: go to WP Adminify > Productivity, toggle on Custom Admin Columns, tick Show "URL Path" Column for Post Types, pick which post types get it from the Posts, Pages and custom post type options that appear, and save, and a URL Path column shows each row a path like /hello-world/, which WordPress computes at render time from post_name plus your permalink structure plus, on hierarchical types, the whole ancestor chain, and not from a stored URL field, which is why the column is blank or a ?p=123 on drafts, because core saves an empty post_name for draft, pending and auto-draft posts.

That is the whole answer. The rest of this post is why the distinction between a stored slug and a computed path produces three separate surprises, one of which is a genuine bug that will hand you a wrong URL with a straight face.

The tooling is not the interesting part

Let me concede this up front, because the SERP is full of it.

Admin Slug Column has 5,000+ active installs, is tested to WordPress 6.9.5, and adds a column it literally calls URL Path across every post type including WooCommerce products. Slug Search and Admin Columns adds ID and Slug columns and wires them into the default search box. Show Page Slug in Admin does the same for Pages. There is an open source version on GitHub. All correct, all fine.

Every one of them describes the column as showing the slug.

It is not showing the slug.

Stored versus computed

WordPress stores exactly one slug per post: post_name, in wp_posts. One segment. hello-world. There is no stored URL column anywhere in the schema.

What a URL Path column renders is assembled at request time by get_permalink():

post_name
+ permalink structure          (Settings > Permalinks)
+ post type rewrite slug       (register_post_type's rewrite arg)
+ ancestor chain               (hierarchical types, via get_page_uri)
+ %category% and friends       (if your structure uses rewrite tags)

Five inputs, one of which is stored on the row. Every surprise below is a consequence of the other four.

Surprise 1: your drafts come back blank

This is the one you will hit within a day of switching the column on, and it is core doing it on purpose. From wp_insert_post():

if ( empty( $post_name ) ) {
    if ( ! in_array( $post_status, array( 'draft', 'pending', 'auto-draft' ), true ) ) {
        $post_name = sanitize_title( $post_title );
    } else {
        $post_name = '';
    }
}

An unpublished post has an empty string for a slug. Not a placeholder, not a guess from the title. Empty.

And that is only half of it. wp_force_plain_post_permalink(), added in WordPress 5.7, decides whether get_permalink() takes the pretty branch or the plain one:

if (
    is_post_status_viewable( $post_status_obj ) ||
    ( $post_status_obj->private && current_user_can( 'read_post', $post->ID ) ) ||
    ( $post_status_obj->protected && $sample )
) {
    return false;
}

return true;

Draft is not viewable. Pending is not viewable. Scheduled (future) is a protected status, and without $sample it does not get the exemption either. So all three return true, and get_permalink() hands back ?p=123.

Admin Slug Column greys those rows out and says the path "isn't an official URL yet", which is the closest anyone in this SERP gets to explaining it. Now you know the two functions responsible.

If you want the path a draft would have, that is a different function: get_sample_permalink(), which is what the Gutenberg permalink panel uses, and it returns the structure with a %pagename% placeholder rather than a finished path.

Surprise 2: a draft parent silently corrupts its children's paths

This one is not a display quirk. This is a wrong answer.

Here is how get_page_uri() assembles a hierarchical path:

foreach ( $page->ancestors as $parent ) {
    $parent = get_post( $parent );
    if ( $parent && $parent->post_name ) {
        $uri = $parent->post_name . '/' . $uri;
    }
}

Read the if twice. An ancestor whose post_name is empty is skipped, silently, with no notice and no fallback.

From surprise 1, we know exactly which posts have an empty post_name: drafts, pending posts and auto-drafts.

So:

You have a page Services, still a draft, being written this week.
You publish Services > Pricing under it, because publishing children first is a normal staging workflow.
Your URL Path column shows /pricing/.
The URL that page will actually have, the moment Services goes live, is /services/pricing/.

The column is not lying about post_name. It is faithfully reporting a computation that dropped a segment. If somebody is building a redirect map, a sitemap submission or an SEO audit off that column, they are building it on a path that does not exist and will never exist.

Go check this on your own site:

SELECT child.ID, child.post_name AS child_slug, parent.post_status AS parent_status
FROM wp_posts child
INNER JOIN wp_posts parent ON parent.ID = child.post_parent
WHERE child.post_status = 'publish'
  AND parent.post_status IN ( 'draft', 'pending', 'auto-draft' );

Every row that comes back is a page whose displayed path is missing a segment.

Surprise 3: you can see the slug and you still cannot search it

This is the one that gets the "wait, really?" reaction, because it is the actual reason most people wanted the column.

WP_Query::parse_search() opens with:

$default_search_columns = array( 'post_title', 'post_excerpt', 'post_content' );

post_name is not on that list. It has never been on that list.

The post_search_columns filter arrived in WordPress 6.2 and looked like the fix, except it validates your return value against those same three columns. There is no filter, no argument and no setting that makes the admin Search Posts box find a post by its slug.

So you can add a column showing /summer-sale-2025/, look straight at it, type summer-sale-2025 into the search box above it, and get nothing.

The proof that this is a real gap and not me splitting hairs: somebody shipped an entire separate plugin called Slug Search and Admin Columns. The column half and the search half are two products because core makes them two problems.

If you need it, the query-level escape hatches are WP_Query's name and post_name__in arguments, or get_page_by_path(). None of them are wired to the admin search box.

Surprise 4: non-Latin slugs render percent-encoded

Smaller, but it will look like a bug the first time you see it. sanitize_title_with_dashes() does this to UTF-8 titles:

if ( wp_is_valid_utf8( $title ) ) {
    if ( function_exists( 'mb_strtolower' ) ) {
        $title = mb_strtolower( $title, 'UTF-8' );
    }
    $title = utf8_uri_encode( $title, 200 );
}

post_name is stored already percent-encoded. A column that prints post_name raw shows %e3%81%93%e3%82%93 where your browser's address bar helpfully renders the actual characters. Admin Slug Column specifically advertises multibyte support, which is a good hint about what the naive implementation does.

If you write your own column, rawurldecode() before display, and be aware you are then showing something that is not byte-identical to the stored value.

Also: `wp_unique_post_slug()` is why you have a `-2`

While we are in here. wp_unique_post_slug() appends -2, -3 and so on when a slug collides, and it scopes that check by post type, parent and status. Two pages with the same title under different parents can both be about. Two posts cannot. A URL Path column is the fastest way to spot the accumulated -2s from duplicated posts, which is honestly one of the better arguments for switching it on.

The cost ladder in one settings panel

Adminify's Custom Admin Columns panel has four checkboxes and they cost wildly different amounts:

Column	What it costs	Sortable?
Post/Page ID	Nothing, the ID is already on the row object	Yes, it is the primary key
Taxonomy ID	Nothing, `term_id` is a real column on `wp_terms`	Yes, no join needed
URL Path	A computed permalink per row, plus an ancestor walk per row on hierarchical types	No. There is nothing to `ORDER BY`
Last Login	A `wp_usermeta` join	Yes, but it drops rows for users missing the meta key

That "No" in the URL Path row is worth sitting with. post_name is a real column, so orderby=name works, but the displayed path is a computed string that exists nowhere in the database. You cannot sort a list by a value the database does not have without computing it for every row first.

Changing a path is where the actual risk lives

Editing the slug of an already published post is covered. wp_check_for_changed_slugs() stores the old one in _wp_old_slug, and wp_old_slug_redirect() 301s the old URL when it 404s.

Not covered:

changing your permalink structure in Settings > Permalinks
changing a post type's rewrite slug in register_post_type()
reparenting a page, which changes the path without touching post_name at all

That third one is the trap, and it is the same mechanism as surprise 2. The slug never changed, so no _wp_old_slug was recorded, so there is no redirect. URL redirection is where you clean that up manually, and replacing an image without changing its URL is the same class of problem on the media side.

The code route

Two hooks, and note the contract, because it is the opposite of the taxonomy one:

// 1. Register the column.
add_filter( 'manage_posts_columns', function ( $columns ) {
    $columns['url_path'] = 'URL Path';
    return $columns;
} );

// 2. Print the value. This is an ACTION. Echo, do not return.
add_action( 'manage_posts_custom_column', function ( $column, $post_id ) {
    if ( 'url_path' !== $column ) {
        return;
    }
    $post = get_post( $post_id );

    if ( in_array( $post->post_status, array( 'draft', 'pending', 'auto-draft' ), true ) ) {
        echo '<span style="opacity:.5">not published</span>';
        return;
    }

    echo esc_html( rawurldecode( wp_make_link_relative( get_permalink( $post_id ) ) ) );
}, 10, 2 );

manage_posts_columns registers, manage_posts_custom_column prints, and it is an action with the signature ( string $column_name, int $post_id ) where you echo. The taxonomy equivalent, manage_{$taxonomy}_custom_column, is a filter where you return. Same feature, opposite contracts, and mixing them up is an hour of your life.

wp_make_link_relative() is what turns the absolute permalink into the /hello-world/ form the screenshot shows. Use manage_pages_columns for Pages, manage_{$post_type}_posts_columns for a specific custom post type, and put the whole thing in a must-use plugin because in functions.php it dies on a theme switch.

The checkbox route

I ran this pass with WP Adminify's Productivity module. Productivity tab, toggle on Custom Admin Columns, tick Show "URL Path" Column for Post Types, then a second option appears, "URL Path" Column for Post Types, with checkboxes for Posts, Pages and, per the docs, every registered custom post type added dynamically. Save.

That per-post-type selector is the one genuine advantage over the free plugins, and it is worth naming precisely because everything else in this post has been a caveat: every other checkbox in that panel is all-or-nothing, and every wordpress.org equivalent applies to all post types. If you run eight and want the path on two, this is the only one that asks.

The same panel carries the other list screen columns people otherwise snippet in one at a time, a Post/Page ID column, a Comment ID column with Parent ID, a Taxonomy ID column, a post thumbnail column and the Last Login column for Users. If you want arbitrary columns rather than the fixed set, the standalone Admin Columns Editor is the bigger hammer, adding an ACF field as an admin column is the next step for custom fields, the rundown of which admin columns actually earn their width is a sane map before you switch five of them on, and the wider Productivity toolset sits in the same place.

Two related things from the same list screen that pair with this column: duplicating a page is the single fastest way to accumulate -2 slugs, and custom post type ordering is the other reason people spend time in these list tables.

The conditions I would put on it

It is a display column. It prints a computed string. The marketing line is "Find, Copy & Share URLs Instantly", and what the screenshot actually shows is /hello-world/, a relative path you cannot paste into a browser or send to a client. WordPress already puts a copyable absolute URL in the row actions View link on every published row. The column's real value is scanning a hundred rows at once, which is a genuinely good reason to have it, just not the one on the box.

It also costs horizontal space on a list already carrying Title, Author, Categories, Tags, Comments and Date, and Screen Options is where you claw that back.

And the thing worth taping to the monitor: on any page whose parent is a draft, that column is showing you a path with a segment missing. Run the SQL above before you trust it for anything that matters.

Demo Video

Which columns are worth the width: https://wpadminify.com/necessary-admin-columns-for-wordpress

WordPress stores two IDs for every category, and the ID column in your admin only shows one of them

Lucas Fenwick — Sun, 26 Jul 2026 06:12:34 +0000

Add an ID column to the WordPress taxonomy list tables by enabling Custom Admin Columns in WP Adminify: go to WP Adminify > Settings > Productivity, scroll to Custom Admin Columns, tick Show "Taxonomy ID" Column for all possible types of taxonomies, and save, and an ID column appears after Count on Categories, Tags and every custom taxonomy screen, and the number it prints is the term_id, the same value that sits in each row edit link as term.php?taxonomy=category&tag_ID=3, which is not the term_taxonomy_id that wp_term_relationships uses to join posts to terms.

That is the whole answer. The rest of this post is where the number was hiding before you added the column, why WordPress has two IDs per term, which one the relationship table uses, and why code that confuses them passes on your laptop and fails on a client site.

The number was never missing

Most admin column tricks are recoveries, and this is one of them. Open Posts > Categories and view source on any term row:

<tr id="tag-3" class="level-0">
  <th scope="row" class="check-column">
    <input type="checkbox" name="delete_tags[]" value="3">
  </th>
  <td class="name column-name">
    <a href="term.php?taxonomy=category&amp;tag_ID=3&amp;post_type=post">Dashboard</a>

The ID is in the row element, in the bulk action checkbox, and in the Edit, Quick Edit and Delete links. Core queried it, loaded it, and printed it into the markup. It just never puts it in a cell you can read.

Which is why the standard workaround exists. TaxoPress, BasicWP and MyThemeShop all teach the same move: hover the category, read tag_ID=3 out of the browser status bar, transcribe it. Reveal IDs with its 40,000+ active installs and Catch IDs automate it. All correct, all fine, and all of them stop at the same sentence: "that number is the category ID".

WordPress has two numbers for that category.

A small aside, because you have probably wondered

The parameter is called tag_ID on every taxonomy. Categories. WooCommerce product_cat. Your custom genre. Tags arrived in WordPress 2.3 and the parameter name arrived with them, and it survived the 4.5 move of term editing from edit-tags.php to term.php. If a category edit screen saying tag_ID has ever looked like a bug to you, it is just a very old name.

WordPress keeps two IDs per term

Here is the taxonomy side of the schema, from the database handbook:

wp_terms                term_id, name, slug, term_group
wp_term_taxonomy        term_taxonomy_id, term_id, taxonomy, description, parent, count
wp_term_relationships   object_id, term_taxonomy_id, term_order
wp_termmeta             meta_id, term_id, meta_key, meta_value

Two auto increment keys, term_id and term_taxonomy_id, for what a human calls one category.

Read the third line again. wp_term_relationships is the table that connects a post to a category, and it does not store term_id at all. It pairs object_id with term_taxonomy_id.

Meanwhile everything in the admin, including the new ID column, speaks term_id.

Core admits the ambiguity in its own API

This is the citation I would put in front of anyone who thinks I am splitting hairs. WP_Tax_Query accepts both, in the same argument:

// These are two different queries.
'tax_query' => [ [ 'taxonomy' => 'category', 'field' => 'term_id',          'terms' => 47 ] ]
'tax_query' => [ [ 'taxonomy' => 'category', 'field' => 'term_taxonomy_id', 'terms' => 47 ] ]

If the two IDs were the same thing, field would not need both values. Core is telling you there are two numbers. The list table is not.

Why this ships as a bug instead of getting caught

On a fresh install the two values line up for the earliest terms. Uncategorized is term_id 1 and term_taxonomy_id 1. Add a handful of categories in order and they keep matching. So SQL that confuses them passes locally, passes code review, and passes staging if staging is a clean install.

They diverge on real sites. WordPress used to allow shared terms, one wp_terms row serving several taxonomies, and it spent two releases undoing that: 4.2 split shared terms when one was updated, and 4.3 split every remaining shared term on upgrade. Splitting means new term_id values, which is exactly how the two columns drift apart. Any site that lived through that, or that has simply run several taxonomies for a few years while the two tables incremented at different rates, has terms where term_id and term_taxonomy_id are different numbers.

That split is also why get_term() could make its $taxonomy parameter optional in 4.4: once terms stopped being shared, a term_id identified a term on its own. Useful history, and the same history that put two IDs on your screen with no label.

Run this on your oldest client site:

SELECT term_id, term_taxonomy_id, taxonomy
FROM wp_term_taxonomy
WHERE term_id != term_taxonomy_id
LIMIT 10;

If that returns rows, every hand written join on that site is a coin flip.

Where each number is safe

Safe with the term_id your column shows:

get_term( 3 )
wp_list_categories( array( 'include' => 3 ) )
a tax_query with the default field
get_term_link( 3, 'category' )
WP_Term_Query with include
Elementor, Bricks and query loop widgets that ask for term IDs

Check before you trust it:

any hand written SQL touching wp_term_relationships
import and migration mappings, where both numbers appear in the same export
wp_get_object_terms() results being fed back into raw SQL
anything copying an ID from one site's admin into another site's config

Get the right number for the join like this:

$term = get_term( 3, 'category' );
$ttid = $term->term_taxonomy_id;   // the value wp_term_relationships wants

Or in SQL:

SELECT p.ID, p.post_title
FROM wp_posts p
INNER JOIN wp_term_relationships tr ON tr.object_id = p.ID
INNER JOIN wp_term_taxonomy tt ON tt.term_taxonomy_id = tr.term_taxonomy_id
WHERE tt.term_id = 3 AND tt.taxonomy = 'category';

Note the join goes through wp_term_taxonomy. That is not boilerplate, it is the translation layer between the two IDs.

One thing this column gets right

It is safe to sort. term_id is a real column on wp_terms, so get_terms() can order by it with no join and no dropped rows.

Compare the Last Login column from the same settings panel. That one sorts on user meta, which joins wp_usermeta on the meta key and removes every user who does not have it, so sorting to find dormant accounts can delete the dormant accounts from the list. Same panel, opposite risk profile, and worth knowing which column you are clicking.

The code route

Two hooks, and the second one has a contract people get wrong:

// 1. Register the column.
add_filter( 'manage_edit-category_columns', function ( $columns ) {
    $columns['term_id'] = 'ID';
    return $columns;
} );

// 2. Print the value. This is a FILTER. Return, do not echo.
add_filter( 'manage_category_custom_column', function ( $out, $column, $term_id ) {
    return ( 'term_id' === $column ) ? (int) $term_id : $out;
}, 10, 3 );

// 3. Optional, make it sortable.
add_filter( 'manage_edit-category_sortable_columns', function ( $columns ) {
    $columns['term_id'] = 'term_id';
    return $columns;
} );

manage_{$taxonomy}_custom_column has been a filter since WordPress 2.8, with the signature ( string $string, string $column_name, int $term_id ) and an empty string default. The posts equivalent, manage_{$post_type}_posts_custom_column, is an action where you echo. Same feature, two different contracts, and the taxonomy one is where people lose an hour.

Fine print: swap category for post_tag or your own taxonomy, register one pair per taxonomy or hook manage_edit-{$taxonomy}_columns dynamically for all of them, use manage_{$screen->id}_sortable_columns if you prefer the screen-based hook name, and put the whole thing in a must-use plugin because in functions.php it dies on a theme switch.

The checkbox route

I ran this pass with WP Adminify's Productivity module. Settings, Productivity tab, scroll to Custom Admin Columns, tick Show "Taxonomy ID" Column for all possible types of taxonomies, save. The ID column appends after Count.

The same panel carries the other list screen columns people otherwise snippet in one at a time, a Post/Page ID column, a Comment ID column with Parent ID, a post thumbnail column and a URL Path column, all documented on that page. If you want arbitrary columns rather than the fixed set, the standalone Admin Columns Editor is the bigger hammer, customising columns for any post type is the docs entry for that, and WooCommerce product columns is the same idea on product_cat and friends. The rundown of which admin columns actually earn their width is a sane map before you switch five of them on, adding an ACF field as an admin column is the next step for custom fields, and the wider Productivity toolset sits in the same place.

The conditions I would put on it

It is a display column. It prints a number, it does not tell you which of the two IDs your other code needs, and it does not remap, merge or migrate anything. It costs horizontal space on a Categories screen already carrying Name, Description, Slug and Count, and Screen Options is where you claw that back. If you enable it on a site with many taxonomies, check that it appears on the ones you care about rather than assuming, because "all possible types of taxonomies" is a claim worth testing on a custom taxonomy.

And the thing worth taping to the monitor: the ID on that screen is the term_id. If your next step is a join, translate it first.

Demo Shorts

Docs for the checkbox route: https://wpadminify.com/docs/adminify/productivity/custom-admin-columns

WordPress has never stored when your users last logged in, and the column you add records something slightly different

Lucas Fenwick — Sat, 25 Jul 2026 06:15:52 +0000

Show the Last Login column for users in the WordPress admin by enabling Custom Admin Columns in WP Adminify: go to WP Adminify > Settings > Productivity, scroll to Custom Admin Columns, tick Show "Last Login" Column for Users, and save, and a Last Login column appears on the Users screen, but it starts blank for every existing user and fills in only as each one signs in again, because WordPress core stores no last login date anywhere, there is no last_login field in wp_users and no user meta key core writes for it, so no plugin on any site can show a login that happened before it was installed, and what the column records is the wp_login authentication event rather than activity, which means an editor who ticked Remember Me can work in the dashboard every day for two weeks while that column still reads 14 days ago.

That is the whole answer. The rest of this post is why the column is empty, what it is actually measuring, the login timestamp core keeps and then destroys, and a sorting behaviour that can hide the accounts you are auditing for.

There is no field to reveal

Most admin column tricks are recoveries. The Posts list already knows the post ID and drops it. The Comments list already knows comment_parent and prints an author name instead. You add a column, the number comes back.

This one is not that. Here is wp_users, in full:

ID
user_login
user_pass
user_nicename
user_email
user_url
user_registered
user_activation_key
user_status
display_name

Registration date, yes. Last login, no. And core writes no user meta key for it either. Every implementation of this feature, WP Last Login with its 10,000+ installs, the WPBeginner snippet, rudrastyh's sortable version, all of them do the same two things: hook wp_login, write a timestamp to user meta.

So the column is not uncovering a field. It is starting a recording, and a recording has no past. Every existing user reads Never on day one and fills in one at a time as people sign back in. WPBeginner and rudrastyh both say this plainly, so it is baseline knowledge rather than a discovery. The next three parts are not.

What actually gets recorded

Here is the end of wp_signon() in wp-includes/user.php:

wp_set_auth_cookie( $user->ID, $credentials['remember'] );

/**
 * Fires after the user has successfully logged in.
 */
do_action( 'wp_login', $user->user_login, $user );

wp_login fires on authentication. That is the moment credentials are checked and a cookie is issued.

It does not fire when a browser comes back holding a cookie that is still valid. And wp_set_auth_cookie() issues generous cookies:

if ( $remember ) {
    $expiration = time() + apply_filters( 'auth_cookie_expiration', 14 * DAY_IN_SECONDS, $user_id, $remember );
} else {
    $expiration = time() + apply_filters( 'auth_cookie_expiration', 2 * DAY_IN_SECONDS,  $user_id, $remember );
}

Fourteen days with Remember Me ticked. Two days without. Both adjustable through auth_cookie_expiration, and almost nobody adjusts them.

Work the arithmetic on a real team. An editor who ticks Remember Me and opens the dashboard every weekday re-authenticates roughly twice a month. Their Last Login has a hard staleness ceiling of 14 days, and on any given morning it can read 13 days old while they are actively editing.

Last Login column:  July 11, 2026
Reality:            in the dashboard every day since July 11
Difference:         one auth event vs 14 days of work

Which means the column answers "when did this person last type their password", not "when was this person last here". Those are different questions, and dormant-account audits ask the second one.

Core does record a login time, then throws it away

This is the part I have not found written down anywhere.

WP_Session_Tokens::create() builds a session record and stamps it:

$session = $this->get_session_information( $expiration );

// Timestamp.
$session['login'] = time();

The record lands in the session_tokens user meta, keyed by a hash of the session token:

get_user_meta( $user_id, 'session_tokens', true );
/*
array(
  '9f2c...' => array(
      'expiration' => 1754648160,
      'ip'         => '203.0.113.7',
      'ua'         => 'Mozilla/5.0 ...',
      'login'      => 1753436160,   // <- the login timestamp
  ),
)
*/

So core knows exactly when the login happened. It stores the number inside a live session record, which is destroyed on logout and garbage collected when the session expires.

Core keeps a login timestamp only for users who are logged in right now. The users you are auditing are, by definition, the ones whose record core already deleted. It is a genuinely funny piece of design: the data exists precisely when it is least useful.

Worth knowing for a second reason. If you want to know who is logged in right now, that meta is the answer and the Last Login column is not. Two different questions, two different sources.

The sorting behaviour that inverts the audit

Here is the one that costs something.

Sorting a Users list by a custom column normally means registering the column as sortable and then setting meta_key plus an orderby on the user query. That join is on the meta key, so a user with no row for that key is not sorted to the bottom. That user is excluded from the result set.

Play it out. You enable Last Login specifically to find dormant accounts. You click the column header to sort oldest first. Every row reading Never can drop out of the list, and Never is the strongest dormancy signal on the screen. The audit deletes its own findings.

The fix, if you are building this yourself, is to keep the never-logged-in users in the query with a two-branch meta_query rather than a bare meta_key, via pre_get_users:

add_action( 'pre_get_users', function ( $query ) {
    if ( 'wpa_last_login' !== $query->get( 'orderby' ) ) {
        return;
    }
    $query->set( 'meta_query', array(
        'relation' => 'OR',
        'logged'   => array( 'key' => 'wpa_last_login', 'compare' => 'EXISTS' ),
        'never'    => array( 'key' => 'wpa_last_login', 'compare' => 'NOT EXISTS' ),
    ) );
    $query->set( 'orderby', 'logged' );
} );

Test that on your own install before trusting it, meta_query ordering is fiddly and version-sensitive.

Honestly though, for an actual dormancy audit, skip the column and run the query:

SELECT u.ID, u.user_login, u.user_registered
FROM wp_users u
LEFT JOIN wp_usermeta m
  ON m.user_id = u.ID AND m.meta_key = 'wpa_last_login'
WHERE m.umeta_id IS NULL
ORDER BY u.user_registered ASC;

Every row is someone who has not authenticated since you started recording. Swap wp_ for your real table prefix and swap the meta key for whatever your plugin writes.

The code route, and its fine print

Recording first, because there is nothing to display until you do:

// mu-plugin, not functions.php
add_action( 'wp_login', 'wpa_record_last_login', 10, 2 );
function wpa_record_last_login( $user_login, $user ) {
    update_user_meta( $user->ID, 'wpa_last_login', time() );
}

Then the column, using manage_users_custom_column for the value:

add_filter( 'manage_users_columns', 'wpa_last_login_column' );
function wpa_last_login_column( $columns ) {
    $columns['wpa_last_login'] = 'Last Login';
    return $columns;
}

add_filter( 'manage_users_custom_column', 'wpa_last_login_value', 10, 3 );
function wpa_last_login_value( $output, $column, $user_id ) {
    if ( 'wpa_last_login' !== $column ) {
        return $output;
    }
    $ts = get_user_meta( $user_id, 'wpa_last_login', true );
    if ( ! $ts ) {
        return 'Never';
    }
    return wp_date(
        get_option( 'date_format' ) . ' ' . get_option( 'time_format' ),
        (int) $ts
    );
}

The fine print:

Use update_user_meta() and store a raw Unix timestamp, not a formatted string. Formatting at write time locks you out of sorting and out of timezone changes
Use wp_date() rather than date() so the output respects the site timezone
User meta is global on multisite. wp_usermeta is not per-site, so a Last Login recorded on one site in the network shows on every site's Users screen. That is either useful or misleading depending on what you are auditing
The value callback runs per row, so this is one get_user_meta() per user on screen. Fine at 20 rows, worth thinking about at 500
Application password requests, REST authentication and programmatic wp_set_current_user() do not go through wp_signon(), so headless and API traffic will not update this
In a mu-plugin it survives theme switches. In functions.php it does not

The checkbox route

I did this run with WP Adminify's Productivity module. Settings > Productivity tab > scroll to Custom Admin Columns > tick Show "Last Login" Column for Users > save.

The Last Login column appends to the Users screen after Posts, no code, survives theme switches. Their own guide states the feature is in the free version on wordpress.org, worth verifying against your install before you promise it to a client
The full walkthrough with the code alternative is on how to show the Last Login column in the WordPress Users list
The same panel carries the rest of the list-screen columns people usually snippet in one at a time, Show Post/Page ID Column, Comment ID with Parent ID, Taxonomy ID, and a URL Path column with per-post-type selection, all on the Custom Admin Columns docs page
If you want a date column and also arbitrary meta columns, the standalone Admin Columns Editor is the bigger hammer
This rundown of necessary admin columns for WordPress is a decent map of which columns earn their width
On the users side of the same product, hiding the admin bar based on user roles and changing a WordPress username are the two adjustments most sites make next
It all sits inside the wider Productivity toolset

The caveats I will not skip. A Last Login column is a date on a screen. It does not log activity, record sessions, capture IP addresses or flag anything, so treat "track user activity" as marketing rather than a feature. If you actually need activity records, that is a separate job and monitoring user activity in WordPress plus the track users docs is the honest pointer. The column also costs horizontal space on a Users screen already carrying Username, Name, Email, Role and Posts, and Screen Options is where you get it back. The docs page does not document the column as sortable, so treat sorting as unconfirmed, and if it is sortable, check the never-logged-in behaviour above before you rely on it.

One more, for the offboarding case

A last login date is personal data. If you are recording it to satisfy a security policy, it also lands inside whatever data export and erasure obligations you already have, and it should be in your privacy policy alongside the rest of the user meta you collect. Not a reason to skip the column. A reason to write it down.

Short demo

Guide: How to show the Last Login column in the WordPress Users list

So: column on permanently, snippet in a mu-plugin, or a scheduled query? And has anyone here actually cross-checked a dormant list against session_tokens before revoking access?

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

DEV Community: Lucas Fenwick

Your WordPress "URL Path" column is not reading a slug, it is computing one

The tooling is not the interesting part

Stored versus computed

Surprise 1: your drafts come back blank

Surprise 2: a draft parent silently corrupts its children's paths

Surprise 3: you can see the slug and you still cannot search it

Surprise 4: non-Latin slugs render percent-encoded

Also: wp_unique_post_slug() is why you have a -2

The cost ladder in one settings panel

Changing a path is where the actual risk lives

The code route

The checkbox route

The conditions I would put on it

WordPress stores two IDs for every category, and the ID column in your admin only shows one of them

The number was never missing

A small aside, because you have probably wondered

WordPress keeps two IDs per term

Core admits the ambiguity in its own API

Why this ships as a bug instead of getting caught

Where each number is safe

One thing this column gets right

The code route

The checkbox route

The conditions I would put on it

WordPress has never stored when your users last logged in, and the column you add records something slightly different

There is no field to reveal

What actually gets recorded

Core does record a login time, then throws it away

The sorting behaviour that inverts the audit

The code route, and its fine print

The checkbox route

One more, for the offboarding case

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

The substitution, not the omission

Parent ID 0 is a value, not a blank

Do not carry the post ID explanation over

What it actually costs

The code route, and its fine print

The checkbox route

The core behaviour that quietly breaks threads

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

The workaround is the proof

Why your IDs look random

What it actually costs

The code route, and its fine print

The checkbox route

The warning that matters more than the column

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

The featured image was never in the post

Why the gap actually costs something

The code route: five lines, plus fine print

The checkbox route

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

What a WordPress post actually is

Where the "lost" data lives

Doing it correctly in code

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

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

The settings-panel version

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

What a WordPress menu actually is

Where the nesting lives, and why it breaks

Doing it correctly in code

Gotcha one: the copy is not assigned to a location

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

The settings-panel version

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

What a drag-drop reorder actually does

Why the front end does not care

Doing the second job

Gotcha one: posts do not even have an order field

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

The settings-panel version

adminify

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

Path one: Screen Options is a filter

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

The answer that actually ranks, and why it is cosmetic

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

Also: `wp_unique_post_slug()` is why you have a `-2`