EzyPlatform can be extended with separate modules. Two useful ideas are themes and plugins. You can think of a theme as the appearance and pages people see, while plugins add features and connect the platform to different kinds of applications.

In this guide, Plugins is the larger group. It contains Admin Plugins, Web Plugins, Socket Plugins, and Socket Apps. A Theme is a separate module type.

A Theme controls how the public-facing website looks and which pages it presents. In one EzyPlatform instance, only one Theme can be active at a time. This does not limit the website to one page: the active Theme can provide many pages for different needs and customer groups, such as an introduction, product pages, a blog, or support pages.

A Theme commonly contains page layouts, HTML templates, styles, images, browser-side JavaScript, and the code that prepares data for a page. Administrators can create additional pages for a Theme through the admin interface. They can also use Vibe Coding to describe a page in everyday language and help create it. See Vibe Coding with EzyPlatform.

A single Theme can also serve multiple domains. You can create a page for each domain, then configure a routing tool such as Nginx to send requests from each domain to its matching page. For example, shop.example.com could open the shop page while news.example.com opens the news page. Nginx sits in front of the website and forwards requests to the appropriate address or path based on its configuration.

Imagine a shop: the theme is the shop's design style and layout. A shop can have many areas and pages, while using one active design style at a time. The theme can also include page-specific behavior, but it is not the place where every business feature must live.

In the SDK project template, theme files include page templates under src/main/resources/templates, static files under src/main/resources/static, and web page controllers. The platform registers themes separately from web plugins, even though both take part in the web application.

A plugin is a separately packaged set of features that EzyPlatform can add to a project. The word “plugin” covers several kinds of modules because a project may need features for administrators, normal website visitors, or live socket connections.

An Admin Plugin adds screens and actions to the administration area. For example, it might let an administrator edit settings, manage records, or review activity. It can provide both admin pages and admin APIs, and it can add links to the admin menu.

In the project template, admin page templates are kept separately from the public website's theme templates. The plugin's menus.properties file describes its menu entries.

An Admin Plugin runs in the administration application, which has its own port. Its code cannot directly call code in a Socket Plugin, Socket App, Web Plugin, or Theme. To exchange data or request a capability from those parts, the Admin Plugin must call an API across the application boundary.

A Web Plugin provides website-side capabilities. It can provide APIs for a website or browser to call, and it can also provide extra interface elements for a Theme to use, such as reusable components or page templates for a feature. An API is a defined way for one part of a system to ask another part for information or an action. For example, a page might ask an API for a list of items or send a request to save a setting.

The theme and web plugin often work together: the theme presents the main pages, while the web plugin can add APIs, reusable interface elements, and other website capabilities. EzyPlatform tracks these as distinct module types.

The Theme and Web Plugin are both part of the web application, so they can work together directly within that application, depending on how the code is organized. They cannot directly call code in socket modules, but they can send requests to a Socket App or Socket Plugin through the Socket API. Calls from a Theme or Web Plugin to an Admin Plugin should be limited for security reasons; expose administrative APIs only when needed and protect them appropriately.

A Socket Plugin adds supporting behavior to the socket server, but it does not manage users. This makes it suitable for handling user authentication, internal server events, or commands that are not tied to a specific user. A socket connection stays open so the server and a user's application can exchange updates as they happen.

The sample socket plugin includes an entry loader and socket-zone settings. In plain terms, these tell the socket server how to start the plugin and which live-server area it belongs to.

A Socket App contains features that run on the socket server and manages users connected to the application. Requests sent by users over a socket connection should therefore be handled here. For example, a game could use a Socket App to handle players joining, moving, and chatting without refreshing a webpage.

The sample project has an app entry loader and request controllers for actions such as joining a game or moving. The entry loader is the starting point the server uses to load the app.

Socket Apps and Socket Plugins can also communicate through the socket server's zone, app, and plugin management mechanisms. A zone can be thought of as an operating area on the server; within a zone, apps and plugins can be registered and work together using the mechanisms provided by the platform.

Because Socket Plugins and Socket Apps run on the socket-server side, they can directly call each other's code using the mechanisms provided by EzyPlatform/EzyFox. They cannot directly call code in an Admin Plugin, Web Plugin, or Theme because those modules run in other applications; communication with them must go through an API. A Socket App or Socket Plugin can also call an Admin Plugin through an API, but this direction should be limited for security reasons.

Think of each application as a separate team. Modules within the same application can work together directly when the platform supports it. To communicate with a module in another application, they send a request through an API. Admin Plugins belong to the administration application, Themes and Web Plugins belong to the web application, and Socket Plugins and Socket Apps belong to the socket server. So Admin Plugins communicate with web or socket modules through APIs; the two socket module types can work together directly; and Themes and Web Plugins can work together directly within the web application and can call socket modules through the Socket API. Limit calls from Themes or Web Plugins to Admin Plugins, and protect any administrative APIs that must be exposed.

flowchart LR
    subgraph Admin[Administration application · separate port]
        AP[Admin Plugin]
    end

    subgraph Web[Web application]
        TH[Theme]
        WP[Web Plugin]
        TH <-->|Direct calls within the application| WP
    end

    subgraph Socket[Socket server]
        SP[Socket Plugin]
        SA[Socket App]
        SP <-->|Direct calls through zone, app, and plugin mechanisms| SA
    end

    TH <-->|Socket API| SA
    TH <-->|Socket API| SP
    WP <-->|Socket API| SA
    WP <-->|Socket API| SP

    AP <-->|API across application boundary| WP
    AP <-->|API · limit for security| SA
    AP <-->|API · limit for security| SP

    TH -.->|Limit for security| AP
    WP -.->|Limit for security| AP

Solid arrows show communication paths. Calls to an Admin Plugin from a Theme, Web Plugin, Socket App, or Socket Plugin should be limited for security reasons; expose them only when there is a clear need and the API is properly protected.

For a simple website, a visitor opens a page rendered by the Theme. The page may call a Web Plugin to read or update information. An administrator can manage related settings through an Admin Plugin. If the product also has live features, a Socket App handles those real-time actions, with a Socket Plugin providing supporting socket-server behavior.

These modules are separate so each part has a clear job. A project can include the module types it needs; it does not have to use every type.

EzyPlatform records each module's type in its `module.properties` file. The SDK project template places modules in folders according to their type:

The runtime starts the web modules as part of its web application and loads socket modules on the socket-server side. This separation helps EzyPlatform know where each module belongs and how to load it.

The SDK can generate these module types from its project template. Each generated module includes metadata that identifies its type and gives the platform information needed to load it.