Collabora Online and WordPress integration

Collabora Online and WordPress integration: what it does and how it connects

A site team that keeps its files in WordPress and wants to edit them in the browser can connect Collabora Online to WordPress over the WOPI protocol, using the WordPress integration that Collabora lists on its product page. WordPress accounts decide who can open a document and who can edit it, so the access model your site already runs is the one that governs the editor. The main decision is not whether the connection works but who your WordPress users are, which roles they hold, and which of them should be allowed to co-edit.

Collabora Online is the component that renders and edits documents, and it runs on infrastructure you control, whether that is a Linux package install, Docker or Kubernetes. Documents move between WordPress and the editor during a session, so the Collabora server must be reachable from the WordPress host and the WordPress host must be reachable from the Collabora server. Plan that network path, the hostnames and the TLS certificates before anyone tests editing. Confirm with the plugin documentation which WordPress version and which Collabora Online release it supports, because those details are set by the integration and the server, not by this page.

The integration does not change which formats the editor supports. Collabora Online handles the OpenDocument and Microsoft formats listed on its product page, including docx, xlsx and pptx, PDF, RTF, CSV and Visio, so a site team should test its own library of files (older Word files, spreadsheets with macros, and PDFs with forms) before rollout. Keep that test set with the rollout record so you can compare results after each Collabora Online update.

Prerequisites to confirm before you install anything

The WordPress plugin connects two systems that each need their own certificates, network paths and accounts. Confirm these prerequisites first, because most rollout delays start with a version mismatch, a mixed-protocol URL or a firewall rule nobody owned.

WordPress version and hosting model

Confirm the WordPress version your site runs and whether it is self-hosted, managed or behind a shared hosting panel. Hosts that restrict outbound connections, block custom plugins or limit PHP settings can stop the WOPI exchange before it starts. Also confirm the exact plugin version and the WordPress versions it supports with Collabora's documentation for the integration, since those details are not covered here.

Collabora Online release line

Choose between the 26.04 line, announced July 23, 2026, and the 25.04 branch, which was still receiving point releases through 25.04.13 on September 21, 2026. Match the Collabora server release to what the plugin documentation supports, and record the choice so later upgrades follow a known path.

HTTPS on both endpoints

Plan HTTPS for the WordPress site and for the Collabora server URL, and use the same protocol on both sides. Mixed HTTP and HTTPS addresses are a common cause of blocked editing sessions. Confirm which certificate authority issues each certificate and who renews them before go-live.

DNS and firewall paths

Map every network path between WordPress and the Collabora server in both directions, including the name each side uses to reach the other. Note that the browser also loads the editor from the Collabora server, so users need a route to it as well. Ask the network team to open only the required ports and to document the rules.

CODE for testing, subscription for production

CODE is the free edition, released roughly once a month as a rolling release, and Collabora does not recommend it for production. For a live WordPress site with staff editing, compare CODE with a Business or Enterprise subscription, which includes long term support, a service level agreement and signed security updates. Decide this before the test environment becomes the production setup.

WordPress administrator accounts

Identify who will install and configure the plugin, who will hold administrator rights on the WordPress site, and who will manage the Collabora server. WordPress roles decide who can open and co-edit documents, so assign them deliberately and keep a named owner for each role. Avoid sharing one administrator login across the team.

Configuring WordPress and Collabora Online in order

This sequence takes a WordPress site from a Collabora Online server that nobody can reach yet to a working setup where only the right accounts can open documents for editing and viewing. Each step ends with a check you can run before moving on.

Install and secure the Collabora server
Your infrastructure or platform team installs Collabora Online on a server or cluster you control, using the packaging method that matches your operating model. Give it a stable hostname and serve it over HTTPS with a certificate your WordPress site trusts, so the editor is reachable at one fixed address. Confirm the setup by loading the Collabora discovery endpoint over HTTPS from a machine on the WordPress network, and check that the certificate chain validates without warnings. If the hostname changes later, the WOPI configuration on WordPress breaks, so settle the name before going further.
Install the WordPress integration component
A WordPress administrator installs the WordPress integration component for Collabora Online, following the instructions in Collabora's documentation for the version that matches your server branch. Activate it on the site, then confirm that the plugin's settings page appears in the WordPress admin area. Check the plugin's version against the Collabora Online release you installed, and note any compatibility statement in the vendor documentation. Do not treat a plugin from an unofficial source as equivalent without reviewing its code and maintenance status first.
Set matching protocols for both URLs
Enter the Collabora Online server URL and the WordPress site URL in the integration settings, and make sure both use the same protocol. If WordPress runs on HTTPS, the Collabora URL must also use HTTPS, because browsers block mixed content and the WOPI exchange fails silently when the schemes differ. Save the settings and open the Collabora discovery information from the WordPress side to confirm that WordPress can reach the server. The check is a successful connection status in the settings screen with no protocol or certificate warning.
Restrict WOPI requests to Collabora addresses
Limit which hosts can send WOPI requests to WordPress so that only your Collabora servers can do so. Collect the outbound IP addresses of every Collabora server or load balancer in front of it, then add them to the allow list your WordPress hosting or firewall supports. Confirm the list is complete by running a test request from a host outside that list and verifying it is refused, while a request from a Collabora server succeeds. Ask your network team to document where the list lives, since a change to Collabora's egress addresses will otherwise block editing for every user.
Map WordPress roles to edit and view
Decide which WordPress roles can open documents at all and which of those can edit, then configure the integration so that each role maps to the matching permission. Keep the mapping narrow at the start, for example by granting edit only to roles that already manage content on your site, and treat any role that can publish or upload as a candidate for edit access only after review. Record the mapping in your access documentation so reviewers can trace who can change documents. The check is that the saved mapping matches the table you approved, which you verify in the settings screen and again in the next step.
Test with one editor and one viewer
Create or pick two test accounts on the WordPress site, one assigned a role mapped to edit and one mapped to view only. Sign in as the editor, open a document from the media library, and confirm it loads in edit mode with changes saved back to WordPress. Then sign in as the viewer, open the same document, and confirm it opens read-only with no editing controls available. Also confirm that a logged-out visitor cannot open the editor at all. Document any failure with the account, document type and timestamp before you widen access to real users.

Mapping WordPress roles to Collabora editing rights

This table compares each standard WordPress role and a logged-out visitor against the two Collabora actions that matter most, opening a document and editing it. Read each row as the intended mapping, then confirm it against the plugin settings and the capabilities your site actually grants, because custom roles and plugins can change the result.

WordPress role or account group	Can open	Can edit	Notes
Administrator	Expected yes	Expected yes	Full site control. Confirm the plugin grants access through WordPress capabilities and that no sharing setting limits administrators on individual documents.
Editor	Expected yes	Expected yes	Typically manages other users' content. Confirm the edit capability the plugin checks and whether it applies to documents uploaded by others.
Author	Expected yes	Expected yes	Usually edits only their own uploads. Confirm whether the plugin limits editing to the author's files or the whole library.
Contributor	Expected yes	Confirm	Often can upload but not publish. Confirm whether the plugin lets contributors edit or only view, and test with a real account.
Subscriber	Confirm	Confirm	Commonly has no document access by default. Confirm whether the plugin exposes documents to subscribers and whether any share rule grants access.
Custom roles	Confirm	Confirm	Map each custom role to the capabilities it holds. Do not assume a role inherits the access of a built-in role.
Logged-out visitors	Confirm	Expected no	Editing should require a signed-in account. Confirm that public document links do not expose the WOPI endpoint or allow anonymous editing.

How WordPress credentials decide who can co-edit

WordPress stays the identity and permission source in this setup. When a user opens a document, the browser reaches Collabora Online with a WOPI request that points back to WordPress, and WordPress decides whether that request is honored based on the user's session and capabilities for the file. Collabora Online does not hold its own user directory for these documents. That means the first decision is which WordPress roles may open a document, which may edit it, and which may only view it. Write that matrix down before rollout, then confirm with the plugin vendor how it maps WordPress roles and per-file permissions onto the editor's view and edit modes, and what happens when a user's role changes while a session is open.

Co-editing means several authorized users open the same file at once and their changes merge in one document. Authorization alone does not prove this works. Session handling, lock behavior and how the plugin identifies a document across sessions all affect what a second editor sees, so the team should test concurrent sessions directly rather than assume them. Use at least two accounts with different roles, open the same file in separate browsers, edit the same paragraph and cell, then check what each user sees, whether a read-only user is blocked from editing, and whether a revoked user loses access on their next request. Record the results alongside the WordPress and plugin versions tested.

When several Collabora servers are added later, the routing guidance in the Collabora Online pillar applies: load balancers must route by the WOPISrc parameter so every user editing one document reaches the same server. Plan that now, because a stateless balancer can split co-authors across servers and break editing. Confirm with Collabora and the plugin maintainer how sessions and document locks are handled in that case before you size or scale the deployment.

Security controls for the WordPress to Collabora link

The link between WordPress and Collabora Online carries document content and edit rights, so it needs controls at three layers: who can reach the Collabora server, who can open and edit inside WordPress, and whether the software stays current. The cards below cover those layers and the logs that show when they fail.

Restrict WOPI requests by source IP

Collabora Online only needs to accept WOPI requests from your WordPress server. Limit the WOPI endpoint to the addresses of the servers that host WordPress, and confirm that the list still matches after load balancers, NAT or proxy changes. The Nextcloud administration manual recommends the same practice for its own Collabora integration, which makes a useful parallel. Check the allow list after every network change, because a stale entry either blocks editing or leaves the endpoint wider than intended.

Match protocol and prefer HTTPS

The WordPress site URL and the Collabora server URL should use the same protocol, and HTTPS should be the default for both. Mixed protocols lead to blocked frames, mixed content warnings and tokens sent over plain HTTP. Confirm the certificate chain is valid for the hostname WordPress uses to reach Collabora, not only for the browser-facing name. Test the editor from a clean browser session after any certificate renewal.

Limit which roles can edit

WordPress credentials decide who can open and co-edit documents, so role assignment is the main access control. Give view rights to readers and edit rights only to roles that need them, and review custom roles added by other plugins that may grant broader capabilities than expected. Confirm that a logged-out visitor cannot reach the editor through a direct document link, and test each role with a real account before go-live.

Keep WordPress and the plugin patched

Patch WordPress core, the Collabora plugin and the Collabora Online server as separate tracks, because each has its own release cycle. Subscribe to Collabora's security advisories and treat them as a standing input to your change calendar. The 25.04.7.5 release, dated January 29, 2026, fixed CVE-2026-23623, and the same release updated RPM and DEB package signing keys, so check that your package source still trusts the current keys before applying updates.

Restrict external reach to the Collabora server

Only the WordPress host should reach the Collabora server directly, and browsers should reach it only through the paths the editor requires. Place the server behind a reverse proxy or firewall rule set that blocks administrative endpoints and unrelated ports from the internet. Document which networks and hosts are allowed, and review that list against your network inventory each quarter so unexpected exposure is found early.

Review logs for failed WOPI calls

Failed WOPI calls show up in both WordPress and Collabora Online logs, and they are often the first sign of a misconfigured allow list, an expired certificate or an access attempt from an unexpected address. Set alerts on repeated failures from one source, on rejected token checks and on requests to the WOPI endpoint from unknown addresses. Decide who reviews these logs, how often, and where they are retained so incidents can be reconstructed later.

Common failures when WordPress and Collabora Online are connected

This table pairs each common symptom with its likely cause and a specific fix when WordPress and Collabora Online are connected. Work through the rows in order, and check the WordPress plugin logs and the Collabora server logs before changing any setting, since most symptoms point to one of the same few causes.

Symptom	Likely cause	Fix
Documents do not open	The WordPress site cannot reach the Collabora discovery URL, or the Collabora server cannot reach WordPress back over WOPI	Confirm the Collabora server URL in the plugin settings, then test the discovery URL and the WOPI callback from both directions. Check the plugin log for connection errors and the Collabora server log for the matching request.
Documents open read-only for editors	The WordPress user's role or the plugin's edit permission does not allow editing, so the session is issued as view-only	Check the WordPress role of the affected user and the plugin's permission mapping for that role. Open the same file as an administrator to confirm the document opens in edit mode, then compare the two user roles.
Blocked sessions when HTTP and HTTPS are mixed	The WordPress site URL, the Collabora server URL or the WOPI callback uses a different protocol from the page, so the browser blocks mixed content	Set the WordPress site address and the Collabora server URL to HTTPS. Correct any hard-coded HTTP links in the site configuration, then clear caches and retest in a private browser window.
WOPI requests rejected because the source IP is not allowed	The Collabora server's WOPI allow list does not include the address WordPress uses, often because of a proxy, load balancer or changed outbound IP	Find the source address in the Collabora server log, add it to the WOPI host allow list, and confirm that the list matches the WordPress server's current outbound path. Remove entries that no longer apply.
Files saved but not visible in WordPress	The save callback failed or wrote to a different location than the WordPress media library expects, or the file was saved as a new copy	Check the plugin log for PutFile errors and the file permissions on the upload directory. Confirm the file ID in the WordPress record matches the document that was edited, and test a save with a single user first.
Certificate trust errors	The Collabora server or WordPress uses a certificate issued by an internal authority that the other side does not trust, or the chain is incomplete	Install the internal root and intermediate certificates on both the WordPress server and the Collabora server, then verify the full chain with a command line TLS test. Renew certificates before they expire and confirm the hostname matches the configured URL.
Sessions drop when two users edit the same file	Requests for one document are routed to different Collabora instances, usually because a load balancer does not route by the WOPISrc parameter	Configure the load balancer to route by WOPISrc so all users editing one document reach the same server. Review the Collabora server log for session resets and confirm the replica count is set manually rather than through autoscaling.

Choosing a Collabora edition and server layout for the WordPress site

A proof of concept tests whether the WordPress plugin, the WOPI connection and the document formats your team uses behave correctly. Collabora describes the free CODE edition as suited to testing, home use or small teams, and does not recommend it for production. CODE is a rolling release, published on average once a month, so a pilot built on it should be treated as a test environment rather than the basis for a live rollout.

Edition limits: CODE carries no long term support, SLA or signed security updates, so the pilot cannot stand in for a supported production service.
Server count: A single CODE server is usually enough to prove the connection, but confirm that the test server is separate from the production WordPress host.
Hosting: Decide whether the pilot runs on the same host as WordPress or on a separate machine, and record which network path the plugin uses to reach it.
Load: Use a few test accounts and a small set of real file types to observe behavior, not to measure capacity for a full site.
Exit criteria: Agree in writing what the pilot must prove before the team moves to a supported edition.

Before leaving the pilot, confirm the current CODE terms with Collabora and check that the document formats in use open and save correctly.

Questions teams ask before connecting WordPress to Collabora Online

What does it cost to connect WordPress to Collabora Online?

The cost has two parts: the Collabora Online subscription and the services work to connect and test the site. Collabora's pricing page lists a Business plan at 3 euros per user per month for up to 99 users, which includes long term support, a service level agreement, signed security updates and customer portal access. Plans for 100 or more users are quoted with volume discounts and add integration support and customization services. The subscription recurs monthly per user, while setup, plugin configuration, role mapping and testing are typically one-time work. Ask any partner for a written quote that separates these lines, states the user count it assumes, names who hosts the Collabora server, and lists which testing and handover items are included.

How long does a WordPress and Collabora Online setup take?

Duration depends mostly on the state of the site and the access model, not on the plugin itself. Teams with a working HTTPS WordPress site, a DNS record for the Collabora server and existing server access usually move fastest. Delays tend to come from certificate issuance, firewall rules between WordPress and Collabora, agreeing which WordPress roles may edit, and testing a representative set of documents in the formats your users rely on. Multisite installations, custom storage paths and large document libraries add checking time. No fixed duration is supplied here, so ask for a timeline in the written scope with milestones for connectivity, access testing and user acceptance.

What must our internal team provide before setup starts?

Four inputs unblock most projects. First, WordPress administrator access, or a named administrator who can install and configure the plugin and change role settings. Second, DNS control for a hostname that points to the Collabora server, so the WordPress site and the editor can reach each other over the same protocol. Third, a valid certificate for that hostname, since the Nextcloud guidance on WOPI traffic prefers HTTPS and the same protocol as the host. Fourth, a role map that states which WordPress roles can open documents, which can co-edit and which are view only. Your team should also confirm which network addresses may send WOPI requests so those rules can be written before go-live.

Can one in-house WordPress administrator run this integration alone?

A capable WordPress administrator can install the plugin and configure the basic connection, especially on a single site with a small user group. The harder parts are the server side: running or reaching a Collabora Online server, reverse proxy and TLS configuration, firewall rules, and monitoring for failed editor sessions. Collaborative editing also needs the editor and WOPI paths to behave correctly under load, which is a platform concern rather than a WordPress one. If your team has no one who runs Linux services or reverse proxies, plan for outside help on the infrastructure and keep the WordPress administrator as the owner of roles and content. Confirm this split in writing before work starts.

What happens to the integration when WordPress or Collabora Online is upgraded?

Each component has its own update path, so both need a test before they reach production. Collabora publishes branches and point releases, and its 25.04 release notes show that security fixes arrive as point releases, such as 25.04.7.5 fixing CVE-2026-23623. A WordPress core or plugin update can change how requests reach the editor, so the connection and a sample document should be re-tested after each change. Keep a staging copy, record the current Collabora version and plugin version, and set a rollback path. Ask any partner how upgrades are scheduled, who approves them and whether they cover both sides of the integration.

How do user access changes work after go-live?

Access is controlled by WordPress credentials, so changes to a user's role or account in WordPress change what they can open or edit. Removing a user from the role that may edit should stop new edit sessions, but existing sessions and cached copies may need checking, so test this rather than assume it. Joiners, leavers and role changes need an owner and a process, typically tied to your identity or HR workflow. Ask how the role map is documented, how changes are reviewed, and how the team confirms that a removed user can no longer open a document. Test these steps with real test accounts before you announce the rollout.

How DeployOpen scopes, delivers and supports this integration

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the WordPress plugin, the Collabora Online server and the access rules that connect them stay under your control. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Confirm which WordPress sites, post types and user roles will open and co-edit documents through Collabora Online.
Record the Collabora Online server address, network path from WordPress and the editor hostnames that must be reachable.
Agree in writing how WordPress credentials map to view and edit rights, and who approves exceptions.

How we build

Install and configure the WordPress plugin against your chosen Collabora Online server over HTTPS.
Set up the Collabora Online deployment in your own cloud account, data center or restricted network, including the reverse proxy in front of it.
Test editing, co-authoring and access denial for each role with representative documents from your library.

How we hand over

Deliver configuration records, the access model, and a test script your team can rerun after changes.
Document the upgrade and patching steps for both WordPress and Collabora Online, including how to track vendor security advisories.
Walk your administrators through daily checks, log locations and the escalation path for editor failures.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
Retainer work can cover plugin and Collabora Online version updates, checks after WordPress core and theme changes, and re-running the access tests.
Confirm with DeployOpen during scoping which response and reporting terms apply, since these are set in the written agreement.

Collabora Online and WordPress integration