WordPress Screen Options vs. Custom Columns

WordPress Screen Options vs. Custom Columns can be confusing because both features affect what appears in WordPress administration tables, but they operate at different levels.

Screen Options primarily let users control the presentation of an existing admin screen.

Custom columns change the information that the screen itself is capable of displaying.

The distinction can be summarized as:

Screen Options
→ control visibility and screen preferences

Custom Columns
→ define additional information in the table

If a Posts screen already contains an Author column, Screen Options can allow a user to hide or show it.

If you want the Posts screen to display a new SEO Score, Product Code, Reading Time or Client column, that information first needs to exist as a column. Only then can WordPress expose that column as something the user may show or hide.

The two systems therefore complement each other rather than compete with each other.

This guide explains how WordPress Screen Options interact with admin list-table columns, how custom columns are registered and populated, where user preferences are stored conceptually, how sorting differs from visibility, and when a site should rely on native Screen Options versus defining a standardized admin-column configuration.

What WordPress Screen Options actually control

The Screen Options tab appears near the top-right corner of many WordPress administration screens.

Its contents depend on the current screen.

On a content list such as Posts → All Posts, Screen Options may allow a user to control:

• which columns are visible;
• how many items appear per page;
• other screen-specific preferences exposed by WordPress or plugins.

On other administration screens, the available controls may be different.

That is why Screen Options should be understood as a screen-specific preference system rather than a single global WordPress setting.

For a broader explanation of the feature, see WordPress Screen Options, Explained.

Column visibility is one of the most important Screen Options features

Consider a Posts list table containing:

• Title;
• Author;
• Categories;
• Tags;
• Comments;
• Date.

A particular editor may not need to see Tags.

They can open Screen Options and disable that column.

The important detail is that the Tags column still exists.

Screen Options did not remove the column from WordPress’s table definition. It changed whether that particular user sees it.

Conceptually:

Registered columns:
Title
Author
Categories
Tags
Comments
Date

User preference:
Tags = hidden

Rendered table:
Title
Author
Categories
Comments
Date

Another user on the same website can still choose to display Tags.

Screen Options are generally personal preferences

WordPress saves many administration-screen preferences against the current user rather than treating them as one universal site configuration.

This is useful because different roles may have different workflows.

An administrator may want a dense table containing technical information, while an editor may prefer a smaller set of editorial columns.

That flexibility is valuable, but it also explains why Screen Options alone are not always sufficient when an organization needs every user to work from a predictable administrative interface.

For that broader problem, see Standardizing the WordPress Admin for Teams.

What custom WordPress columns actually do

A custom column changes the structure of an administration list table by adding information that WordPress would not otherwise display there.

Suppose a website has a custom post type named book.

By default, its administration screen might show information such as:

• Title;
• Author;
• Date.

But the content model may also contain:

• ISBN;
• Publisher;
• Publication Year;
• Genre.

Without custom columns, editors may need to open each Book individually to inspect those values.

A better list screen could become:

Title | ISBN | Publisher | Year | Genre | Date

That is not merely a visibility preference.

The table has gained new information.

For the broader architecture behind these screens, see WordPress Admin List Tables, Explained.

WordPress provides dedicated column hooks

For Posts, WordPress exposes the manage_posts_columns filter.

For a specific post type, developers can use the dynamic pattern:

manage_{$post_type}_posts_columns

For example, a book post type can use:

manage_book_posts_columns

The official WordPress Developer Reference for post-type columns documents this filter.

A basic implementation might look like:

function project_book_columns( $columns ) {

    $columns['isbn'] = __( 'ISBN', 'project' );
    $columns['publisher'] = __( 'Publisher', 'project' );

    return $columns;
}

add_filter(
    'manage_book_posts_columns',
    'project_book_columns'
);

The table now knows that those columns exist.

But registering a heading is only the first half of the job.

The column also needs a value

WordPress provides a corresponding action for rendering custom post-type column content:

manage_{$post_type}_posts_custom_column

The official WordPress documentation for custom column output describes the action and its parameters.

For example:

function project_book_column_content(
    $column,
    $post_id
) {

    if ( 'isbn' === $column ) {

        $isbn = get_post_meta(
            $post_id,
            '_isbn',
            true
        );

        echo esc_html( $isbn );
    }

    if ( 'publisher' === $column ) {

        $publisher = get_post_meta(
            $post_id,
            '_publisher',
            true
        );

        echo esc_html( $publisher );
    }
}

add_action(
    'manage_book_posts_custom_column',
    'project_book_column_content',
    10,
    2
);

The resulting table can now display actual metadata for each Book.

How Screen Options and custom columns work together

This is where the distinction becomes especially useful.

A properly registered custom column can participate in WordPress’s normal column-visibility system.

In other words:

Developer registers column
        ↓
WordPress knows column exists
        ↓
Column appears in list table
        ↓
Screen Options can expose its visibility
        ↓
User can show or hide it

The official documentation for manage_posts_custom_column explicitly notes that custom columns added through the corresponding column filters automatically appear in Screen Options.

This means developers generally do not need to build a second visibility interface simply to let users hide a correctly registered list-table column.

Screen Options do not create the custom data

If the table does not contain an ISBN column, opening Screen Options will not somehow discover an ISBN custom field and offer it automatically.

Screen Options work with the columns that the screen has registered.

The sequence matters:

Custom field exists
≠
admin column exists

Admin column registered
→
column can be displayed

Column registered
+
Screen Options
→
user can control visibility

This distinction becomes important on sites with large amounts of custom metadata.

WordPress does not need to turn every custom field into an administration column.

Only information that is useful during list-level management should normally be promoted into the table.

Hiding a column is not the same as removing it

If an editor hides Publisher through Screen Options, the column definition still exists.

If a developer removes Publisher from the registered column array, users can no longer enable it through the normal column visibility control because the screen no longer exposes that column.

That gives developers and users different levels of control:

Developer:
What columns are available?

User:
Which available columns do I want visible?

Screen Options are about preferences; custom columns are about information architecture

This is the most useful way to decide which mechanism a project needs.

Use Screen Options when the information already exists

If WordPress or a plugin already provides a useful column and the only requirement is:

I do not want to see this column

Screen Options are usually enough.

Examples include hiding:

• Author;
• Categories;
• Tags;
• Comments;
• Date;
• a plugin-provided SEO column.

No custom PHP is necessary simply because one user prefers a cleaner table.

Use a custom column when important information is missing

If the requirement is:

I need to see information
that this table does not currently show

you need a column implementation.

Useful examples might include:

• SKU;
• product supplier;
• event date;
• assigned account manager;
• reading time;
• featured status;
• internal content ID;
• custom taxonomy;
• workflow status;
• last synchronization date.

TheOneWP provides Custom Content Columns for configuring useful information in supported WordPress administration lists without requiring every column to be implemented manually.

Use both when the information is useful but not universally required

This is often the ideal combination.

For example, an editorial site may register:

Title
Author
Section
Reading Time
SEO Status
Last Updated
Date

An SEO specialist might display all of them.

A writer may only need:

Title
Author
Section
Date

The data architecture remains consistent while individual users retain control over the amount of information shown.

Column visibility, sorting and pagination are separate systems

A frequent source of confusion is treating every list-table feature as one configuration.

They are related, but separate.

A column can be:

• registered;
• visible or hidden;
• populated with data;
• sortable or not sortable.

Those are distinct decisions.

A visible column is not automatically sortable

Suppose you add a Publication Year column.

Displaying:

2022
2024
2026

does not automatically mean clicking the column heading will reorder the posts.

WordPress exposes a screen-specific sortable-column filter:

manage_{$screen_id}_sortable_columns

The official sortable-columns documentation explains this mechanism.

For the book post type, the screen ID would typically be:

edit-book

and a sortable column can be registered accordingly.

However, declaring a column sortable only tells the list table that sorting is available.

The underlying WordPress query must also understand how to order the records.

For the deeper relationship between table headings and query ordering, see WordPress List-Table Sorting, Explained.

Items per page are another Screen Option

Many list screens also let the user decide how many records appear per page.

This changes:

20 posts per page
→
50 posts per page

but it does not alter which columns exist.

WordPress provides the add_screen_option() API for registering supported administration screen options such as per-page and layout controls.

WordPress then saves supported screen-option values through its user-preference system.

Again, this is different from the list-table column API.

Custom columns can improve workflow, but they can also hurt performance

Adding a column looks inexpensive because the final result may contain only a short value.

The expensive part can be obtaining that value for every row.

Suppose the screen shows 100 posts and a custom column performs an additional database query for every post.

You may have created:

1 list query
+
100 additional queries
=
avoidable admin overhead

Add several poorly implemented columns and the administration screen can become noticeably slower.

Avoid unnecessary per-row work

Custom column callbacks run repeatedly as WordPress renders the table.

Avoid doing expensive work inside each callback such as:

• remote API requests;
• large uncached queries;
• recalculating complex statistics;
• loading large object collections;
• performing the same lookup repeatedly.

If information is expensive to calculate but changes infrequently, consider whether it should be calculated earlier and stored in an appropriate form.

Hidden does not necessarily mean free

Do not design expensive column logic under the assumption that hiding a column through CSS will solve its performance cost.

CSS hiding only affects presentation after the server has generated the response.

The better approach is to integrate with WordPress’s actual column visibility architecture and avoid unnecessary processing where practical.

More columns can also reduce usability

A technically impressive table containing fifteen columns may be less useful than a carefully designed table containing six.

Too many columns create:

• narrow title areas;
• wrapped values;
• horizontal pressure;
• poor readability;
• awkward responsive behavior;
• more decisions for editors.

Custom columns should expose high-value information, not every value stored in the database.

Think about roles, teams and standardized admin interfaces

Screen Options are convenient precisely because users can personalize their workspace.

That can become a disadvantage when a team requires a predictable interface.

Imagine support documentation that says:

Check the "Approval Status" column.

One employee sees it.

Another previously hid it through Screen Options and assumes the feature is missing.

A third user has ten additional plugin columns enabled and can barely find it.

The underlying WordPress configuration is identical, but the visible interfaces differ.

Personalization and standardization solve different problems

Personal Screen Options are useful when:

• users have different responsibilities;
• advanced users need more information;
• individual workflow preferences matter;
• there is no need for identical screenshots or documentation.

A standardized configuration becomes more useful when:

• many users perform the same task;
• training material assumes a specific layout;
• clients should see a simplified interface;
• support teams need predictable screens;
• the organization wants to reduce accidental interface complexity.

See Standardizing the WordPress Admin for Teams for the wider administration strategy.

For client-facing projects, Reducing WordPress Admin Confusion for Clients covers the same issue from a usability perspective.

Do not remove useful flexibility without a reason

Standardization does not mean every user must see exactly the same information forever.

A sensible administration design can define a useful default while still allowing experienced users to expose additional information when necessary.

The correct balance depends on the organization.

How to design a useful WordPress column strategy

Before adding or removing columns, start with the workflow rather than the available hooks.

Ask what decision the list screen should support

A good custom column helps someone answer a useful question without opening every item.

For example:

Is this article ready?
Who owns this project?
When does this event start?
Which supplier provides this product?
Has this item been synchronized?
What is this product's SKU?

If a column does not help users identify, compare, filter, sort or act on records, it may not belong in the table.

Keep the primary column readable

WordPress list tables have a primary column that normally carries important row interactions.

Do not compress the Title column into a tiny strip because several secondary values were promoted into separate columns.

The table still needs to work as a content-management interface.

Decide whether a value needs visibility, sorting or filtering

These requirements should be considered separately.

A useful planning table might look like:

This prevents the common mistake of assuming every displayed value needs every list-table feature.

Test with realistic datasets

A custom column that performs perfectly with eight posts may become problematic with:

• 50 rows per page;
• several thousand posts;
• multiple metadata lookups;
• large taxonomy relationships;
• several plugins adding their own columns.

Test the actual administration workflow rather than only confirming that the column renders.

Using TheOneWP Custom Content Columns

TheOneWP Custom Content Columns is designed to make supported WordPress administration list screens more informative without requiring a separate custom interface for every content type.

The objective is the same as a carefully implemented custom-column system:

existing WordPress list table
+
useful additional information
=
faster content management

This can be particularly useful when a site has custom content structures and editors repeatedly need information that is stored on the item but not visible from the list screen.

Custom columns should complement native WordPress behavior

The best administration customization usually extends the list table rather than attempting to replace it.

Native list tables already provide important behavior such as:

• bulk selection;
• row actions;
• pagination;
• search;
• filters;
• sortable columns;
• Screen Options;
• user-specific preferences.

Preserving those conventions reduces the amount of custom interface logic users need to learn.

Use Screen Options after adding useful information

The ideal result is not necessarily a table where every available column is permanently visible.

A better approach is often:

define useful columns
        +
preserve user visibility controls
        =
flexible native admin workflow

That gives WordPress administrators more information without forcing every user to work with the densest possible table.

Screen Options vs. Custom Columns checklist

• Use Screen Options when a column already exists and only its visibility needs to change.
• Use a custom column when the list table needs to display new information.
• Remember that Screen Options do not automatically turn custom fields into columns.
• Register columns through the appropriate WordPress list-table filters.
• Populate custom columns through the appropriate output actions.
• Escape custom column output correctly.
• Keep expensive operations out of per-row callbacks where possible.
• Do not assume a visible column is automatically sortable.
• Implement the underlying query behavior when adding sortable custom columns.
• Do not use CSS hiding as a replacement for WordPress column visibility.
• Keep the primary content column wide enough to remain useful.
• Avoid adding columns simply because the data exists.
• Choose columns according to real editorial or administrative decisions.
• Consider whether users need different column configurations.
• Consider standardization when teams require predictable interfaces.
• Test custom columns with realistic numbers of rows.
• Test narrow administration layouts.
• Test with plugins that add their own columns.
• Check whether custom values need sorting independently from visibility.
• Retest list screens after significant plugin or WordPress changes.

Related guides

• WordPress Screen Options, Explained
• WordPress Admin List Tables, Explained
• WordPress List-Table Sorting, Explained
• Standardizing the WordPress Admin for Teams
• Reducing WordPress Admin Confusion for Clients
• How to Set a Fixed Dashboard Layout in WordPress

Final recommendation

WordPress Screen Options and custom columns solve two different layers of the same administration problem.

Custom columns determine what information a list table can provide.

Screen Options help determine which of those available columns an individual user actually wants to see.

The relationship is therefore:

Custom Columns
→ available information

Screen Options
→ personal presentation

If the information already exists in the table and a user simply wants a cleaner screen, use Screen Options.

If editors repeatedly open individual posts because an important value is missing from the list, consider adding a custom column.

When that new column is registered through WordPress’s normal list-table architecture, it can participate in the same visibility system as native columns, giving users the ability to show or hide it according to their workflow.

Do not stop at visibility, however. Decide separately whether the value needs to be sortable or filterable, and consider the performance cost of generating the value for every row.

For teams, also decide how much personalization is desirable. Individual Screen Options are useful for specialized workflows, while standardized column configurations can make training, documentation and client administration more predictable.

TheOneWP Custom Content Columns can extend supported WordPress list screens with additional useful information while preserving the familiar administration-table workflow.

The strongest approach is therefore not Screen Options or custom columns. It is to define the right information at the list-table level and then give users an appropriate amount of control over how much of that information they see.