At first glance, the WordPress Admin Dashboard feels a bit outdated. The overall structure with the left-hand navigation and the top admin bar has hardly changed for many years. Admittedly, there have been major updates that have shaped how we work in the dashboard: visual refreshes, the introduction of the block editor, and later the expansion of the block philosophy to the entire site design.
Maybe for that very reason, the WordPress backend sometimes feels like a patchwork. This becomes especially clear when comparing the modern Site Editor with the classic management screens, such as the lists of posts, pages, users, or, in the Multisite context, sites, plugins, and themes. These areas have remained almost unchanged for a long time.
They still rely on an outdated technical foundation that is difficult to extend and whose limitations are becoming more and more apparent.
That is where my discussion begins. For my Multisite presentation at WordCamp US 2025 in Portland (OR), I explored the challenges and opportunities around this topic. With new components such as DataViews and DataForm, we finally have a modern foundation to make these interfaces more consistent, flexible, and user-friendly, especially in the Network Admin Dashboard.
The list-based management screens in WordPress still rely on the PHP class WP_List_Table. It has been stable over the years, but offers very limited possibilities for extension. This raises the question: Does it still make sense to open tickets aimed at improving these old admin lists? In the long run, we do not need more workarounds for legacy code but a modern, extensible foundation for all admin screens.
DataViews and DataForm provide a unified interface for displaying and editing data. To use them effectively, they require a reliable data source: the REST API. For standard post and taxonomy lists, the REST API already covers most use cases. But for Multisite and network-level screens, important endpoints are still missing. Further development of the REST API is therefore a crucial prerequisite.
At this point, a classic chicken-and-egg problem appears. In WordPress Core, these new components are meant to become the standard, but some required REST endpoints are not yet available. In the Gutenberg project, they are already being tested, but only within the context of the block editor, not in the Network Admin. And Multisite urgently needs modernized screens, but cannot start without these new React-based components.
The result is a stalemate: the API and the interface depend on each other. In fact, the missing endpoints do exist in a so-called feature plugin, but the last commit to that repository was more than six years ago. The lack of perceived urgency (or perhaps the small number of people affected) has not helped the project move forward. This is where the MultiSyde plugin might help. It includes a proof of concept that demonstrates how some of these ideas could work in practice.
That makes MultiSyde the kind of bridge my colleagues at the WordPress agency Syde and I envisioned at the beginning of the project, an experimental space to test ideas and prove their feasibility. The insights gained from this can help define realistic Core features. It is also conceivable that MultiSyde could serve as an incubator in the medium term, helping certain functionalities find their way into Core later on.
It is also important to emphasize that none of this goes against the official WordPress roadmap, quite the opposite.
These ideas align with the stated goals of Phase 3 of the Gutenberg project, which focuses on redesigning the admin dashboard. In the related post on the Core blog, it is clearly stated that the classic management screens need a modern, consistent foundation. In that sense, DataViews and DataForm are not side projects but key building blocks of that vision, and particularly relevant in the Multisite context.
2 thoughts on “Thoughts on the WordPress Network Admin Redesign”