DataViews: Allow users to configure which actions are primary

[oandregal]

Related #57669

What problem does this address?

Third parties can start extending some of our DataViews-based screens, such as the Pages page, via registerEntityAction and unregisterEntityAction.

While desired, this can grow wildly if unchecked: for example, I presume most plugins will want its actions to be primary. I've done a quick test by setting all existing actions as primary to see how the screen scales and this is what I've got:

Gravacao.do.ecra.2024-09-24.as.10.23.23.mov

What is your proposed solution?

We should look at how to alleviate this UI tension derived from extensibility.

[oandregal]

One option could be limiting the number of primary actions to a certain number (say, 3). This is not a solution, though, because if more actions declare to be primary, how do we decide which ones to display? It's a FIFO queue or a LIFO queue? Whatever we decide, it's going to be problematic because 3rd parties can register/unregister as they want: there's visual instability of primary actions depending on plugins active, etc.

[oandregal]

A more promising path would be letting users to modify the action's primary state.

Actions can still declare they're primary and plugins can mark them as such — so, after activating a plugin users may see new actions available. However, they'd be able to modify that state. This could be similar to how browser's extension work: once installed, you can pin/unpin them to make them visible or not in the browser bar (they're always available via the browser's extension menu).

If we go this route, we'd need to implement user choices persistence #57669

[jameskoster]

I think your first suggestion could work in the short term, if we feel there's an urgent need to address this. Otherwise I agree that making the 'primary' status of an action part of the config (and user-editable) could be a nice enhancement.

[oandregal]

I think your first suggestion could work in the short term, if we feel there's an urgent need to address this. Otherwise I agree that making the 'primary' status of an action part of the config (and user-editable) could be a nice enhancement.

It doesn't seem urgent because extensibility hasn't yet landed in WordPress core (not part of 6.7 either): 3rd parties are only able to register new actions if the Gutenberg plugin is active.

[jameskoster]

Some additional considerations for the design:

• Primary actions are all displayed in table layout
• In List layout only a single primary action is displayed; how do we manage this?
• In Grid layout no primary actions are displayed

If we make this user-configurable the options would likely need to adapt based on the chosen layout.