WordPress Plugin
Enabling Modules
A decision matrix on which of the seven Unidy modules to enable, and how they interact.
The plugin exposes seven independently toggleable modules. This article summarizes what each does and when to enable it.
Overview
Each module is toggled on or off in Unidy → Overview → Modules. Disabled modules do not load their assets or register their shortcodes.
Module | Use when… | Shortcode |
Auth | Visitors need to sign in via Unidy | [unidy_user_menu] |
Profile | Signed-in users manage their profile data | [unidy_profile] |
Newsletter | You run one or more newsletters | [unidy_newsletter], [unidy_newsletter_preferences] |
Tickets | You sell tickets through Vivenu | [unidy_tickets] |
Transactions | Users see their payment history | [unidy_transactions] |
Subscriptions | Users manage recurring memberships | [unidy_subscriptions] |
WooCommerce | You use WooCommerce and want SSO-backed accounts | (auto-integrates) |
Dependencies
- Auth is the foundation. Every other module depends on the visitor being identifiable via Unidy, so the Auth module should be enabled first.
- Profile, Tickets, Transactions, and Subscriptions are read-only or edit-only surfaces on top of what your Unidy instance already knows about the user. They render as inline sections when the user is signed in, and as sign-in prompts otherwise.
- Newsletter works both anonymous (signup form on any page) and signed-in (preference center). You can render it in both modes on the same site.
- WooCommerce integrates Unidy identity with the WooCommerce account system. Only enable it if you use WooCommerce.
Session mode
Under Unidy → Auth → Session mode you decide how the Unidy identity is reflected in WordPress:
- Create WP user (default): A matching WordPress user is created on first sign-in. Useful when your site relies on the WordPress user table (comments, WooCommerce, member-only content plugins).
- Match existing WP users only: No WordPress users are created; visitors with an existing matching WP account get logged into WordPress on top of Unidy sign-in.
- Frontend only: No WordPress session is created. Visitors are identified by Unidy for the plugin's modules only.
The session mode only affects how the plugin bridges Unidy identity into WordPress. All modules keep working in any mode — the difference is whether comments, memberships, and other WP-native features see the visitor as logged in.
Enable / disable at runtime
Module toggles take effect immediately after saving. There is no cache to purge for module enablement — the plugin re-registers shortcodes and hooks on each request based on the current toggle state.
If you disable a module while a page still contains its shortcode, the shortcode renders empty (no error). Enable the module again to bring the section back.