EditMenuItems & BeforeDocumentControls: props.id shown in examples but not provided

[mulfyx]

Documentation Issue

Summary
The official docs examples for admin edit-view custom components (notably EditMenuItems) show usage of props.id (the document id) inside server components, but in the codebase the serverProps passed to admin custom components do not include an id (both the TypeScript types and runtime construction lack it). As a result props.id is undefined at runtime and the docs are misleading.
Note: BeforeDocumentControls shows the same problem — its docs/examples also imply access to props.id, but the server props do not provide it.

---

Additional Details

Reproduction steps

1. Create an EditMenuItems server component using the docs example that references props.id, for example:

import React from 'react'
import { PopupList } from '@payloadcms/ui'

import type { EditMenuItemsServerProps } from 'payload'

export const EditMenuItems = async (props: EditMenuItemsServerProps) => {
  const href = `/custom-action?id=${props.id}` // expects props.id

  return (
    <PopupList.ButtonGroup>
      <PopupList.Button href={href}>Custom Edit Menu Item</PopupList.Button>
      <PopupList.Button href={href}>
        Another Custom Edit Menu Item - add as many as you need!
      </PopupList.Button>
    </PopupList.ButtonGroup>
  )
}

2. Register this component in a collection config as admin.components.edit.editMenuItems.
3. Open the document edit page in the admin UI.

(Repeat the analogous steps for BeforeDocumentControls using its docs example.)

Observed behavior (actual)

• props.id is undefined at runtime for EditMenuItems (and likewise for BeforeDocumentControls when following the docs).
• The TypeScript types for EditMenuItemsServerProps (and the corresponding types used for BeforeDocumentControls) do not include an id field.
• The serverProps object that is passed to these components at render time (in renderDocumentSlots.tsx) does not contain the document id.
• Current consumer workaround: read the id from window.location on the client side (fragile and not server-render-friendly).

Expected behavior (documentation / expectation)

• The docs examples imply that the document id is available on server component props (props.id). The actual codebase does not provide this value in serverProps. Documentation and runtime/types should match so examples are accurate and not misleading.

Evidence / references (from official docs & repo inspected)

• Docs example referencing props.id for EditMenuItems:
  https://payloadcms.com/docs/custom-components/edit-view#editmenuitems

• EditMenuItems element / types (no id in props):
  https://github.com/payloadcms/payload/blob/9c8f3202e4130fe70f7b18a1e66ac2d37d04a992/packages/payload/src/admin/elements/EditMenuItems.ts

• Where server props are constructed and passed to custom components (no id included):
  https://github.com/payloadcms/payload/blob/9c8f3202e4130fe70f7b18a1e66ac2d37d04a992/packages/next/src/views/Document/renderDocumentSlots.tsx

• Note: BeforeDocumentControls exhibits the same docs vs. runtime mismatch (docs/examples reference props.id, but serverProps passed at render time do not include id).

Workaround currently used by consumers

• Parse window.location on the client to extract the document id from the URL path/query.