"Apply" button for screen options isn't just for the per-page setting

[helen]

The "Apply" button for screen options is output inside WP_Screen::render_per_page_options() and is displayed next to the per-page setting. By default right now this makes sense, as all other core screen options update via Ajax or are links (problematic in itself). However, there is a screen_settings filter that displays below the per page options, which are not always shown. Plugins that use this filter either also update via Ajax, piggyback onto the per-page's apply button, or add their own.

This makes adding other non-Ajax screen options not very pleasant for developers or users, both for plugins and when looking at them in core, such as in #22222.

Additionally, the button is secondary, when it's really your primary action and takes you away from the page. Related: #23738

[helen]

My inclination would be to put Apply on its own line and make it a primary button. There are, however, some issues with this:

• Some screen options don't need an Apply button at all, so pulling it out of the per page render method and always showing it is probably not a good solution. @afercia noted that those options that save on Ajax don't really provide feedback about what's happened, either visually where your eyes are focused or for screenreaders. That should be considered separately, just wanted to note it upfront.
• Given the above about not being able to indiscriminately show the button all the time, it's also a bit more difficult to be smart about whether plugins need a button.
• Because of the mixed context, it could/would be confusing as to which options save on their own and which need the Apply button. Related weirdness: all the data gets sent in the request, just not everything is used.

I *think* we could do something a little funky here around filtering whether to show the button, defaulting it to off and turning it on in some of our own render methods. Not sure what to do about the UX trickiness of the last point, though.

[helen]

34295.diff​ is a possible technical approach, using the filter method.

Screenshot:

[helen]

And thanks to @afercia, here are a couple screenshots with plugins, one that uses the submit button and one that applies the changes live. The results are very good - except for the UX issue of the mixed saving contexts (which I suspect is a bit of a rabbit hole, and exists now in mostly worse ways), I think we can roll with this and document this filter in a Make/Core guide post about various button changes.

[helen]

In 35161:

Screen options: Improve the "Apply" button

Previously the button was output as a part of the per-page option rendering, inline with that input. While this was appropriate for core's usage, the screen_settings filter has allowed plugins to place additional items at the bottom of the panel, which a number take advantage of. This leads to confusing situations where plugins that don't save settings via Ajax either have to add their own button or piggyback onto the existing button, which doesn't make any sense in the flow of additional options. It also hinders core from adding any other options that need to be submitted.

Also, when the screen options panel is open, a submit button there is the primary action at that moment. The "Apply" button also does a full page load, which a primary button indicates better.

fixes #34295. see #22222, #23738.

[helen]

Derp, failed to mention in the commit that the button will continue to only show by default when the per-page option is there, but is on its own line and can be turned on by plugins by using add_filter( 'screen_options_show_submit', '__return_true' ).

[ocean90]

Want to mention that I just accidentally clicked on the "Apply" button after changing a column setting… ¯\_(ツ)_/¯