How to customize admin columns in WordPress

First decide whether you only need to hide existing columns, add a value that already exists, or make a custom field sortable and filterable. WordPress handles the first task in the admin; the other tasks require code or a plugin.

Write down the target screen, such as Posts, Pages, a custom post type, Users, Media, or Comments. A column hook is tied to a particular list table, so code for Posts will not automatically appear on a custom post type screen.

Open the relevant list screen, such as Posts or Pages, then open Screen Options in the top-right corner. Tick the columns you want and clear the ones you do not want, then select Apply. You can also change how many records appear per page.

This is the right manual route when the column already exists. The setting is screen-specific and may be stored per user, so changing it for one administrator does not necessarily change what other users see. Loading too many rows can also make the admin table slower.

Put site-specific code in a small custom plugin or a child theme rather than editing a parent theme. For a custom post type called book, add a column with the post-type columns filter and print its value with the matching custom-column action:

add_filter( 'manage_book_posts_columns', function( $columns ) { $columns['publisher'] = 'Publisher'; return $columns; } ); add_action( 'manage_book_posts_custom_column', function( $column, $post_id ) { if ( 'publisher' === $column ) { echo esc_html( get_post_meta( $post_id, 'publisher', true ) ); } }, 10, 2 );

Replace book with the registered post-type key and publisher with the custom-field key. Use manage_posts_columns and manage_posts_custom_column for the standard Posts screen, or the page-specific equivalents for Pages. WordPress documents these hooks as the pair used to register and render custom post-list columns.

For a taxonomy column, register the column as above and use a taxonomy function such as get_the_term_list() when rendering it. Escape plain text with esc_html(); if you deliberately output generated term links, make sure the returned markup is safe and appropriate for the admin screen.

User tables use different hooks, including manage_users_columns for the headings and manage_users_custom_column for the values. Media also has its own column hooks. Do not copy a post-column hook into the Users or Media screen and expect it to run.

Adding a value does not make it sortable. For the book example, register the column on the edit-book screen:

add_filter( 'manage_edit-book_sortable_columns', function( $columns ) { $columns['publisher'] = 'publisher'; return $columns; } );

If the value is stored in post meta, you must also alter the admin query when that column is selected, usually by checking the admin screen and the query's orderby value in pre_get_posts, then setting meta_key and orderby to the correct values. This is where many snippets fail: the heading becomes clickable, but the rows stay in date order because the query was never changed. WordPress's sortable-column filter only registers the sortable screen column; it does not perform the database ordering for custom data.

Reload the list table, test pagination, and verify the column for users with different roles. Check empty values, long text, missing terms, and records with no custom field saved. A PHP notice or unescaped output can affect the whole admin table.

Keep the number of columns reasonable. On narrow screens, WordPress applies responsive list-table behaviour around the primary column. If you move or add a column at the front, the layout can become confusing unless the intended primary column is handled correctly. Also check for conflicts with custom post-type, WooCommerce, or field-management plugins that add their own columns.

If you need columns for several post types, custom fields, taxonomies, users, images, or WooCommerce data, use MB Admin Columns instead of maintaining several code snippets. Configure the list screen, choose the data source, arrange the columns, and enable sorting or filtering where supported.

The manual route remains perfectly suitable for one small, stable column. The plugin route is faster when non-developers need to adjust layouts, when you need sortable custom-field data, or when the same site has several admin tables to manage.