[wp-trac] [WordPress Trac] #64393: Change how we include Gutenberg in Core

Tue Feb 24 20:50:28 UTC 2026

#64393: Change how we include Gutenberg in Core
------------------------------+--------------------------
 Reporter:  youknowriad       |       Owner:  youknowriad
     Type:  task (blessed)    |      Status:  reopened
 Priority:  high              |   Milestone:  7.0
Component:  Build/Test Tools  |     Version:
 Severity:  blocker           |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+--------------------------

Comment (by desrosj):

 Replying to [comment:158 youknowriad]:
 >  If you think about this from how WP has always been organized, I'd
 agree with you but the important bit here is that we're introducing the
 idea of a build tool that generates code for us and for the ideal DevX we
 shouldn't care where the files are added or organized at all. The
 important part is that we should be able to load build/build.php and
 that's all we need for our routes, scripts, modules (and more later) to be
 registered properly at the right moment, with the right performance...
 Removing all boilerplate and often hard to pick integration points.
 >
 So moving some parts of the build to a folder, and another to another
 folder is IMO the wrong solution, I wouldn't mind moving the build folder
 to src/wp-build or something but that feels like a bigger departure. We
 can think of this folder as the "includes" necessary to build and register
 WP-Admin pages but not necessary the admin pages themselves. The font-
 library.php file is still outside and it calls these includes.
 >

 Who is we in this part of your response? And where was this discussed
 before hand? Can you share who was involved when it was agreed that
 changing how WP is organized is the correct way forward after considering
 all of the requirements and historical context?

 This is a very significant divergence from how WP has been organized for
 15-20+ years now. It also seems to circumvent several well established
 patterns and expectations that plugin developers and the extender
 community have.

 I want to understand this more so I can support it, but I don't know where
 to look for more information.

 > > Next new concern I have is the way that scripts and styles are being
 registered and enqueued. In wp_font_library_wp_admin_enqueue_scripts(),
 the function returns early if the current page is not the expected font
 library. This means that WordPress is not always aware of the fact that
 the related scripts and styles are available.
 >
 > This is wrong, the scripts are always registered, they are only
 "enqueued" on the required pages.

 Can you help me understand where they are registered?

 I
 [https://github.com/WordPress/gutenberg/blob/252fdf490b564a7a1bf579909ec03667de9d2486/packages
 /wp-build/templates/page-wp-admin.php.template#L135-L144 see these lines
 returning early], and the only instance of `wp_register_script( 'font-
 library-wp-admin-prerequisites' )`/ `wp_register_script( 'site-editor-v2
 -wp-admin-prerequisites' )` after this conditional.

 Based on this template and the resulting PHP file, I don't think that
 these assets are always registered, only enqueued when needed.

 > I'd love to have had help in Gutenberg when I was working on this but
 didn't get enough support at that point.

 I'm sorry you felt unsupported while working on this. That said, I don't
 recall seeing any posts on Make Core asking for feedback or review, no
 outline of the challenges this was trying to solve, the goals it was
 trying to accomplish, or requests for help in `#core` during or outside of
 Dev Chat. With the volume of work happening across the project, it's
 genuinely impossible for people to monitor everything, so the right people
 often won't know help is needed unless it's explicitly and loudly asked
 for.

 These extra steps do take more time upfront, but actively seeking
 consensus and building wider awareness pays off greatly in the long run.

 ----

 To be transparent: I've found it difficult to get some of the concerns
 raised here, by multiple committers and respected community members, taken
 seriously, and that's been discouraging. Concerns don't need to be
 universally shared to deserve fair consideration, and everyone involved
 should at least feel heard.

 Based on the responses here, it seems many of the changes in this ticket
 are intentional and meant to shift some well-established expectations and
 practices. That's okay! The project should adapt when it needs to. But for
 that kind of change to succeed, the process needs to be collaborative
 process from the start.

 My primary frustration isn't with any one specific aspect of these
 changes. It's with the process and the lack of opportunity to participate
 early enough to have a meaningful impact. Some of that appears to be a
 visibility problem. There wasn't wide awareness that this type of change
 was being worked on, and that was compounded by some unfortunate timing.

 Collaboration did happen here, and I appreciate that. But it started too
 late, after the overall approach was already complete. Engagement at the
 proposal-to-trunk stage leaves very little room to course-correct, and
 that makes the process feel stressful for everyone. This isn't unique to
 this change. It's a pattern the project has been working around for years,
 and it's worth addressing directly. I also recognize that this is a piece
 of the puzzle to address that.

 ----

 Historical continuity of the code base is very important, especially when
 looking back at past changes to understand the reasoning and rationale
 many years in the future. Many of the established processes are
 intentionally a certain way to ensure specific problems don't occur.
 Breaks in this continuity not only makes it more difficult for current
 contributors, but also makes it harder and more confusing to get involved
 contributing. With the [https://wordpress.org/education/credits/ WP
 Credits program], the latter part is especially important. The project
 needs more contributors, and it's very important to me that it remains
 easy to learn about the project's past in order to contribute in a well-
 informed way.

 ----

 Replying to [comment:166 youknowriad]
 (this response came in after I typed the above).

 > I understand and I agree. The reality is any change can break something,
 I hope that I've shown in this ticket that I've followed and fixed all of
 what has been raised.
 >
 > Also I have to say that I have been working almost solo on this for
 months and it's depressing to be met with only resistance to chance and
 not support and openness to what this unlocks. It is totally possible that
 I'm not receiving this the way I should be, but the reactions are all
 about "protecting" and less about thinking about achieving the vision.
 This is not encouraging at all to keep pushing the boundaries of
 possibilities of WordPress, we'll just be protecting our "fields" and
 leaving progress for others.

 Thank you for all the work you've done on this, both initially and in
 following up to address feedback.

 Everyone here is trying to make WordPress better. It's healthy to disagree
 about what that means or how to get there, and everyone should feel heard
 and understood in that process.

 I've tried to be intentional in my feedback by detailing what is broken
 and why it matters, with as much surrounding context as I can provide.
 While I've shared my opinions throughout based on my understanding and the
 information available, I hope nothing came across as directed at any one
 person or as though I'm unwilling to change my mind.

 I genuinely agree with the vision of reducing friction between the two
 code bases as much as possible. It frees up significant contributor time,
 and I'm participating here because I want to support that and arrive at a
 solution that's as maintainable as possible for the next 5 to 10 years. I
 also don't disagree with the broader vision of a process that handles
 things for contributors automatically.

 Where I'm currently stuck is the implementation as it stands. The
 cumulative impact of the known concerns so far is tipping the scales in
 the wrong direction, and I think we can do better, for the sake of our
 current and future selves.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64393#comment:167>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform