Thoughts on the WordPress Network Admin Redesign

Thoughts on the WordPress Network Admin Redesign 🔗 **Source:** [Thoughts on the WordPress Network Admin Redesign](https://ploetner.io/thoughts-on-wordpress-network-admin-redesign/) > [!note]+ Document Notes > tags: [WordPress, Multisite, Admin-UX] > author: realloc > source: ploetner.io > reference: [https://ploetner.io/thoughts-on-wordpress-network-admin-redesign/] > date created: 2025-10-07 00:00 > > # 🏷️ Title: Thoughts on the WordPress Network Admin Redesign >  ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Include links cited in or relevant to the article. ## 📝 Summary - What happened: The author proposes modernizing WordPress Network Admin using React-based DataViews and DataForm, backed by REST API endpoints, with MultiSyde as a proof-of-concept bridge. - Why it matters: Classic list screens (WP_List_Table) limit extensibility and consistency versus the Site Editor; Multisite particularly needs updated UI and APIs. - Key stakeholders: WordPress Core/Gutenberg teams, Multisite admins, plugin/theme authors, agencies. - Risks and tradeoffs: API–UI stalemate; feature-plugin drift; migration complexity; fragmented efforts without Core alignment. - Bottom line: Invest in REST endpoints and adopt DataViews/DataForm to unify admin UX; use MultiSyde to de-risk and inform Core. ## 📖 Main Content - Core arguments: - Legacy problem: “They still rely on an outdated technical foundation that is difficult to extend.” - Modern foundation: DataViews/DataForm can unify data display/editing if REST endpoints exist for network-level data. - Dependency loop: UI components need APIs; APIs lack urgency without UI—producing a stalemate. - Bridge approach: MultiSyde demonstrates feasibility and can incubate features toward Core. - Alignment: This fits Gutenberg Phase 3’s admin redesign goals. - Context/definitions: - WP_List_Table: PHP list table utility with limited extensibility. - DataViews/DataForm: React components from Gutenberg for listing/editing entities. - Multisite/Network Admin: WordPress setup managing multiple sites from a central dashboard. - Feature plugin: Experimental plugin path for shipping Core features. - Uncertainties: - Scope and timeline of missing REST endpoints. - Path to Core inclusion and long-term maintenance of MultiSyde. ### 🗒️ Notes - “At first glance, the WordPress Admin Dashboard feels a bit outdated.” - “Classic management screens… have remained almost unchanged for a long time.” - “We do not need more workarounds for legacy code but a modern, extensible foundation.” - “DataViews and DataForm provide a unified interface… require a reliable data source: the REST API.” - “A classic chicken-and-egg problem… new components are meant to become the standard, but some required REST endpoints are not yet available.” - “The missing endpoints do exist in a… feature plugin… last commit… more than six years ago.” - “MultiSyde… includes a proof of concept… an experimental space to test ideas and prove their feasibility.” - “These ideas align with… Phase 3 of the Gutenberg project… redesigning the admin dashboard.” ## 📚 References - Gutenberg Phase 3: Admin redesign goals (Core blog): https://make.wordpress.org/core/2023/08/24/phase-3-plans/ - WP_List_Table (developer note): https://developer.wordpress.org/reference/classes/wp_list_table/ - WordPress REST API handbook: https://developer.wordpress.org/rest-api/ - Multisite overview: https://wordpress.org/documentation/article/create-a-network/ - DataViews tracking (Gutenberg): https://github.com/WordPress/gutenberg/labels/DataViews ## 🗣️ Paraphrase - Paragraph A: WordPress admin feels dated; modern Site Editor contrasts with unchanged list screens, revealing a patchwork and technical limits. - Paragraph B: Replace WP_List_Table-era lists with DataViews/DataForm backed by robust REST endpoints, especially for Multisite data. ## 📰 Newsletter - WordPress is edging toward a unified admin UX. This piece argues for DataViews/DataForm plus stronger REST coverage to lift Multisite out of WP_List_Table constraints. Watch Gutenberg Phase 3’s admin redesign, and test emerging patterns in proofs like MultiSyde. Resources: Gutenberg’s DataViews label, REST API docs, and Multisite guides. Agencies and plugin authors: start mapping your list screens to REST and prototype with DataViews to prepare for Core shifts. ## ✅ Action Items #### DevRel - Publish example repos: DataViews-based list screens for posts, sites, users. - Run office hours on migrating from WP_List_Table to REST+DataViews. - Add SDK snippets for common filters/sorts/bulk actions. #### OSPO - Define contribution pathway for missing REST endpoints. - Establish API review cadence and deprecation policy for legacy screens. - Track feature-plugin health to avoid abandonment. #### Community - Host contributor sprints to add network REST endpoints. - Maintain “first issue” tasks around DataViews adoption. - Share case studies from Multisite admins. #### WordPress - Core: prioritize REST endpoints for network sites/users/themes/plugins. - Core Performance: set list-render KPIs for DataViews. - Core AI: evaluate admin-assist use cases after UI foundation stabilizes. - Core Program Team: coordinate Gutenberg/Core milestones for Phase 3. - Playground: provide DataViews sandboxes with seed Multisites. - Documentation: migration guides from WP_List_Table to DataViews. - Accessibility: audit DataViews patterns for WCAG 2.2 AA. - Meta: ensure .org API reliability for developer docs. #### The WPOCC - Fund microgrants for endpoint implementations and audits. - Sponsor MultiSyde-style incubations with milestone payouts. ### FAIR - Require provenance and signatures for feature-plugin releases. - Publish charters and exit-to-Core criteria for incubations. ## 🧪 Hypotheses - Adopting DataViews reduces custom admin list code by ≥30%. - Network REST endpoints cut average Multisite admin task time by ≥25%. - Accessibility scores improve when list screens move to standardized components. - Agencies adopt upgrades faster when a maintained bridge plugin exists. ### 📊 Methodology - A/B study: WP_List_Table vs DataViews task completion/time/UX. - Performance: TTI/interaction latency under typical list sizes. - Accessibility: WCAG 2.2 AA audits on representative screens. - Adoption: survey agencies/plugins pre/post migration guides. ### ❓ Questions - Which network endpoints are blockers for parity with classic lists? - What is the minimal viable DataViews API for bulk actions? - How to phase deprecations without breaking admin workflows? ### 🔮 Future Research - Schema for composable filters across entities. - Offline-capable admin actions with conflict resolution. - Versioned admin UI contracts for plugin compatibility. ### 💡 Implications - Practice: faster, consistent admin tooling. - Policy: clearer Core inclusion criteria for incubations. - Security: uniform permission checks via REST middleware. - Education: migration playbooks for agencies. ### 🧠 Learning Styles Assessment - Reading level: Flesch-Kincaid Grade ≈ 10–11. #### 👀 Visual learners - Present: comparative screen descriptions. - Improve: before/after DataViews diagrams and flows. #### 🔊 Aural learners - Improve: 3-minute audio summary. #### 🗣️ Verbal learners - Present: clear definitions of components. - Improve: glossary for DataViews/DataForm terms. #### 🧩 Kinesthetic learners - Improve: Playground labs to rebuild a Sites list. #### 🧠 Logical learners - Present: problem→foundation→bridge structure. - Improve: decision trees for migration paths. #### 🧑‍🤝‍🧑 Social learners - Improve: cohort-based migration clinics. #### 🧘‍♀️ Solitary learners - Improve: self-check quizzes on REST coverage. #### 🌿 Naturalistic learners - Improve: lifecycle maps for feature-plugin to Core. ### 📊 Accessibility Assessment #### Screen reader semantics - Improve: standardized landmarks in DataViews templates. #### Keyboard navigation - Improve: bulk action focus order and skip links. #### Contrast and readability - Improve: enforce 4.5:1 in redesigned lists. #### Text resizing and reflow - Improve: verify 200% zoom in dense tables. #### Media and captions - Improve: add captions to demo videos. #### Forms and interactions - Improve: inline validation and ARIA-live toasts. #### Standards reference - Map to WCAG 2.2 AA: 1.4.*, 2.1.*, 3.3.*, 4.1.* ### 🌍 DEIB Assessment #### Cultural breadth - Improve: global Multisite use cases and translations. #### Inclusive language - Present: neutral tone; low jargon. - Improve: plain-language callouts. #### Neurodiversity support - Improve: predictable patterns and icon+text labels. #### Representation - Improve: inclusive imagery and balanced quotes. #### Psychological safety - Improve: contribution guidelines and escalation paths. ### ✅ Logical Validity #### Strong reasoning - Causal: Legacy limits → need modern foundation; supported by contrasts with Site Editor. - Inductive: Feature-plugin stagnation → risk without renewed ownership. #### Fallacies - None evident; claims are scoped to feasibility and alignment. #### Tone of voice - Constructive and practical; aligned with Core roadmap. ### 🛡️ DARVO Analysis - No denial/attack patterns; the piece is collaborative and solution-focused. ## 🎯 Conclusion - Bottom line: Modernize Network Admin via REST-backed DataViews/DataForm; use MultiSyde to break the API–UI stalemate while aligning with Gutenberg Phase 3. - Next steps: Identify missing network REST endpoints, prototype key screens with DataViews, and document migration patterns. ## 🧱 Refactor Appendix (append after 🎯 Conclusion) ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: H3. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] 5–10-word present-tense claim > [!quote] [Thoughts on the WordPress Network Admin Redesign](https://ploetner.io/thoughts-on-wordpress-network-admin-redesign/) by [[realloc]] via [[ploetner.io]]. Published 2025-10-04. Accessed 2025-10-07. > “Classic management screens need a modern, consistent foundation.” Two lines: context and use. Cite data if relevant. [view highlight](https://ploetner.io/thoughts-on-wordpress-network-admin-redesign/#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] 5–10-word present-tense claim > [!quote] [Thoughts on the WordPress Network Admin Redesign](https://ploetner.io/thoughts-on-wordpress-network-admin-redesign/) > “DataViews and DataForm require reliable REST endpoints.” Two lines: context and use. [view highlight](https://ploetner.io/thoughts-on-wordpress-network-admin-redesign/#H2) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) #### [Z1] DataViews standardize admin data lists - Applies to WordPress admin contexts. - Pointer: Article section on DataViews/DataForm. - Links: [[Gutenberg]] [[Admin-UX]] #### [Z2] Network REST endpoints unblock Multisite UX - Applies to network sites/users/themes/plugins. - Pointer: Article notes on missing endpoints. - Links: [[REST-API]] [[Multisite]] --- ### ✏️ Fleeting Queue (Extract by Selection) - [F1] Inventory missing network REST endpoints — context/https://ploetner.io/thoughts-on-wordpress-network-admin-redesign/ #fleeting #inbox - [F2] Prototype Sites list with DataViews — context/https://ploetner.io/thoughts-on-wordpress-network-admin-redesign/ #fleeting #inbox - [F3] Draft migration guide WP_List_Table → DataViews — context/https://ploetner.io/thoughts-on-wordpress-network-admin-redesign/ #fleeting #inbox ---