Opening PDF fails: The "documentType" parameter for the config object is invalid. Please correct it. #331

Activity

1. serge-vk commented on Jul 15, 2024

   

   serge-vk

   on Jul 15, 2024

   Last edited by serge-vk

   More actions

   Yes, I can confirm that I have this issue as well on v28.0.7 and OnlyOffice app v9.3.0. This may be due to an older version of OnlyOffice server, which in my case was not updated for a while, but I am not sure.
   ...
   Actually, I googled a bit, and it does seem to be an issue with the OnlyOffice server that needs to be updated. There are a few threads discussing this.
2. rsedlmeier commented on Jul 30, 2024

   

   rsedlmeier

   on Jul 30, 2024

   More actions

   Many thanks, that workaround helps
3. Qnap66 commented on Nov 6, 2024

   

   Qnap66

   on Nov 6, 2024

   More actions

   Je ne parviens actuellement pas à ouvrir un PDF, DOCXF, OFORM dans NextCloud avec OpenOffice et Community Document Server installés.

   Informations système :

   Nextcloud : v30.0.1
   OnlyOffice v9.5.0
   Serveur de documents communautaire v0.1.18
   Comme il s’agit d’une instance Nextcloud gérée, je ne peux pas modifier les fichiers de configuration ou mettre à niveau les versions antérieures.
4. joshtrichards

   added

   bugSomething isn't workingSomething isn't working

   on Mar 3, 2025
5. ballerbude commented on Nov 11, 2025

   

   ballerbude

   on Nov 11, 2025

   Last edited by ballerbude

   More actions

   I have the same issue. When I go to administration settings, configure ONLYOFFICE and uncheck "pdf", then press save, and then return to the ONLYOFFICE settings, the "pdf" is still checked. It looks like it's impossible to uncheck it.

   EDIT: Okay, after emptying the browser cache, it seems that unchecking the PDF handling worked.
6. chadek commented on Sep 15, 2026

   

   chadek

   on Sep 15, 2026

   Collaborator

   More actions

   Fixed for v0.4.0, by #387. The part of your report that matters is the last sentence — "when any option is changed and the settings saved, on reload they appear back checked" — which is a bug in this app, not in the connector.

   What was wrong. AutoConfig::autoConfigIfNeeded() runs from boot(), so on every request, and it re-applied syncSupportedFormats() against a hardcoded list. Anything the admin had enabled or disabled that the list did not agree with was switched back by the next page load:

   admin enables pdf/docm/html editing:   pdf=True  docm=True  html=True
   -> loading the files app once:         pdf=False docm=False html=False
   

   So unchecking PDF under "The default application for opening the format" — your workaround — held until you navigated anywhere, and then came back.

   The list had gone stale as well. It predated 9.x and named twelve editable formats where the bundled server declares twenty-nine, and three of the twelve (doc, ppt, xls) it cannot edit at all, only auto-convert.

   What changed. Formats are seeded once, at initial auto-configuration, from the format matrix the bundled document server actually ships, and never touched again — from there the admin owns them. Seeding still earns its keep because the connector leaves the lossy-editable formats (odt, ods, odp, csv, rtf, txt) off by default. Default openers stay a curated ten rather than following capability, since making OnlyOffice the default handler for .txt or .html would fight Nextcloud's own apps. A fresh install now seeds 29 editable formats where it seeded 12.

   An instance configured before this — yours — is repaired on upgrade to 0.4.0, but only when its settings still hold exactly what the old code wrote. Anything else is a choice somebody made, and is left alone.

   Proof. tests/rig/formats_test.py, run against master just now on Nextcloud 34 with connector 10.1. It checks four things in order: the seed a fresh install gets; that an admin's own choice survives page loads; that the setting reaches the editor (read from the connector's own config response, where a format decision shows up as editorConfig.mode); and the repair, by driving two real occ upgrade runs — repair steps are not part of occ maintenance:repair, so an app's installed version being behind info.xml is the only thing that carries them.

      PASS  formats         42s
   

   This does not by itself explain the documentType error in your title — that is the connector deciding what to do with a PDF — but it does mean your workaround now sticks: unchecking PDF stays unchecked. If you are still on a managed instance and can try 0.4.0, I would like to know whether the error survives the upgrade, since the bundled server now declares pdf editable where the old hardcoded list did not.
7. chadek

   closed this as completedin #400on Sep 16, 2026