fix: [SDK-4340] skip enqueueing metabox assets for disallowed post types#418
Conversation
When viewing a Custom Post Type that has not been added to "Additional Custom Post Types" in the OneSignal admin settings, the metabox PHP correctly skips rendering, but the metabox JS/CSS were still enqueued on every post edit screen. The JS would then log a console error because the expected DOM elements (os_update, os_options, etc.) were missing. Gate the enqueue with the same onesignal_is_post_type_allowed() check already used to register the metabox so the script only loads when the metabox is actually present.
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
LGTM — mirrors the existing post-type allow-list gate used by onesignal_add_metabox.
Extended reasoning...
Overview
This PR adds a 4-line early-return in onesignal_meta_files() (v3/onesignal-metabox/onesignal-metabox.php) that skips enqueueing the metabox JS/CSS when the current post type isn't allowed. It uses the existing onesignal_is_post_type_allowed() helper (v3/onesignal-helpers.php:38), which is the same gate already applied by onesignal_add_metabox() and onesignal_save_meta(). The net effect is that the metabox UI and its assets are gated consistently.
Security risks
None. This change is a strict narrowing of when assets are loaded — it removes a code path on disallowed post types, doesn't introduce any new user input handling, capability checks, escaping concerns, or external calls. The helper consults a stored option, not request data.
Level of scrutiny
Low. This is a tiny, mechanical bug fix that reuses an already-vetted helper to close a UX issue (a JS console error on CPTs that aren't enabled). It does not touch auth, the save path, REST API integration, or rendering of trusted/untrusted data.
Other factors
The bug hunting system found no issues. The change is self-contained to one function, follows the established pattern in the file, and the PR description includes both manual reproduction steps and confirmation that the existing 69-test suite passes.
2 participants
One Line Summary
Stop loading the OneSignal metabox JS/CSS on Custom Post Types that aren't enabled in plugin settings, eliminating a Classic Editor console error.
Motivation
SDK-4340: When viewing a Custom Post Type in the Classic Editor that has not been added to "Additional Custom Post Types" in OneSignal settings, a DOM error appeared in the browser console:
The metabox PHP (
onesignal_add_metabox) correctly skipped rendering for disallowed post types, butonesignal_meta_fileswas registered onadmin_print_styles-post.php/admin_print_styles-post-new.phpunconditionally, so the metabox JS still loaded and immediately failed its DOM lookup.Scope
v3/onesignal-metabox/onesignal-metabox.php—onesignal_meta_files()now early-returns for disallowed post types using the existingonesignal_is_post_type_allowed()helper (the same gate already used byonesignal_add_metabox()).Testing
Manual
product) and open one in the Classic Editor.OneSignal: required elements are missing in the DOM.productto "Additional Custom Post Types", reload the edit screen.Unit / Integration
composer test— all 69 existing tests pass.Affected code checklist
v3/)Checklist