Add metadata to mailable view data #53042
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Background
While developing a package that filters outgoing emails by recipient using the
MessageSending
event, I noticed a discrepancy between notifications and mailables. Notifications include metadata like the notification class in the viewData (which is also provided to the event). However, when sending aMailable
, this functionality is not present and it is impossible to identify the originating class from the event.What is currently present for notification context:
Proposed Changes
This pull request introduces an
additionalMessageData
method to theMailable
class to enhance the provided viewData, mirroring the functionality present in theMailChannel
class used for notifications. The aim is to provide consistent metadata in theMessageSending
event across both notifications and mailables. As this is also passed to theMessageSending
event, this enables event listeners to identify the message source.Considerations
This PR does not fully mimic the notifications metadata. Currently i have only included the
Mailable
class to the meta data as I am not aware of a similarid
attribute on mailables and checking for the implementation of theShouldQueue
interface might not be enough to identify if the mailable was queued (due to ways to queue a mailable without it's implementation). I might be wrong, but the "__laravel_notification_queued" information on notifications might also not be 100% accurate depending on the way it is queued, so it might be ok to include the same information for mailables for consistency?