Buttons in the new UI system is not working for me

[jelum 36]

I'm trying to add a button to a plugin setting page using the new UI. I'm able to see the button, but when I click on it, nothing happens. Where do I miss something?

 

Plugin:

public class Plugin : BasePluginSimpleUI<PluginPageUI>, IHasPluginConfiguration

 

PluginPageUI:
 

public class PluginPageUI: EditableOptionsBase {

...

        public Emby.Web.GenericEdit.Elements.ButtonItem AButton { get; set; } = new ButtonItem("My Button");

...

}

 

PluginPageView:

public class PluginPageView : IPluginUIView{ 

        public MovieMergePageView(PluginInfo pluginInfo,ILogger logger)
        {
            PluginId = pluginInfo.Id;
            _logger = logger;
            _pageUi = new PluginPageUI();
            ContentData = _pageUi;
        }
  
         public bool IsCommandAllowed(string commandKey)
        {
            return true;
        }

        public async Task<IPluginUIView> RunCommand(string itemId, string commandId, string data)
        {
            switch (commandId)
            {
                case "AButton":
                    _logger.Info($"Press button {itemId}");
                    return this;
            }

            return this;
        }
  
  ...

}

 

It looks like the PluginPageView class is not even created during the startup. At least a breakpoint was not triggered. Should I use a different approach with buttons?

I used ButtonsAndLinksUI.cs as an example

 

 

Edited December 19, 2025 by jelum
add link

[Luke 42077]

@softworkz

[jelum 36]

@softworkz, kind reminder 

[softworkz 5066]

@jelum

Apologies, this has slipped through my attention filters.

The Emby SDK Documentation: Simple Plugin UI is a special and limited way where you just need to create a single class with properties.

This path doesn't allow custom buttons and extended logic. The only ways of interaction is by overriding these three methods:

• OnBeforeShowUI
  Allows you to load/prepare any specific values, populate labels, show/hide controls
   
• OnOptionsSaving
  Called when the user hits the Save button. You can cancel the save operation by returning true and change the UI object values to indicate to the user what's wong
   
• OnOptionsSaved
  The values have been saved to storage and your plugin should reload the configuration to use the changed values

While this is sufficient in many cases, it's still quite limited when comparing to the full Plugin UI
If you want to use that, you need to stop deriving the plugin class from Emby SDK Reference: BasePluginSimpleUI<TOptionType> and fully follow the code from the sample you've already been looking at.

Please let me know when you have any more questions.

[jelum 36]

@softworkz, thanks for the answer!

Unfortunately, I need the support of a custom button that will call some functionality on the backend. I already have such support via the old flow (js + HTML), but wanted to implement the same via the new path after you advertised it as a successor.

Do you know when the new flow will have such support?

[softworkz 5066]

You misread. The "new flow" has two flavors.

8 hours ago, softworkz said:

[Simple UI...] it's still quite limited when comparing to the full Plugin UI
If you want to use that, you need to stop deriving the plugin class from Emby SDK Reference: BasePluginSimpleUI<TOptionType> and fully follow the code from the sample you've already been looking at.

 

[jelum 36]

Do you mean:

public class MyPlugin : BasePlugin, IHasThumbImage, IHasUIPages, IHasPluginConfiguration

 

Clicking on my custom button had no effect, even with this approach (BasePlugin + IHasUIPages + implementation of a custom storage, sort of a page controller, a page view, etc.)

Looks like I missed something  

What are the key snippets to share to help?

 

[softworkz 5066]

Here's a project template which will be added to the SDK on the next update.

EmbyPluginUiTemplate.zip

It has everything that is needed and I also added a button with backend processing as an example.

Please let me know whether that helps.

Thanks

[jelum 36]

Thanks, will check!

[softworkz 5066]

Sorry for the confusion. I have realized that the documentation is unclear and misleading. First, it praises all the benefits of the new PluginUI and then it suggests to go with the SimpleUI plugin template which allows for just a small subset of those features (i.e. no dialogs, wizards, button actions etc.)

That's on me. At the time of writing, there was no other template available and intentions for later improvement became forgotten.

 It's all fixed now, the new template will be in the next SDK update and the docs update will also be published alongside the new server releases (dev.emby.media for stable and betadev.emby.media for beta).

[jelum 36]

@softworkzThanks, the template really helped. I missed that some functionality is linked to a specific class and not only to the interface. I merged all functionality into my implementation of interfaces in my previous non-working solution (since the plugin is small (2-3 active classes), I don't see a reason to have several layers of interface implementation if I can put all in one without losing SOLID principles). But once I used the "UIBaseClasses" - everything started to work. I think it is worth mentioning in the documentation that one has to use "UIBaseClasses".

Thanks for the help

 

[softworkz 5066]

@jelum

We have a somewhat unfortunate history in breaking plugins by interface changes. The UIBaseClasses kind-of give you the API that we want to provide, while the actual interfaces are done in a way that features can (ideally) be added without breaking interfaces (e.g. via Emby SDK Reference: PluginViewOptions).

On 12/30/2025 at 9:51 AM, jelum said:

I don't see a reason to have several layers of interface implementation if I can put all in one without losing SOLID principles).

The base classes stem from our own plugin implementations and there are multiple reasons for using them:

• When a breakage is unavoidable, the base classes provide an opportunity to adapt more easily
• You don't need to repeat all the boilerplate code in each plugin view - what you see is just the code that is specific to that view and you don't see the same repeated code in all views
• You can easily add your own code that should be common and available to all views (PluginViewBase) or all views of a type, like "all dialogs" (PluginDialogView)

They are also meant to make the samples easier to understand by pulling focus on the important parts and moving less relevant stuff out of the way. Eventually, these are made to give developers a reliable and proven pattern at hands which might indeed appear unnecessary at first sight, especially when you have a single view only.

Anyway though, it's just sample code, you're free to do it in whichever way you like, of course.