fix: add missing jquery.switchbutton includes to compose.manager.page

[wqcqj9rq5d-tech]

Bug fix: missing jquery.switchbutton includes

compose_manager_main.php calls .switchButton() in multiple places, but compose.manager.page never loads the required CSS and JS files from Unraid's webGui.

Symptoms:

• Autostart toggles in the Compose tab show as plain checkboxes, not toggle switches
• Basic/Advanced View toggle does not render as a switch
• Browser console: switchButton: false or $.fn.switchButton is not a function

Fix:
Added the two missing includes to compose.manager.page after the existing jquery.filetree.js include:

<link type="text/css" rel="stylesheet" href="<?autov('/webGui/styles/jquery.switchbutton.css')?>">
<script src="<?autov('/webGui/javascript/jquery.switchbutton.js')?>"></script>

Tested on: Unraid 7.2.3

[mstrhakr]

Thanks for taking the time to contribute. Unfortunately jquery isn't included in Compose Manager Plus because it is provided by the main dynamix webgui. If you are having display issues, try doing [CTRL]+[SHIFT]+[R] to do a hard refresh in your browser.

[mstrhakr]

As I say that I'm realizing that it only loads the main library globally. It's likely been loaded for me on other pages. For example my system defaults to the Dashboard and it loads the switchbutton, then I go to compose and it's already available; no issues. But if I were to load Compose Manager first, it would NOT load the switch buttons correctly? I will test this out and see if I can recreate this behavior or if it's truly included already by the main webgui.

[mstrhakr]

Okay so it looks like its loading that already, even though its not explicitly included. I think my original assumption is correct.

To test this I cleared my browser cache, set my server to default to the settings page (no switch buttons there), opened the F12 dev menu to the network tab, then loaded the compose tab. Upon load I saw the swithbutton file get loaded in and all the toggle were styled correctly.

If you can do a hard refresh and still have the issue please talk to me and we can figure this out.

[mstrhakr]

I was accidentally testing on a dev version, let me do more testing before I say more things I'm not sure of lol

[mstrhakr]

Okay, the final is that this page, compose.manager.page is only loaded when Compose is embedded in the Docker tab. The docker tab includes this already and its loaded via that include. When the compose tab is its own header tab, it uses Compose.page and THAT does include the switch button bits. So at the end of the day this is not needed, but I guess it wouldn't hurt. Can you please try a hard refresh without this fix included to see if your switch buttons load normally?

[wqcqj9rq5d-tech]

Thanks for the thorough investigation. Your load-order theory is correct.

The bug was observed on Unraid 7.2.3 with Compose Manager Plus v2026.03.30 in a specific scenario: Compose Manager was set as the default/startup tab (the first page loaded after login), so the Docker tab had never been visited. In that case, the Docker tab's framework hadn't loaded switchbutton.js yet, and compose.manager.page didn't load it either → switches rendered as plain checkboxes.

If the user navigates through the Docker tab first (which is the default for most), the script is already in memory and Compose works fine — which matches what you observed in your test.

So to summarize:

• Normal flow (Docker tab visited first): no issue, your test confirms this
• Edge case (Compose Manager as default/startup page, Docker tab never visited): switchbutton.js not loaded → broken toggles

The fix is a defensive include — technically redundant for the typical navigation path, but it prevents the edge case entirely. Happy to close the PR if you'd prefer to keep the code lean, but it might be worth keeping for users who customize their default tab.

[mstrhakr]

• Edge case (Compose Manager as default/startup page, Docker tab never visited): switchbutton.js not loaded → broken toggles

Honestly I'm torn, seems harmless to add it but I don't think it's needed in this place. Again, compose.manager.page only loads when compose is embedded in the docker tab. When embedded as a tab or below the docker section on the docker tab, this IS loaded by docker. When compose is on its own tab it actually loads Compose.page, this has the includes you want so when the docker tab has not been loaded, the standalone compose tab still gets what it needs.

So this edge case is invalid because if compose manager is its own tab, it loads it itself.
If compose manager is embedded, docker.manager loads it.

I still think a hard refresh would have solved this, and I'm working toward fixing that now.

[wqcqj9rq5d-tech]

After looking more closely at the actual page files on the server, I think I can give you a more precise explanation.

compose.manager.page has Menu="Docker:2", so it always renders as a sub-page inside the Docker tab. Your point about the standalone case using Compose.page is correct, and that one already has the includes.

The issue we hit was a script load order problem within the Docker tab itself. DockerContainers.page does include switchbutton.js, but it's at line 65, near the bottom of the file. compose.manager.page gets rendered in between, and if the browser hasn't processed line 65 yet when .switchButton() is called, the function isn't defined yet.

So the edge case isn't "Docker tab never visited" as I described earlier, that was wrong on my end. The real scenario is a race condition in how the page assembles, which is why it's inconsistent and a hard refresh sometimes fixes it.

The defensive include in compose.manager.page makes the page self-contained and eliminates the dependency on load order entirely. But I understand if you'd rather handle it differently or just leave it. Either way, thanks for digging into this so thoroughly.