Part of #79231. Related to #83440.
What problem does this address?
The layout is the list of instances the dashboard renders, and once a user has saved it, nothing changes it except for that user.
The default layout filter runs only while the stored layout is empty (lib/experimental/dashboard-widgets/dashboard-layout.php:72-74); there is no other hook, in PHP or in JS.
If a plugin is activated after that and registers its widget types, they appear in the inserter, and nothing tells the user. For a plugin, registering a widget means offering it, not showing it, and a customized dashboard cannot be extended.
Injecting instances on the server is not an option: the layout travels inside the persisted preferences, and any preference change writes the whole blob (packages/preferences/src/store/reducer.ts:61-64), so whatever the server injects becomes the user's layout at the first change.
What is your proposed solution?
Detect types a user hasn't seen and let them decide.
New is registered minus known: the registry the page already carries, minus a per-user list of type names stored next to the layout in the core/dashboard scope, seeded with everything registered at the first visit and grown on every announcement.
The route computes it on each load. A new type is announced in a notice that names its source, with Insert and Ignore; both mark the type as known. Plugins need nothing: registering a type is enough, as it is for the classic dashboard.
Two pieces support it. The registry records which plugin registered a type, so the notice can name it.
A type may declare how it wants to appear, offer by default or auto (inserted and announced with Remove at hand), on WP_Widget_Type, the REST record, and WidgetType; the presence rule for classic boxes (#79237) is decided there.
Tasks
Part of #79231. Related to #83440.
What problem does this address?
The layout is the list of instances the dashboard renders, and once a user has saved it, nothing changes it except for that user.
The default layout filter runs only while the stored layout is empty (
lib/experimental/dashboard-widgets/dashboard-layout.php:72-74); there is no other hook, in PHP or in JS.If a plugin is activated after that and registers its widget types, they appear in the inserter, and nothing tells the user. For a plugin, registering a widget means offering it, not showing it, and a customized dashboard cannot be extended.
Injecting instances on the server is not an option: the layout travels inside the persisted preferences, and any preference change writes the whole blob (
packages/preferences/src/store/reducer.ts:61-64), so whatever the server injects becomes the user's layout at the first change.What is your proposed solution?
Detect types a user hasn't seen and let them decide.
New is registered minus known: the registry the page already carries, minus a per-user list of type names stored next to the layout in the
core/dashboardscope, seeded with everything registered at the first visit and grown on every announcement.The route computes it on each load. A new type is announced in a notice that names its source, with Insert and Ignore; both mark the type as known. Plugins need nothing: registering a type is enough, as it is for the classic dashboard.
Two pieces support it. The registry records which plugin registered a type, so the notice can name it.
A type may declare how it wants to appear,
offerby default orauto(inserted and announced with Remove at hand), onWP_Widget_Type, the REST record, andWidgetType; the presence rule for classic boxes (#79237) is decided there.Tasks
offer/auto) and its application in the route.