Espacios de nombres en el esquema
Haz que todos los tipos e interfaces añadidos al esquema por plugins reciban automáticamente espacios de nombres.
Aplicar espacios de nombres al esquema evita los conflictos de nombres, que ocurren cuando diferentes propietarios (p. ej.: distintos equipos en la empresa, o entre plugins de terceros) utilizan el mismo nombre para un tipo o interfaz.
Por ejemplo, supongamos que la empresa "AwesomeWP" tiene el equipo de Tutoriales y el equipo de Ventas, y ambos crean un tipo Product para el esquema GraphQL de la empresa, produciendo un conflicto.
Aplicando espacios de nombres al esquema, los dos tipos se convertirían automáticamente en AwesomeWPTutorialsProduct y AwesomeWPSalesProduct, evitando el conflicto sin tener que modificar manualmente el esquema, ni hacer que los equipos interactúen entre sí.
Las entidades del modelo de datos de WordPress no llevan espacios de nombres
El modelo de datos de WordPress se considera canónico, y sus tipos de esquema GraphQL (como Post y User) e interfaces (como Commentable y WithMeta) no llevan espacios de nombres.
Aplicar espacios de nombres al esquema en los endpoints
Hay 2 niveles en los que podemos definir si el esquema llevará espacios de nombres o no. Por orden de prioridad:
1. En la configuración del esquema
Aplicar espacios de nombres al esquema para un custom endpoint o persisted query, puede definirse mediante la correspondiente configuración del esquema:

2. Modo por defecto, definido en los Ajustes
Si la configuración del esquema tiene el valor "Default", utilizará el modo definido en los Ajustes:

Visualizar el esquema con espacios de nombres
Utiliza el cliente Voyager para visualizar el esquema con espacios de nombres.
Cuando los espacios de nombres están deshabilitados, el esquema de WordPress se ve así:

Cuando están habilitados, los tipos e interfaces añadidos por plugins llevan espacios de nombres, viéndose así:

Consultar nombres de tipos (no-)namespaced
Una vez habilitados los espacios de nombres, los tipos pueden consultarse utilizando tanto sus nombres con espacios de nombres como sin ellos. Por tanto, solo es necesario editar las consultas que involucran tipos en conflicto, y no todas ellas.
Por ejemplo, si el equipo de Ventas de AwesomeWP también tiene un tipo Discount, una consulta que solicita este nombre de tipo sigue funcionando:
query {
discounts {
...DiscountProps
}
}
fragment DiscountProps on Discount {
price
dateRange
}Solo el tipo en conflicto Product debería actualizarse a AwesomeWPSalesProduct en la consulta, para eliminar cualquier ambigüedad:
query {
products {
...ProductProps
}
}
fragment ProductProps on AwesomeWPSalesProduct {
price
dateRange
}Especificación de GraphQL
Esta funcionalidad no forma parte actualmente de la especificación de GraphQL, pero ha sido solicitada en: