Fix boot failure on Nextcloud 34, support onlyoffice connector >= 10.1, and fix PHP 8.4 nullable deprecations

[NSO73]

What

Four related fixes that let documentserver_community boot and run on Nextcloud 34 and with the current ONLYOFFICE connector on recent PHP.

On Nextcloud 34 the app currently fails to boot on every request, so this is not only a connector >= 10.1 issue.

1. Fix boot failure on Nextcloud 34 (getConfig() removed)

OC\Server::getConfig() no longer exists on NC 34, so the new AppConfig('onlyoffice', \OC::$server->getConfig(), ...) calls in Application.php break the app on every request:

Could not boot documentserver_community: Call to undefined method OC\Server::getConfig()

Visible symptoms: HTTP 500 on /apps/documentserver_community/healthcheck, and "Error when trying to connect" on the admin page.

IConfig is now resolved through the DI container (\OC::$server->get(\OCP\IConfig::class)) instead of the removed accessor. Same service, no behaviour change.

Credit to @sjs6776 and @defame-flagstick, who diagnosed this and posted the fix in the comments.

2. Support ONLYOFFICE connector >= 10.1 (AppConfig constructor change)

Once the boot failure above is fixed, the next blocker is the connector's constructor signature. OCA\Onlyoffice\AppConfig::__construct changed in 10.1 from

(string $appName, IConfig, LoggerInterface, ICacheFactory)                            // <= 10.0

to

(string $appName, IAppConfig, IConfig, IUserConfig, LoggerInterface, ICacheFactory)   // >= 10.1

With the old 4-argument call the app no longer boots:

TypeError: OCA\Onlyoffice\AppConfig::__construct(): Argument #2 ($appConfig)
must be of type OCP\IAppConfig, OC\AllConfig given

A new buildAppConfig() helper detects the constructor arity at runtime via reflection and passes the matching arguments, so it keeps working with both the old (<= 10.0) and the new (>= 10.1) connector, and with the Nextcloud versions that ship them (OCP\Config\IUserConfig only exists on the newer ones). The two duplicated inline constructions are replaced by calls to this helper.

3. PHP 8.4 — explicit nullable parameter types

PHP 8.4 deprecates implicitly nullable parameters (Type $x = null). Made the nullable explicit (?Type) for the $password parameters in DocumentConverter, ConverterBinary and DocumentStore. No behaviour change; removes the deprecation warnings logged on every document conversion.

4. Allow installation on Nextcloud 34

appinfo/info.xml still declared max-version="33", so even with the fixes above the app would not be offered on NC 34. Bumped to max-version="34".

Changed files

File	Change
lib/AppInfo/Application.php	buildAppConfig() helper: DI-resolved IConfig + connector arity detection
lib/DocumentConverter.php	explicit ?Type on $password
lib/Document/ConverterBinary.php	explicit ?Type on $password
lib/Document/DocumentStore.php	explicit ?Type on $password
appinfo/info.xml	max-version 33 → 34

Testing

Verified on Nextcloud 33.0.5 / PHP 8.4 / connector 10.1.0: the app boots, /healthcheck returns 200, documents open and convert.

Independently reported on Nextcloud 34.0.1 / PHP 8.3.31 / connector 10.1.2 / documentserver_community 0.2.4 by @blueforce: the app boots cleanly, /healthcheck returns true, the boot errors disappear from the log, and opening/editing .docx and .xlsx works with no errors. To be precise about scope: that confirmation was obtained with the equivalent fix applied by hand (\OC::$server->get(\OCP\IConfig::class) plus the 6-argument constructor), not with this branch checked out verbatim.

Note

I have since migrated to a different setup and won't be actively testing or maintaining this going forward. The PR is left open in case it is useful; happy for a maintainer to take it over or push to the branch.

[audioanton]

I have this exact issue too. The PR looks like a sensible fix.

[sjs6776]

Note the fix on line 96 of my file below, this allows docserver to work on NC34.
Credit to @defame-flagstick for the code to fix getConfig() being deprecated
Application.php

[NSO73]

Thanks @sjs6776 (and @defame-flagstick) — I've folded the getConfig() fix into the PR (commit c230ddf): \OC::$server->getConfig() → \OC::$server->get(\OCP\IConfig::class), so it now also covers NC34.

Heads-up: I've since migrated to a native EuroOffice setup, so I won't be actively testing/maintaining this on my side anymore. I'm leaving the PR open in case it's useful to others and a maintainer wants to pick it up.

[blueforce]

This PR is also required for Nextcloud 34, not only for connector >= 10.1 — that might be worth reflecting in the title, since it's easy to miss.

On NC 34, OC\Server::getConfig() no longer exists. The two new AppConfig('onlyoffice', \OC::$server->getConfig(), ...) calls in Application.php therefore make the app fail to boot on every request:

Could not boot documentserver_community: Call to undefined method OC\Server::getConfig()

The visible result is HTTP 500 on /apps/documentserver_community/healthcheck, and the admin page shows "Error when trying to connect". Once that is fixed, the 6-parameter AppConfig constructor in connector 10.1.2 is the next blocker — which is exactly what buildAppConfig() here handles.

I ran into both on a production instance:

• Nextcloud 34.0.1
• PHP 8.3.31
• onlyoffice connector 10.1.2
• documentserver_community 0.2.4

To confirm the diagnosis I applied the equivalent change by hand (\OC::$server->get(\OCP\IConfig::class) plus the 6-argument constructor), not this exact branch. With that in place the app boots cleanly, /healthcheck returns true, and the boot errors disappear from the log. So I can confirm the root cause and that the fix direction is correct — but to be precise about scope: I have not run this branch verbatim, and I have not done a full editor regression test on NC 34.

One gap this PR doesn't cover: appinfo/info.xml still declares max-version="33", so even after this is merged the app won't be offered on NC 34 without a version bump.

[blueforce]

Update: I've now verified the editor itself on the same instance (Nextcloud 34.0.1, PHP 8.3.31, onlyoffice connector 10.1.2) — opening and editing .docx and .xlsx works cleanly, no errors in the log. The earlier caveat about the editor being untested no longer applies.

Still accurate: I'm running the equivalent fix applied by hand, not this branch verbatim.

[NSO73]

Thanks @blueforce, both of your points are addressed:

• max-version: bumped to 34 in appinfo/info.xml (commit 9912f1a), so the app is now offered on NC 34.
• Title: updated to lead with the NC 34 boot failure, since that's the most visible symptom and it was indeed easy to miss.

I've also rewritten the PR description so everything is in one place: the getConfig() removal and its exact error, the connector 10.1 constructor change that follows it, the PHP 8.4 nullables, and the max-version bump. Your NC 34.0.1 report is included in the Testing section, with your caveat that you ran the equivalent fix by hand rather than this branch verbatim.

I left <version> at 0.2.4 — that's a release decision for a maintainer.

As mentioned above, I'm no longer running this setup myself, so I won't be doing further testing on my side. Everything known is now in the description; happy for a maintainer to take it from here or push to the branch.

[blueforce]

Update: I've now tested this branch verbatim on a production instance — the five files from 9912f1a are running as-is, no local modifications.

Environment

• Nextcloud 34.0.1, PHP 8.3.31, LiteSpeed
• onlyoffice connector 10.1.2, documentserver_community 0.2.4

What I verified

• App boots cleanly on every request; /apps/documentserver_community/healthcheck returns true
• /settings/admin/onlyoffice loads normally — no "Error when trying to connect"
• Editor end-to-end: created a new .docx via the Files "New" menu, it opened in the ONLYOFFICE editor, typing works, and the save round-trip back to .docx completed (file written to disk, correct size). .xlsx works as well.
• PDFs open in the native Nextcloud viewer
• max-version="34" from your latest commit is in place; the app is offered and enabled on NC 34
• No errors in nextcloud.log across the whole session, no errors in the browser console, and every editor request returned 200

The only thing I saw that isn't a 200: a 404 on 3rdparty/onlyoffice/documentserver/themes.json. That file isn't part of the release tarball at all — it's cosmetic (editor themes) and unrelated to this PR.

My earlier caveat ("equivalent fix by hand, not this branch verbatim") no longer applies — this is the branch itself. Without it the app doesn't boot at all on NC 34, so from my side this is ready to merge.