Repository navigation
Fix alert audio not playing: resolve sounds dir from plugin root - #278
Merged
Merged
Conversation
getMonitorSound() used __DIR__ . '/sounds/' after the controller moved to includes/, so the sound file was never found and the audio element was never printed. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The localized path correction addresses the reported defect with no blocking issues identified.
0 open findings
What changed in this PR
Restores alert audio by resolving sound files from the plugin root rather than the controller’s includes/ directory.
Changes:
- Corrects the sound-file lookup path.
- Adds a regression test and changelog entry.
| File | Description |
|---|---|
| tests/Integration/MonitorSoundPathTest.php | Checks the path expression and directory layout. |
| includes/controller.php | Resolves sounds from the plugin root. |
| CHANGELOG.md | Documents the alert-audio fix. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
bmfmancini
approved these changes
Oct 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
getMonitorSound()inincludes/controller.phpresolved the sound file with__DIR__ . '/sounds/'. Since the controller moved intoincludes/, that points atincludes/sounds/, which doesn't exist, so the configured sound was never found.isMonitorAudible()then returned false and the<audio id='audio'>element was never rendered, somuteUnmuteAudio()had nothing to play.The path now uses
dirname(__DIR__) . '/sounds/', which points at the plugin's realsounds/directory. A regression test and a CHANGELOG entry are included.Related Issue
Audio no longer plays when a device is down or an alert is triggered.
Motivation and Context
This is a code defect from the restructure, not a browser restriction. Browser autoplay policies can still block playback on a freshly opened tab until the user interacts with the page, but that only matters once the audio element is rendered again.
How Has This Been Tested?
php -l includes/controller.phppasses.dirname(__DIR__) . '/sounds/Siren.mp3'resolves to an existing file fromincludes/.tests/Integration/MonitorSoundPathTest.php(not run locally: no Pest in this checkout).Types of changes