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

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