티스토리 수익 글 보기

The Role

In the WordPress open-source project, each team has on average one or two representatives, abbreviated as reps. For the historians out there, the role go way back to 2012.

Historically with the Core team, the team rep duration was around a year, though some reps stuck around longer if there was a specific need.

Anyone who serves as a team rep is responsible for communicating on behalf of the Core team to the other contributor groups via weekly updates, as well as occasional cross-team chats. Reps are also consulted on Contributor Day, where they help to find someone within the Core team who will be at an event who can lead a Core table. Full details on the Team Rep role can be found on the Team Update site.

It is not called team lead for a reason.  It’s an administrative role. While people elected as team reps will generally come from the pool of folks that people think of as experienced leaders, the team rep role is designed to change hands regularly.

This role has a time commitment of at least one or two hours a week.

The main tasks include:

• Posting the weekly Dev Chat agenda, hosting the chats, and summarizing them (which can include writing and encouraging others to contribute to the summaries). More details on coordinating devchat are available in the Core handbook.
• Keeping up with the current releases (mainly WordPress major and minors and Gutenberg bi-weekly releases) and communicating updates.
• Keeping a watch on the moving parts of the team to report for quarterly updates (example).

How the election works

Please nominate people in the comments of this post. Self-nominations are welcome. The deadline is January 31, 2026 at 23:59 UTC. If there are fewer than 2 nominees who have accepted their nominations, the deadline will be extended.

Once the nomination period expires, a poll will be opened for voting. It will stay open for two weeks. The new reps will start their role in February 2026.

Disclaimer: if you are nominated, please don’t feel like you have to agree to say yes. The election poll will only include the names of the people who have agreed to be nominated. So feel free to reply with a “Thank you, but no thank you”.

If you have any questions, please feel free to ask in the comments or speak to the current team reps. Finally, for reference, these are the 2020, 2021, 2022, 2023, 2024, 2025 nomination posts.

Thanks to @francina for reviewing this post.

#team-reps

How to interact with this post

Please do not use this as a spot to request folks to work on features. GitHub and Trac are the best places to share feedback, talk about impact, and advocate for issues. 

Please use this post to share what you are working on, including areas you’d like to help with that may be listed here, as well as areas that you are working on that are not. Items with TBD indicate areas where contributors are needed so please comment below if you’re keen to work on those pieces.

If you were planning to work in an area listed below and don’t see your name, please be sure to comment as well and it’ll be updated. It’s intentional that this post is meant to be a place to shore up who is working on what out in the open at this early stage.

Also note this is neither comprehensive nor yet a commitment that all of these things will be part of 7.0, since many are in early stages and may not make this release. Items marked with mean the work is already merged in Gutenberg or trunk.

Collaboration 

The project is getting deeper into Phase 3: Collaboration. Notes was a highlight feature in WP6.9 and there’s several improvements already planned to make it even more powerful and resilient.

Real time collaboration

• Link: GitHub issue
• Key considerations:
  • There’s been a lot of progress in defining the UI and the diffing mechanics for reconciling changes. It’s in very good shape and needs to be reviewed and tested diligently, especially around compatibility with third-party blocks and plugins.
  • This feature has a stronger dependency on server support and infrastructure than usual WordPress features, so there needs to be a definition of what’s the baseline experience shipping in WordPress (for example, peer-to-peer with 1 or 2 connections) and how it can be augmented, either by WP.org, hosting providers, or plugins.
• Contributors: @acicovic, @aduth, @alecgeatches, @czarate, @ingeniumed, @jsnajdr, @maxschmelingkc, @paulkevan, @shekharnwagh, @youknowriad

Notes i2

• Link: GitHub issue
• Key considerations:
  • Support partial selection inside block rich text fields.
  • A “suggestions” mode and interface that allows Notes to refer to specific content within a block and apply the suggestions.
  • Support for multi-block notes.
  • Add rich text support in the comments.
  • Develop a dashboard widget for recent notes.
  • More notification options (responses, follow a note, mentions).
• Contributors: @adamsilverstein, @jeffpaul, @mamaduka 

Admin

Improving screens across wp-admin

• Link: TBD
• Key considerations:
  • Explore CSS improvements that can modernize the look and feel. For example, consider making the “modern” admin color scheme the default.
  • Admin bar and editor “site hub” improvements. Make the W menu item filterable. Possibly start work as an experiment in Gutenberg.
  • Consider a “This time last year” widget for bloggers.
  • Bring grid layout customization to dashboard experience or other screens. (Possible widgets at the top of comments, etc).
• Contributors: TBD, @fabiankaegy, @karmatosed, @mcsf

DataViews and DataForms iterations

• Link: 7.0 iteration issue
• Key considerations:
  • DataForms/QuickEdit/Document inspector design iterations.
  • Hierarchical post visualization.
  • Make DataViews screens extensible in the site editor (templates, pages, etc).
• Contributors: @oandregal

Design System

• Link: GitHub issue
• Key considerations:
  • Components are already being worked on in wordpress/ui.
  • Theming system with design tokens using wordpress/theme.
  • Start replacing key parts of the editor UI with improved components (tabs, flyout menus).
• Contributors: @0mirka00, @aduth, @jsnajdr, @mciampini, @wildworks

Font library admin section

• Link: Github issue
• Key considerations:
  • Support for block themes.
  • Support for hybrid/classic themes.
• Contributors: @youknowriad

Revisions 

• Link: GitHub issue
• Key tasks:
  • Rethink the revisions interface to be more modern, intuitive, and work with blocks.
  • Show visual diffs. 
  • Bonus: potentially tie in with collaborative editing, suggestions, and undo management.
• Contributors: @adamsilverstein

Customizable Keyboard Shortcuts

• Link: Github issue
• Key considerations:
  • Build with design system components.
• Contributors: TBD

APIs

Abilities & Workflows API

• Link: Github issue
• Key considerations:
  • Hybrid abilities.
  • The client side package.
  • Driven by Fields API definitions. 
  • Querying and filtering functionality for the abilities.
  • Implement some of the abilities outlined in WordPress Core Abilities.
  • Command palette and UI:
    • Differentiation between commands.
    • Ability to support two stages of a command.
• Contributors: @jorgefilipecosta @gziolo @senadir @youknowriad

Upgrade to React 19

• Link: Github issue
• Key considerations:
  • There’s a path for the block editor in the mobile apps that should remove this dependency blocker.
  • Ecosystem impact.
• Contributors: @aduth @jsnajdr @mamaduka @ralucastn @tyxla

Block API: Add validation levels

• Links: Github issue with initial PR 
• Key considerations:
  • The scope of this issue is to drastically reduce the amount of times a user sees a “this block is broken” message.
  • Impact on block API.
• Contributors: @matveb @mcsf @youknowriad

Enforced iframed editor

• Link: GitHub issue.
  • Backwards compatibility, extended testing.
  • Migration guide.
• Contributors: @ellatrix, @wildworks

WP client AI API

• Link: GitHub project
• Key considerations:
  • An AI client and API for WordPress to communicate with any generative AI models of various capabilities using a uniform API.
  • Integration with Abilities API.
  • Strictly no providers included in core.
  • Decide nomenclature.
  • Ideally, the minimum PHP version has to be bumped from PHP 7.2.
• Contributors: @flixos90 @jason_the_adams

Creating blocks and patterns on the server

• Link: GitHub issue
• Key considerations:
  • Most of the tools for a pretty straightforward PHP-only representation of blocks and patterns, including bindings, are ready.
  • Declarative block attributes and form components.
  • Pattern creation and syntax that allows easy construction of blocks and bindings.
• Contributors: @priethor, TBD

wordpress/build and routing (site editor)

• Link: GitHub issue; Scripts issue
• Key considerations.
  • Add extensibility to site editor routing.
  • Dependency on standalone font library.
  • Refactor the site editor to allow plugin authors to add their pages there.
  • Opinionated build tool for plugins.
  • Update Gutenberg – Core backport flow.
• Contributors: @youknowriad 

Shortblocks

• Links: Bits as dynamic tokens; Bits: Introduce the ability to store and render bits, Rich text: try BITS with block binding API, Introduce parser for dynamic token system.
• Key considerations:
  • Decide name for the feature (shortblocks, inline blocks, bits).
  • Determine best syntax.
  • Connect with bindings UI.
  • Support for rich text autocomplete.
• Contributors: @dmsnell, @ellatrix, @jonsurrell

Block bindings iterations

• Link: GitHub issue
• Key considerations:
  • Open up “Pattern Overrides” and therefore intern block bindings to custom dynamic blocks.
  • Filter available source items for a given attribute by format.
  • Align with Fields API as a requirement. 
• Contributors: @bernhard-reiter

Navigation Block

A series of improvements were identified to simplify the navigation workflow and make the experience of managing menus more intuitive and straightforward.

Simpler navigation editing

• Link: GitHub issue
• Key considerations:
  • Better insertion.
  • Pattern editing and ContentOnly interactivity.
  • Better presentation of “bound” page items.
• Contributors: @get_dave, @jeryj

Ability to customise “mobile” overlay 

• Link: GitHub issue
• Key considerations:
  • Implemented as a template part.
  • Ability to customize when the overlay appears (breakpoint settings) just for navigation overlay.
• Contributors: @get_dave, @jeryj

Customization

Over the past couple years we’ve been iterating on a series of related systems with the hope of arriving at a more streamlined editing experience of composite blocks and design patterns. We have some solid directions sketched out that are looking promising.

Explore more intuitive page navigation in the site editor

• Link: TBD
• Key considerations:
  • Modify the title bar to display a pages dropdown instead of empty command palette. List the pages used in the primary menu with a link to “browse all pages”. Exploration.
  • Add next/previous page links in zoomed-out view, similar to a carousel. See a preview in a zoomed out state with arrows next to preview or title bar. Exploration.
• Contributors: @ellatrix

Pattern Editing (aka ContentOnly)

• Link: GitHub issue
• Key considerations:
  • Ensure proper discoverability to enter/exit.
  • Ensure it works well with synced patterns. 
• Contributors: @aaronrobertshaw, @andrewserong, @isabel_brison, @ramonopoly @talldanwp. 

Improve template management

• Link: GitHub PR
• Key considerations:
  • Direction and UX is still TBD and needs more exploration.
  • Retain access to template parts across theme switches.
• Contributors: @ellatrix @scruffian.

Responsive editing mode

• Link: GitHub issue
• Key considerations:
  • Toggle to engage responsive editing mode.
  • Block visibility i2: add ability to hide blocks based on screen size.
  • Allow style changes to be saved and retrieved for different breakpoints.
  • Allow customization of hardcoded breakpoints.
• Contributors: @matveb @ramonopoly

Block supports and design tools:  

• Link: GitHub issue
• Key considerations:
  • Add text line indent support. GitHub PR.
  • Add gradient support to text color options.
  • Add height block support to dimension .
  • Styles support for text shadow. GitHub PR.
  • Support for text alignment with justify support.
  • Allow Video backgrounds to be ‘Fixed’.
  • Balanced line wrap.
  • Text columns. GitHub issue; GitHub issue.
  • Support aspect ratio on wide and full images.
• Contributors: TBD, @aaronrobertshaw @matveb @youknowriad @wildworks

Blocks

Keeping the momentum on adding new blocks and new block tools to expand the palette and expressiveness offered to theme builders and users. There’s also some refinements to some fundamental aspects of blocks to make them more resilient and more consistent.

Group block attributes

• Link: GitHub Issue
• Key considerations:
  • Adding groups to InspectorControls (like BlockControls).
  • Add support for list representation to block API based on nav block work.
  • Implement content representation for media and rich text attributes. (Connected with contentOnly, bindings, and partially synced patterns work.)
• Contributors: TBD

Cover block: video embeds

• Link: GitHub Issue; GitHub PR
• Contributors: @matveb 

Modernize Code editor + Code block

• Link: GitHub link
• Contributors: @jonsurrell, @westonruter 

Lazy load the Classic block

• Link: TBD
• Key considerations:
  • The main aim is performance—avoid loading TinyMCE by default if not needed.
  • If possible, address moving the freeform block to a separate package in this work too.
• Contributors: @tyxla

Leverage iAPI for instant search block & submit comments without full page refresh

• Links: Instant Search, submit comments without requiring a full-page refresh.
• Contributors: TBD

Writing flow + drag and drop improvements

• Link: GitHub issue
• Key considerations:
  • Get to a place where the drag handle from the toolbar can be entirely removed due to improved drag and drop functionality.
  • Making multi selection work on touch devices.
  • Improvements to inline insertion and inline images.
• Contributors: @ellatrix

Tabs block 

• Link: GitHub issue
• Contributors: @mikachan

Release the Table of Contents block 

• Link: GitHub issue
• Contributors: TBD 

Playlist block

• Link: GitHub issue
• Contributors: @scruffian

Slider block

• Link: GitHub issue, GitHub issue, GitHub issue
• Contributors: @lstraczynski, @karolmanijak

Dialog block

• Link: GitHub issue
• Contributors: TBD

Breadcrumb block

• Link: GitHub Issue
• Team: @ntsekouras

Add more dynamic URLs via block bindings to Buttons block and Image block

• Link: GitHub issue, API shape
• Team: TBD

Icon block

• Link: GitHub issue
• Key considerations:
  • Ship with a default set made out of some wordpress/icons.
  • Allow extenders to register their own sets.
• Contributors: @mcsf @welcher

Gallery block: add lightbox support with the ability to switch between images

• Link: GitHub issue, GitHub PR
• Contributor: @wildworks

Introduce heading levels as Heading block variations

• Link: Github issue; https://github.com/WordPress/gutenberg/issues/42181
• Key considerations:
  • Show up in search and slash inserter.
  • Easy toggling in sidebar inspector and transforms.
• Contributor: @matveb

Aim to stabilize grid block

• Link: GitHub issue
• Contributor: @isabel_brison

Media

Client side media work

• Link: GitHub issue 
• Contributors: @adamsilverstein, @ramonopoly

Media editor

• Link: Iteration issue
• Contributors: @aaronrobertshaw, @andrewserong, @isabel_brison, @ramonopoly, @talldanwp

Designers looking across all these projects: @fcoveram, @joen, @jameskoster, @mattmiklic.

#7-0, #phase-3

WordPress 6.9 introduced a fix for adjacent post navigation when posts have identical publication dates. While this resolved a long-standing bug, it inadvertently caused infinite loops in some extensions that modify the get_adjacent_post() WHERE clause.

What Changed in WordPress 6.9

In WordPress 6.9 (Trac #8107), a bug fix landed where next/previous post navigation failed when multiple posts shared identical post_date values. This commonly occurred when bulk-publishing draft posts.

The Technical Change

The get_adjacent_post() function’s WHERE clause was modified to include ID-based comparison as a tiebreaker:

Before (WordPress 6.8 and earlier):

WHERE p.post_date > '2024-01-01 12:00:00' 
  AND p.post_type = 'post'

After (WordPress 6.9):

WHERE (
    p.post_date > '2024-01-01 12:00:00' 
    OR (
      p.post_date = '2024-01-01 12:00:00' 
      AND p.ID > 123
    )
  ) 
  AND p.post_type = 'post'

This ensures deterministic ordering when posts have identical dates, using the post ID as a secondary sort criterion.

Additionally, the ORDER BY clause was updated:

-- Before
ORDER BY p.post_date DESC 
LIMIT 1

-- After  
ORDER BY p.post_date DESC, 
         p.ID DESC 
LIMIT 1

The Problem: Infinite Loops in Some Themes/Plugins

As Trac ticket #64390 documents, some plugins and themes modify adjacent post navigation to change behavior. For example, WooCommerce’s Storefront theme navigates between products instead of regular posts. These plugins use the get_{$adjacent}_post_where filter to replace the current post’s date with a different post’s date.

Here’s what was happening:

1. Plugin hooks into get_previous_post_where filter.
2. Plugin does string replacement: replaces $current_post->post_date with $target_product->post_date.
3. Problem: The new WHERE clause structure includes the post date in TWO places (date comparison AND ID comparison).
4. Simple string replacement modified the date comparison but left the ID comparison unchanged.
5. Query returns the same post repeatedly → infinite loop.

Real-World Example: Storefront Theme

The fix to the WooCommerce Storefront theme illustrates this issue. They had to add special handling for the ID comparison:

// Replace the post date (works as before)
$where = str_replace( $post->post_date, $new->post_date, $where );

// NEW: Also need to replace the ID comparison (WordPress 6.9+)
if ( strpos( $where, 'AND p.ID ' ) !== false ) {
    $search = sprintf( 'AND p.ID %s ', $this->previous ? '<' : '>' );
    $target = $search . $post->ID;
    $replace = $search . $new->ID;
    $where = str_replace( $target, $replace, $where );
}

For Plugin Developers: Detecting and Fixing the Issue

How to Detect If Your Plugin Is Affected

Your plugin is likely affected if it:

1. Uses the get_{$adjacent}_post_where filter.
2. Performs string replacement on post dates in the WHERE clause.
3. Changes which post is considered “adjacent” (like navigating between custom post types instead).

To test if your plugin works correctly with WordPress 6.9:

1. Create 3-4 posts with identical publication dates (bulk publish drafts).
2. Navigate between them using your plugin’s adjacent post functionality.
3. Verify that navigation moves to different posts (not the same post repeatedly).
4. Check for infinite loops or performance issues.

Quick Fix: Handle the ID Comparison

If you’re doing date replacement in the WHERE clause, you also need to handle the ID comparison. There are numerous ways to tie a knot, but the following example is loosely inspired by Storefront’s recent fix.

add_filter( 'get_next_post_where', 'example_custom_adjacent_post_where', 10, 5 );
add_filter( 'get_previous_post_where', 'example_custom_adjacent_post_where', 10, 5 );

function example_custom_adjacent_post_where( $where, $in_same_term, $excluded_terms, $taxonomy, $post ) {

    // IMPORTANT: Replace this with your logic to find the desired adjacent post.
    $adjacent_post = example_find_adjacent_post_function( $post );
	
    if ( $adjacent_post instanceof WP_Post ) {
        // Replace the date comparison.
        $where = str_replace( $post->post_date, $adjacent_post->post_date, $where );

        // Replace the post ID in the comparison.
        $where = preg_replace(
            "/AND p\.ID (<|>) {$post->ID}\)/",
            "AND p.ID $1 {$adjacent_post->ID})",
            $where
        );
    }

    return $where;
}

You could also add a version_compare( $wp_version, '6.9', '>=' ) test if you’d like to support multiple versions.

Important: don’t forget to first test any code on your site, and customize it according to your needs.

Next time

At the time, this was not a known breaking change, and was classed as a bug fix.

However as @jmdodd points out in the ticket, changes to WP_Query, especially SQL changes should be, by default, communicated more widely. Going forward:

1. Reach out to known plugins using the get_{$adjacent}_post_where filter.
2. Include a migration guidance in the 6.9 field guide (as applicable).
3. Test against any known, popular plugins that modify adjacent post queries.

What’s Next and Getting Help

Discussions have started on the ticket about ways to make this more robust in future WordPress versions. If you’re experiencing issues related to this change:

1. Check Trac ticket #64390 for the latest updates.
2. Ask questions in the #core channel on WordPress Slack.
3. Review the original fix PR #10394.

Thank you for your patience and understanding. If you maintain a plugin affected by this change, please update it using the guidance above, and don’t hesitate to reach out if you need assistance.

Thanks to @westonruter @isabel_brison @andrewserong @jmdodd for helping to prepare this post.

#6-9, #dev-notes