Improve extension email template placeholders

[Arafat-plugins]

PR Type

What kind of change does this PR introduce?

• Bugfix
• Security fix
• Improvement
• New Feature
• Refactoring (no functional changes, no api changes)
• Build related changes
• Text changes
• Other... Please describe:

Description

How to reproduce the issue or how to test the changes

This updates the redesigned Directorist notification editor so extension-provided email template events can expose explicit per-event placeholders.

Pricing Plans registers package/subscription email template sections through the existing atbdp_email_templates_settings_sections filter. The editor must use explicit placeholder metadata from those extension events instead of combining a shared/global placeholder list with placeholders scraped from field descriptions/default values.

Changes included:

• Reads explicit placeholder metadata from extension template sections/fields: placeholders, template_placeholders, supported_placeholders, and supportedPlaceholders.
• For extension template-only events, shows only the placeholders declared for that event.
• Stops falling back to the global core placeholder list for extension template-only events.
• Keeps the existing fallback behavior for non-extension/core notification events.
• Updates the compiled legacy settings manager bundle used by the admin UI.

Dependency:

• Depends on Pricing Plans PR #104.
• This core PR consumes the metadata; the Pricing Plans PR registers the package/subscription events and shares the same per-template placeholder metadata with its mailer. Both PRs must be tested and released together.

Testing:

1. Install this Directorist branch together with the branch from Pricing Plans PR #104.
2. Go to Directorist -> Settings -> Email Settings -> Email Events.
3. Open Pricing Plan email events such as Package Activated, Subscription Activated, and Package Cancelled.
4. Confirm each modal shows only placeholders supported by that event.
5. Confirm Subscription Activated does not offer unsupported tokens such as ==LISTING_TITLE== or {{cancelled_date}}.
6. Confirm supported formats still insert/render correctly, for example:
   • ==PLAN_NAME==
   • {{next_billing_amount}}

Verification:

• Targeted legacy settings-manager production build passed.
• git diff --check passed.
• Paired Pricing Plans branch was updated and pushed in Pricing Plans PR #104.

Any linked issues

Support ticket: https://team.sovware.com/support/cmsbripa300bwyps6tzg5ocsq

Depends on Pricing Plans PR #104.

Screenshot

N/A

Checklist

• My code follows the WordPress coding standards

[RabbiIslamRony]

Thanks for the update. Requesting changes before merge:

1. Please explicitly mention and link the dependency on sovware/directorist-pricing-plans-new#104. With this core PR alone and the released Pricing Plans 4.0.1.1, no Pricing Plan email events are registered, so both PRs must be tested and released together.

2. Please show only placeholders supported by each specific email event. On the paired PR heads, the Subscription Activated modal offered ==LISTING_TITLE== and ==CANCELLED_DATE==, but a captured email left both tokens unresolved. Scraping a shared field description and combining it with the global core list is not reliable; please use explicit per-event placeholder metadata shared with the mailer.

3. Please re-test the complete flow with both PRs and ensure the required Pricing Plans CI passes.

Once these are addressed, the updated heads can be revalidated locally.

[Arafat-plugins]

Updated both heads for the requested changes.

Directorist PR #2970:

• Added the explicit dependency on https://github.com/sovware/directorist-pricing-plans-new/pull/104 in the PR body.
• Extension template-only events now read explicit placeholder metadata from the registered section/fields (placeholders, template_placeholders, supported_placeholders, supportedPlaceholders).
• Extension template-only events no longer fall back to the global core placeholder list or scrape field descriptions/default template content.
• Rebuilt the legacy settings-manager bundle.

Pricing Plans PR #104:

• Added per-template placeholder metadata in EmailTemplate.
• Exposed those placeholders through the settings section/fields.
• Updated the mailer so replacements use the same per-template placeholder keys shared with the UI.
• Smoke test confirmed Subscription Activated exposes subscription placeholders only and does not offer/replace unsupported tokens like {{cancelled_date}} or ==LISTING_TITLE==.

Verification run locally:

• Directorist targeted production build for settings-manager passed.
• git diff --check passed in both repos.
• Pricing Plans targeted PHPCS passed for the PR PHP files:
  app/Mail/Mailer.php app/Mail/PackageMailer.php app/Providers/Admin/MenuServiceProvider.php app/Utils/EmailTemplate.php directorist-pricing-plans.php

Note on the Pricing Plans required PHPCS check: the current GitHub workflow is still failing, but the latest run checks out ref: development in the pull_request_target workflow rather than the PR head. The failure is coming from unrelated files on that checkout, for example resources/views/order-payment-summary.php, app/Providers/DirectCheckout.php, database/Migrations/*, etc. The updated PR files pass locally. The workflow/base PHPCS issue will need to be handled separately or the workflow should checkout the PR head before it can validate this branch accurately.

[RabbiIslamRony]

Thanks for the update. The event-specific placeholder metadata fixes the reported Pricing Plans issue in the normal flows, and the dependency on Pricing Plans PR #104 is now documented. However, two release-blocking cases remain:

1. Existing extension events without explicit placeholders metadata now return an empty list because templateOnly events fall back to []. Directorist Booking currently uses this legacy contract, so its email modals regress from 18 available placeholder buttons to none. Please use explicit event metadata when present, but preserve the legacy fallback for extensions that have not migrated yet.

2. Pricing Plans advertises {{expiry_date}} for package-activated, while PackageMailer only supplies that value when current_period_end exists. A valid lifetime package has a null end date, and the outgoing email therefore retains the literal {{expiry_date}}. Please always provide a replacement value for this advertised token, including the lifetime-package path.

Because this PR is intended to be released together with Pricing Plans PR #104, both cases need to be resolved and revalidated before merge.