nextcloud28: Forms page is blank #277206
Assignees
Labels
Comments
Ma27
added a commit
to Ma27/nixpkgs
that referenced
this issue
Dec 28, 2023
Closes NixOS#277206 The bug mentioned above was a symptom of the issue fixed here: when opening the `forms` app which is installed via `extraApps` (or the app store) the site wouldn't work because `.mjs` files had the wrong Content-Type. The actual problem got fixed already[1], however this config was not used for stuff from `/nix-apps` & `/store-apps` which had their own location section with only a `root ;` statement. In fact, this setup isn't strictly supported by Nextcloud upstream[2], so to fix this for good, I decided to follow the upstream suggestion for app directories outside the server root, i.e. linking them back into the store path. This means that the module generates a new derivation now with * `services.nextcloud.package` linked into it via `lndir`. * under `nix-apps` is a symlink to the link farm containing all apps from `services.nextcloud.extraApps`. * under `store-apps` is a symlink to `/var/lib/nextcloud/store-apps`. Since this is only used in the NixOS module that also configures this location for imperatively installed apps, this seems an OK thing to do. Successfully tested the change on a productive Nextcloud 28.0.1 with several apps installed via `extraApps` (`forms`, `cospend`, `maps`, `user_saml` and a few more). [1] 292c74c [2] https://docs.nextcloud.com/server/28/admin_manual/apps_management.html#using-custom-app-directories
13 tasks
SuperSandro2000
pushed a commit
to SuperSandro2000/nixpkgs
that referenced
this issue
Dec 29, 2023
Closes NixOS#277206 The bug mentioned above was a symptom of the issue fixed here: when opening the `forms` app which is installed via `extraApps` (or the app store) the site wouldn't work because `.mjs` files had the wrong Content-Type. The actual problem got fixed already[1], however this config was not used for stuff from `/nix-apps` & `/store-apps` which had their own location section with only a `root ;` statement. In fact, this setup isn't strictly supported by Nextcloud upstream[2], so to fix this for good, I decided to follow the upstream suggestion for app directories outside the server root, i.e. linking them back into the store path. This means that the module generates a new derivation now with * `services.nextcloud.package` linked into it via `lndir`. * under `nix-apps` is a symlink to the link farm containing all apps from `services.nextcloud.extraApps`. * under `store-apps` is a symlink to `/var/lib/nextcloud/store-apps`. Since this is only used in the NixOS module that also configures this location for imperatively installed apps, this seems an OK thing to do. Successfully tested the change on a productive Nextcloud 28.0.1 with several apps installed via `extraApps` (`forms`, `cospend`, `maps`, `user_saml` and a few more). [1] 292c74c [2] https://docs.nextcloud.com/server/28/admin_manual/apps_management.html#using-custom-app-directories
Ma27
added a commit
to Ma27/nixpkgs
that referenced
this issue
Dec 29, 2023
Closes NixOS#277206 The bug mentioned above was a symptom of the issue fixed here: when opening the `forms` app which is installed via `extraApps` (or the app store) the site wouldn't work because `.mjs` files had the wrong Content-Type. The actual problem got fixed already[1], however this config was not used for stuff from `/nix-apps` & `/store-apps` which had their own location section with only a `root ;` statement. In fact, this setup isn't strictly supported by Nextcloud upstream[2], so to fix this for good, I decided to follow the upstream suggestion for app directories outside the server root, i.e. linking them back into the store path. This means that the module generates a new derivation now with * `services.nextcloud.package` linked into it via `lndir`. * under `nix-apps` is a symlink to the link farm containing all apps from `services.nextcloud.extraApps`. * under `store-apps` is a symlink to `/var/lib/nextcloud/store-apps`. Since this is only used in the NixOS module that also configures this location for imperatively installed apps, this seems an OK thing to do. Successfully tested the change on a productive Nextcloud 28.0.1 with several apps installed via `extraApps` (`forms`, `cospend`, `maps`, `user_saml` and a few more). [1] 292c74c [2] https://docs.nextcloud.com/server/28/admin_manual/apps_management.html#using-custom-app-directories
SuperSandro2000
pushed a commit
to SuperSandro2000/nixpkgs
that referenced
this issue
Dec 29, 2023
Closes NixOS#277206 The bug mentioned above was a symptom of the issue fixed here: when opening the `forms` app which is installed via `extraApps` (or the app store) the site wouldn't work because `.mjs` files had the wrong Content-Type. The actual problem got fixed already[1], however this config was not used for stuff from `/nix-apps` & `/store-apps` which had their own location section with only a `root ;` statement. In fact, this setup isn't strictly supported by Nextcloud upstream[2], so to fix this for good, I decided to follow the upstream suggestion for app directories outside the server root, i.e. linking them back into the store path. This means that the module generates a new derivation now with * `services.nextcloud.package` linked into it via `lndir`. * under `nix-apps` is a symlink to the link farm containing all apps from `services.nextcloud.extraApps`. * under `store-apps` is a symlink to `/var/lib/nextcloud/store-apps`. Since this is only used in the NixOS module that also configures this location for imperatively installed apps, this seems an OK thing to do. Successfully tested the change on a productive Nextcloud 28.0.1 with several apps installed via `extraApps` (`forms`, `cospend`, `maps`, `user_saml` and a few more). [1] 292c74c [2] https://docs.nextcloud.com/server/28/admin_manual/apps_management.html#using-custom-app-directories
Ma27
added a commit
to Ma27/nixpkgs
that referenced
this issue
Dec 29, 2023
Closes NixOS#277206 The bug mentioned above was a symptom of the issue fixed here: when opening the `forms` app which is installed via `extraApps` (or the app store) the site wouldn't work because `.mjs` files had the wrong Content-Type. The actual problem got fixed already[1], however this config was not used for stuff from `/nix-apps` & `/store-apps` which had their own location section with only a `root ;` statement. In fact, this setup isn't strictly supported by Nextcloud upstream[2], so to fix this for good, I decided to follow the upstream suggestion for app directories outside the server root, i.e. linking them back into the store path. This means that the module generates a new derivation now with * `services.nextcloud.package` linked into it via `lndir`. * under `nix-apps` is a symlink to the link farm containing all apps from `services.nextcloud.extraApps`. * under `store-apps` is a symlink to `/var/lib/nextcloud/store-apps`. Since this is only used in the NixOS module that also configures this location for imperatively installed apps, this seems an OK thing to do. Successfully tested the change on a productive Nextcloud 28.0.1 with several apps installed via `extraApps` (`forms`, `cospend`, `maps`, `user_saml` and a few more). [1] 292c74c [2] https://docs.nextcloud.com/server/28/admin_manual/apps_management.html#using-custom-app-directories (cherry picked from commit bae5e65)
SuperSandro2000
pushed a commit
to SuperSandro2000/nixpkgs
that referenced
this issue
Dec 29, 2023
Closes NixOS#277206 The bug mentioned above was a symptom of the issue fixed here: when opening the `forms` app which is installed via `extraApps` (or the app store) the site wouldn't work because `.mjs` files had the wrong Content-Type. The actual problem got fixed already[1], however this config was not used for stuff from `/nix-apps` & `/store-apps` which had their own location section with only a `root ;` statement. In fact, this setup isn't strictly supported by Nextcloud upstream[2], so to fix this for good, I decided to follow the upstream suggestion for app directories outside the server root, i.e. linking them back into the store path. This means that the module generates a new derivation now with * `services.nextcloud.package` linked into it via `lndir`. * under `nix-apps` is a symlink to the link farm containing all apps from `services.nextcloud.extraApps`. * under `store-apps` is a symlink to `/var/lib/nextcloud/store-apps`. Since this is only used in the NixOS module that also configures this location for imperatively installed apps, this seems an OK thing to do. Successfully tested the change on a productive Nextcloud 28.0.1 with several apps installed via `extraApps` (`forms`, `cospend`, `maps`, `user_saml` and a few more). [1] 292c74c [2] https://docs.nextcloud.com/server/28/admin_manual/apps_management.html#using-custom-app-directories
github-actions bot
pushed a commit
that referenced
this issue
Dec 29, 2023
Closes #277206 The bug mentioned above was a symptom of the issue fixed here: when opening the `forms` app which is installed via `extraApps` (or the app store) the site wouldn't work because `.mjs` files had the wrong Content-Type. The actual problem got fixed already[1], however this config was not used for stuff from `/nix-apps` & `/store-apps` which had their own location section with only a `root ;` statement. In fact, this setup isn't strictly supported by Nextcloud upstream[2], so to fix this for good, I decided to follow the upstream suggestion for app directories outside the server root, i.e. linking them back into the store path. This means that the module generates a new derivation now with * `services.nextcloud.package` linked into it via `lndir`. * under `nix-apps` is a symlink to the link farm containing all apps from `services.nextcloud.extraApps`. * under `store-apps` is a symlink to `/var/lib/nextcloud/store-apps`. Since this is only used in the NixOS module that also configures this location for imperatively installed apps, this seems an OK thing to do. Successfully tested the change on a productive Nextcloud 28.0.1 with several apps installed via `extraApps` (`forms`, `cospend`, `maps`, `user_saml` and a few more). [1] 292c74c [2] https://docs.nextcloud.com/server/28/admin_manual/apps_management.html#using-custom-app-directories (cherry picked from commit bae5e65)
SuperSandro2000
pushed a commit
to SuperSandro2000/nixpkgs
that referenced
this issue
Dec 30, 2023
Closes NixOS#277206 The bug mentioned above was a symptom of the issue fixed here: when opening the `forms` app which is installed via `extraApps` (or the app store) the site wouldn't work because `.mjs` files had the wrong Content-Type. The actual problem got fixed already[1], however this config was not used for stuff from `/nix-apps` & `/store-apps` which had their own location section with only a `root ;` statement. In fact, this setup isn't strictly supported by Nextcloud upstream[2], so to fix this for good, I decided to follow the upstream suggestion for app directories outside the server root, i.e. linking them back into the store path. This means that the module generates a new derivation now with * `services.nextcloud.package` linked into it via `lndir`. * under `nix-apps` is a symlink to the link farm containing all apps from `services.nextcloud.extraApps`. * under `store-apps` is a symlink to `/var/lib/nextcloud/store-apps`. Since this is only used in the NixOS module that also configures this location for imperatively installed apps, this seems an OK thing to do. Successfully tested the change on a productive Nextcloud 28.0.1 with several apps installed via `extraApps` (`forms`, `cospend`, `maps`, `user_saml` and a few more). [1] 292c74c [2] https://docs.nextcloud.com/server/28/admin_manual/apps_management.html#using-custom-app-directories
marcusramberg
pushed a commit
to marcusramberg/nixpkgs
that referenced
this issue
Dec 30, 2023
Closes NixOS#277206 The bug mentioned above was a symptom of the issue fixed here: when opening the `forms` app which is installed via `extraApps` (or the app store) the site wouldn't work because `.mjs` files had the wrong Content-Type. The actual problem got fixed already[1], however this config was not used for stuff from `/nix-apps` & `/store-apps` which had their own location section with only a `root ;` statement. In fact, this setup isn't strictly supported by Nextcloud upstream[2], so to fix this for good, I decided to follow the upstream suggestion for app directories outside the server root, i.e. linking them back into the store path. This means that the module generates a new derivation now with * `services.nextcloud.package` linked into it via `lndir`. * under `nix-apps` is a symlink to the link farm containing all apps from `services.nextcloud.extraApps`. * under `store-apps` is a symlink to `/var/lib/nextcloud/store-apps`. Since this is only used in the NixOS module that also configures this location for imperatively installed apps, this seems an OK thing to do. Successfully tested the change on a productive Nextcloud 28.0.1 with several apps installed via `extraApps` (`forms`, `cospend`, `maps`, `user_saml` and a few more). [1] 292c74c [2] https://docs.nextcloud.com/server/28/admin_manual/apps_management.html#using-custom-app-directories
SuperSandro2000
pushed a commit
to SuperSandro2000/nixpkgs
that referenced
this issue
Dec 31, 2023
Closes NixOS#277206 The bug mentioned above was a symptom of the issue fixed here: when opening the `forms` app which is installed via `extraApps` (or the app store) the site wouldn't work because `.mjs` files had the wrong Content-Type. The actual problem got fixed already[1], however this config was not used for stuff from `/nix-apps` & `/store-apps` which had their own location section with only a `root ;` statement. In fact, this setup isn't strictly supported by Nextcloud upstream[2], so to fix this for good, I decided to follow the upstream suggestion for app directories outside the server root, i.e. linking them back into the store path. This means that the module generates a new derivation now with * `services.nextcloud.package` linked into it via `lndir`. * under `nix-apps` is a symlink to the link farm containing all apps from `services.nextcloud.extraApps`. * under `store-apps` is a symlink to `/var/lib/nextcloud/store-apps`. Since this is only used in the NixOS module that also configures this location for imperatively installed apps, this seems an OK thing to do. Successfully tested the change on a productive Nextcloud 28.0.1 with several apps installed via `extraApps` (`forms`, `cospend`, `maps`, `user_saml` and a few more). [1] 292c74c [2] https://docs.nextcloud.com/server/28/admin_manual/apps_management.html#using-custom-app-directories
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
The extraApp called
formsdisplays as blank.This was working fine on nextcloud27.
Rest of the site is working fine.
Steps To Reproduce
Steps to reproduce the behavior:
'github:NixOS/nixpkgs/5f64a12a728902226210bf01d25ec6cbb9d9265b' (2023-12-24)formsinextraAppsExpected behavior
It should display the normal forms page.
Screenshots
Additional context
Found non-nixos issue relating to it here:
Seems it may be a
content-typerelated issue?Notify maintainers
@schneefux @bachp @globin @Ma27
Metadata
Please run
nix-shell -p nix-info --run "nix-info -m"and paste the result.Add a 👍 reaction to issues you find important.
The text was updated successfully, but these errors were encountered: