OpenSite/Guides/Manage extensions
Recognize extension availability and compatibility before adding code to the application.
- Stable identifier
opensite.help.manage-extensions
Prerequisites
A trusted extension package and instructions from its distributor. This baseline has no verified public add-on store or general end-user installer.
Steps
Identify what you received
A plugin can contain native code, Python, or both. A workbench is a user interface environment contributed by an extension. A macro is a Python script. These names are not interchangeable.
Check compatibility
Match SDK/host version, native ABI, architecture, compiler/runtime and Release/Debug configuration. Copying a DLL that compiled elsewhere is not a compatibility test.
Keep the package layout
Follow the package’s documented location and restart requirements. Preserve its manifest, implementation, catalogs and runtime files. Do not guess an install folder or move only one file from a mixed package.
Read activation failures
A provider can be unavailable, incompatible, or denied a capability. Record the extension ID/version and host build. Startup registration/discovery is not proof that every command ran.
Protect documents when a provider is missing
Keep a backup before changing extension versions. An unavailable object may retain its payload as a placeholder. See OpenSite/Guides/Recover linked and unavailable objects.
Developer route
For the supported native sample workflow, use OpenSite/Guides/Build a native plugin. The GUI SDK’s distributable state is separate from the installed headless plugin SDK.
Expected result
You can identify the package’s purpose and compatibility needs before attempting to use it.
Limitations
In-process native/Python extensions are trusted code, not sandboxed content. Saved custom workspaces are not implemented user functionality.
