Remove the “Calendar” menu item

[SanchiezesCode]

Hi everyone,

How to remove the “Calendar” menu item from the main menu (not from the admin panel)?
Could someone please explain?

Thanks in advance for your help!

[JammingBen]

There is no config to hide the menu item. You could make it work with some custom CSS and simply hide the menu item. See https://docs.opencloud.eu/docs/dev/web/getting-started#styles and https://github.com/orgs/opencloud-eu/discussions/1726#discussioncomment-14869658 for details on how to add a custom CSS file. Your CSS would need to look like so:

[data-test-id="com.github.opencloud-eu.web.runtime.app-menu-item.Calendar"] {
    display: none;
}

[SanchiezesCode]

Thanks for the answer, but I still can’t fully understand.

I tested this CSS directly in the browser (via DevTools) and it works correctly — the Calendar menu item disappears. I’m running OpenCloud from the opencloud-compose setup (Docker). I’ve installed several plugins, including external-sites. I tried to add my custom CSS file into the plugin directory and reference it inside manifest.json, but it doesn’t seem to work.

Here’s my setup:

opt/opencloud-compose/.env

...
OC_CONFIG_DIR=/srv/opencloud-config
OC_DATA_DIR=/srv/opencloud-data
OC_APPS_DIR=/srv/opencloud-apps
...

Plugin directory

root@opencloud:~# ll /srv/opencloud-apps/external-sites/
total 20
drwxr-xr-x 3 root      root      4096 Nov  5 17:14 ./
drwxr-x--- 7 opencloud opencloud 4096 Nov  4 22:30 ../
-rw-r----- 1 root      root        99 Nov  5 17:14 hide-calendar.css
drwxr-xr-x 2 root      root      4096 Nov  5 00:01 js/
-rw-r--r-- 1 root      root       837 Nov  5 00:00 manifest.json

manifest.json

root@opencloud:~# head -n 5 /srv/opencloud-apps/external-sites/manifest.json 
{
  "entrypoint": "js/external-sites-Cpdcql5J.js",
  "config": {
    "href": "/srv/opencloud-apps/external-sites/hide-calendar.css",
    "sites": [

This configuration doesn’t seem to load the CSS file.

Question:
Is it possible to include a local CSS file (for example, hide-calendar.css) inside a plugin like external-sites?
Or is there a supported way to apply custom CSS globally in an OpenCloud installation (via Docker Compose)?

Any guidance or working example would be appreciated!

[JammingBen]

Adding styles like described in https://docs.opencloud.eu/docs/dev/web/getting-started/#styles is supposed to be done in the general web config, not in an app config. It would need to look something like this: https://github.com/opencloud-eu/web/blob/stable-4.2/dev/docker/opencloud.web.config.json (with the URLs adjusted and the added style of course). Then you can use the WEB_UI_CONFIG_FILE env var to specify a path to where this config file is located.

Is it possible to include a local CSS file (for example, hide-calendar.css) inside a plugin like external-sites?

You should be able to place the CSS file inside a plugin folder, yes. Just reference it in the global web config like described above, e.g. "href": "/assets/apps/external-sites/custom.css". The href should not be the path on your file system, but where the server is serving the app assets. It should be /assets/apps/{app-name}/. You can verify this by checking your browser network tab and looking for a file called external-sites.js if you have this app installed.

[SanchiezesCode]

I also additionally hide drawio and texteditor because users often click and create empty files)
Thank you for your help! You've been a great support to me! Everything is working fine now!

/opt/opencloud-compose/docker-compose.yml

...
    environment:
      WEB_UI_CONFIG_FILE: "/etc/opencloud/web-config.json"
...

/opt/opencloud-compose/.env

...
OC_CONFIG_DIR=/srv/opencloud-config
OC_DATA_DIR=/srv/opencloud-data
OC_APPS_DIR=/srv/opencloud-apps
...

/srv/opencloud-apps/external-sites/css/hide-calendar.css

[data-test-id="com.github.opencloud-eu.web.runtime.app-menu-item.Calendar"] {
    display: none;
}

/srv/opencloud-config/web-config.json

{
  "server": "https://example.com",
  "theme": "https://example.com/themes/opencloud/theme.json",
  "openIdConnect": {
    "metadata_url": "https://example.com/.well-known/openid-configuration",
    "authority": "https://example.com",
    "client_id": "web",
    "response_type": "code"
  },
  "options": {
    "contextHelpersReadMore": true
  },
  "apps": [
    "files",
    "text-editor",
    "pdf-viewer",
    "search",
    "external",
    "admin-settings",
    "epub-reader",
    "preview",
    "draw-io",
    "json-viewer",
    "unzip",
    "external-sites"
  ],
  "styles": [
    {
      "href": "/assets/apps/external-sites/css/hide-calendar.css"
    },
    {
      "href": "/assets/apps/external-sites/css/hide-drawio.css"
    },
    {
      "href": "/assets/apps/external-sites/css/hide-texteditor.css"
    }
  ]
}

[dubtec]

Thanks a lot for the suggestion, @JammingBen. If I may, I'd like to remind You of one of the goals of OpenCloud: Do one thing, and do it good. In my understanding that is File Sharing, see e.g. https://github.com/orgs/opencloud-eu/discussions/262#discussioncomment-12330165.

Therefore, I'd recommend to make the Calendar functionality disable-able. See, there are plenty of good caldav implementations out there, which can be easily hosted (Radicale, Baikal, etc.). Users can easily maintain this outside of OpenCloud. The installation / operation is a lot more easy than OpenCloud. (I've been running Baikal since 2012 on a Raspberry PI).

If one applies the solution suggested, that adds a hurdle to any version upgrade. Because, the changes maintained outside of the container may negatively impact any future change and users will be needed to cross-verify the other changes to the .css / .json mentioned here.

Please consider for a configuration option to enable / disable calendar. Even not having enabled Radicale in .env, should be sufficient.

[micbar]

Are you sure? The compose project needs to add this as a configurable env var. Just adding it to .env has no effect.

[SanchiezesCode]

Just to share my perspective: personally, I use a small custom Ansible role that not only applies all required changes automatically, but also handles the full deployment and configuration of the setup. This way I don’t need to modify anything manually, and updates are seamless — the role simply re-runs and brings everything to the desired state. For my setup this approach has been reliable and keeps maintenance to a minimum.

[dubtec]

Thanks for sharing, @micbar, I tried that now too and added the environment-toggle into my docker-compose. That also didn't make for the wished behaviour.

[dubtec]

Ah, I'm sorry, it seems it has not been released yet. Meaning it will be part of the upcoming rolling release in 2 weeks.

Hi @JammingBen,

I didn't see Your name in the release notes and therefore assume neither 5.0.0 nor 5.0.1 contain the change which we've been discussing here. Can You share if FRONTEND_DISABLE_RADICALE is included?

Thanks in advance & best regards

[JammingBen]

Hi,

hmm then maybe @micbar was right and it was released in a version before already. Either way, I just tested it in our compose project with the current version and it works as expected. Are you sure you correctly added the environment flag to the compose file?