[buddypress-trac] [BuddyPress Trac] #9329: Enhancement Request: Add filter hook to `bp_email_get_type_schema()`

[buddypress-trac]

#9329: Enhancement Request: Add filter hook to `bp_email_get_type_schema()`
-------------------------+------------------------------
 Reporter:  indigetal    |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Emails       |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |
-------------------------+------------------------------

Comment (by indigetal):

 Following up on this ticket. BuddyPress already invites extensions to
 register custom emails through `bp_email_get_schema()` and that path works
 well for subject/body content and is how core itself adds emails on
 upgrade. However, the matching type metadata (admin descriptions, named
 salutation, unsubscribe settings) lives in `bp_email_get_type_schema()`,
 which today is not filterable.

 In practice, that split means many community features can add a new email
 type and get the post created, but the type never shows up fully in admin:
 term descriptions stay empty after install or “Reinstall Emails,”
 salutation/unsubscribe metadata is missing from enumeration, and each
 plugin ends up with its own workaround. That is confusing for site admins
 and brittle for anyone building notifications for groups, messages,
 memberships, or other components on top of BuddyPress.

 `9329.patch` adds the same filter pattern core already uses for email
 content: one hook, no behavior change unless something uses it. The goal
 is parity so plugins can register a complete email type in one place, and
 tools like reinstall/admin lists see the same types users actually
 receive.

 That shared extension point would make it easier for the ecosystem to
 ship, in a consistent way:

 * New notification emails with clear labels and descriptions in the Emails
 admin UI
 * Unsubscribe flows and preference copy that stay aligned with each custom
 type
 * Safer upgrades and reinstalls when plugins add email types alongside
 core’s own schema updates

 Core would still own the default email catalog. Extensions would only add
 or adjust types they need. The patch is attached whenever review fits your
 schedule.

 Thanks for considering it.

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/9329#comment:2>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac