Custom theme: odd folder icon color and default favicon

[mcnesium]

Steps to reproduce

1. create custom theme folder
2. copy content of /core/img/filetypes/ to themes/mytheme/core/img/filetypes/ and change ie. the value fill="#123456" of folder.svg
3. add 'theme' => 'mytheme', to config
4. delete data/appdata_xxxxxxxxxx/theming
5. reload web application

Expected behaviour

Custom folder icons and favicon should show up

Actual behaviour

Folder icons are loaded i.e. from /index.php/apps/theming/img/core/filetypes/folder.svg, a path that does not even fully exist. /index.php/apps/theming/img/ does and there is just one file app.svg in it, which in turn is not able to be loaded in the browser.

The shown folder icons do not have the color set in the SVG files of the theme but the same value as set in public function getMailHeaderColor() in mytheme/defaults.php.

Also, the favicon and apple-touch-icon is loaded from /core/img/ even though there are all of those files in mytheme/core/img:

favicon-touch.png
favicon-touch.svg
favicon.ico
favicon.png
favicon.svg

I have noticed this behavior on multiple nextcloud instances I maintain both v11.0.0 and v11.0.1 so I am sure this has nothing to do with odd local config, but I will post the details of one instance to follow directions…

Apache2.4, PHP5/7, Mariadb 10, both fresh nc 11 and updated from nc 10, and even from oc, no external storage, no encryption, no external user-backend, no ldap, all browsers, all os, no output in apache error.log or nextcloud.log

### app:list (of one

• activity: 2.4.1
• calendar: 1.4.1
• comments: 1.1.0
• contacts: 1.5.2
• dav: 1.1.1
• direct_menu: 0.10.0
• federatedfilesharing: 1.1.1
• federation: 1.1.1
• files: 1.6.1
• files_pdfviewer: 1.0.1
• files_sharing: 1.1.1
• files_texteditor: 2.2
• files_trashbin: 1.1.0
• files_versions: 1.4.0
• files_videoplayer: 1.0.0
• firstrunwizard: 2.0
• gallery: 16.0.0
• logreader: 2.0.0
• lookup_server_connector: 1.0.0
• mail: 0.6.2
• nextcloud_announcements: 1.0
• notifications: 1.0.1
• password_policy: 1.1.0
• provisioning_api: 1.1.0
• serverinfo: 1.1.1
• sharebymail: 1.0.1
• survey_client: 0.1.5
• systemtags: 1.1.3
• templateeditor: 0.2
• theming: 1.1.1
• twofactor_backupcodes: 1.0.0
• updatenotification: 1.1.1
• workflowengine: 1.1.1

config.php

<?php
$CONFIG = array (
    'instanceid' => 'xxx',
    'passwordsalt' => 'xxx',
    'secret' => 'xxx',
    'trusted_domains' => 
    array (
      0 => 'cloud.domain',
    ),
    'datadirectory' => '/usr/local/owncloud',
    'overwrite.cli.url' => 'https://cloud.domain',
    'dbtype' => 'mysql',
    'version' => '11.0.1.2',
    'dbname' => 'owncloud',
    'dbhost' => 'localhost',
    'dbtableprefix' => 'oc_',
    'dbuser' => 'owncloud',
    'dbpassword' => '***',
    'logtimezone' => 'UTC',
    'installed' => true,
    'memcache.local' => '\\OC\\Memcache\\APCu',
    'appstore.experimental.enabled' => true,
    'mail_smtpmode' => 'smtp',
    'mail_from_address' => 'nextcloud',
    'mail_domain' => 'cloud.domain',
    'mail_smtphost' => 'mail.server',
    'mail_smtpport' => '587',
    'loglevel' => 1,
    'filesystem_check_changes' => 1,
    'maintenance' => false,
    'updatechecker' => false,
    'theme' => 'mytheme',
    'app.mail.smtplog.enabled' => true,
    'mail_smtpsecure' => 'tls',
    'mail_smtpauthtype' => 'PLAIN',
    'mail_smtpauth' => 1,
    'mail_smtpname' => 'xxx',
    'mail_smtppassword' => 'xxx',
    'updater.secret' => 'xxx',
);

browser console

 "/index.php/apps/files/", search: "?dir=/" }  bootstrap.js:37

Content Security Policy: Directive ‘frame-src’ has been deprecated. Please use directive ‘child-src’ instead.  (unknown)
Sending message that cannot be cloned. Are you trying to send an XPCOM object?  MessageChannel.jsm:504:4
“nsICookieManager2.getCookiesFromHost()” is changed. Update your code and pass the correct originAttributes. Read more on MDN: https://developer.mozilla.org/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsICookieManager2  cookietracker.js:126:12
“nsICookieManager2.getCookiesFromHost()” is changed. Update your code and pass the correct originAttributes. Read more on MDN: https://developer.mozilla.org/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsICookieManager2  cookietracker.js:82:12
JQMIGRATE: Migrate is installed, version 1.4.0  jquery-migrate.min.js:2:542

"ObjectActor.prototype.grip previewer function threw an exception: Error: Permission denied to access object
Stack: PseudoArray@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/object.js:1799:16
ObjectActor.prototype.grip@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/object.js:131:15
WCA_objectGrip@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webconsole.js:484:12
createValueGrip@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/object.js:2149:14
WCA_createValueGrip@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webconsole.js:430:12
WCA_objectGrip/actor<.createValueGrip@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webconsole.js:477:29
DOMEvent@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/object.js:1766:36
ObjectActor.prototype.grip@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/object.js:131:15
WCA_objectGrip@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webconsole.js:484:12
createValueGrip@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/object.js:2149:14
WCA_createValueGrip@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webconsole.js:430:12
WCA_prepareConsoleMessageForRemote/result.arguments<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webconsole.js:1696:14
WCA_prepareConsoleMessageForRemote@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webconsole.js:1694:24
WCA_onConsoleAPICall@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webconsole.js:1502:16
ConsoleAPIListener.prototype.observe@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/webconsole/utils.js:865:5
CS_recordEvent@resource://gre/components/ConsoleAPIStorage.js:137:5
sendConsoleAPIMessage@resource://gre/modules/Console.jsm:584:5
createMultiLineDumper/<@resource://gre/modules/Console.jsm:514:5
logPrototype@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///home/me/.mozilla/firefox/euy860b6.default/extensions/passff@invicem.pro.xpi!/bootstrap.js:37:7
Line: 0, column: 0"  ThreadSafeDevToolsUtils.js:80
 HTMLDocument → files, NONE: 0 } false 1  bootstrap.js:37
Sending message that cannot be cloned. Are you trying to send an XPCOM object?  MessageChannel.jsm:504:4

 "/index.php/apps/files/", search: "?dir=/&fileid=2" }  bootstrap.js:37

[nickvergessen]

You really should not manually delete items from data/appdata_*

@rullzer same as with previews

[mcnesium]

If I had not deleted those items, I would not have found out that the folder icon color depends on that getMailHeaderColor() function ;)

[nickvergessen]

@nextcloud/theming

[rullzer]

@nickvergessen well I still don't know what to do about it 😉 if people remove stuff from their data folder then yeah... stuff will break...

[juliusknorr]

@mcnesium You should disable the theming app if you use a custom theme. Otherwise there are conflicts which images will be used. Once disabled, the icons from your theme should be used instead of the generated ones.

[mcnesium]

@rullzer I did not remove stuff from the data folder just for the lulz, but because the theme did not look as expected and I was trying to find out why that is, instead of just complaining about it. And since a new folder appeared after removing the old one and reloading the browser, I was assuming this is some kind of cache folder and it is propably okay to do so.

[mcnesium]

@juliushaertl good call. Though, the theming page in the admin section said something like "you are using a custom theme" and no other setting is shown, so I assumed it to notice that by itself.

[juliusknorr]

@mcnesium You are right, I guess we could improve there or at least make it more visible that there might be conflicts.

[nickvergessen]

@juliushaertl Or we simply disable the theming app when we detect this case? And add it to the description on the app management that the app can not be used when a theme is enabled?

[rullzer]

@mcnesium I did not say you did it just for fun I was just stating that it is very hard for Nextcloud to do its thing then. If you would rescan the files (using occ) it should correct itself.

[nickvergessen]

I just tried it:

./occ files:scan --path="/appdata_ocm0u67bw3lj"
Unknown user 1 appdata_ocm0u67bw3lj

Seems like the scanning needs some fixing before.

[rullzer]

O... joy...

[mcnesium]

Sorry guys, it's not over yet :(

After I disabled the theming app, the favicons from /themes/mytheme/img appeared in the browser tabs. A little while later I noticed that the folder icons were all default blue and being loaded from /core/img/filetypes/. So either I did not pay enough attention to notice it in the first place, or maybe the Cronjob does some other magic there.

Anyways, by now none of my custom-themed Nextcloud instances use the files in the Theme's filetypes folder. After I read this but before I could read this I did occ files:scan --all on one instance and then actually started working today, but tonight the folder icons are still the default blue core ones :(

[jancborchardt]

@juliushaertl what do you think about this: When a custom theme is used which is not from the theming app:

• there’s a text on top which says »A custom theme is used. Since that might cause conflicts with these values, it’s disabled«.
• then next to it a button »Override custom theme with these values«
• the theming settings are greyed out

[juliusknorr]

@mcnesium have you been running ./occ maintenance:mimetype:update-js? This is required to push the added mimetype icons to a javascript file.

@jancborchardt I need to have a look how the custom themes are applied, but I like the idea in general.

[fancycode]

+1 to handle custom themes in the theming app without manual interaction.

In automatic deployments you can pre-populate the theme in config.php but then would have to disable the theming app manually (from what I understand).

[mcnesium]

What I just did:

• run sudo -u www-data php occ maintenance:mimetype:update-js+ reload -> still default icons
• notice that SVG files of core and theme differ in syntax (propably because the theme ones are there since v9)
• rsync core filetypes folder with theme filetypes folder
• change colors in every SVG file using sed
• run above update-js command again + reload -> hooray new colored icons in files view

So thx @juliushaertl for that hint 👍 This should be added to the docs imho.

[mammuth]

I followed the steps @mcnesium described in his latest comment, but I'm still facing the blue default icons.

My setup:

• NC 11.0.2
• custom theme
• theme app is disabled
• modified favicon in /mytheme/core/img/
• modified folder icons in /mytheme/core/img/filetypes/

I did:

• copy core filetypes-icons to the theme and change their fill-color
• occ maintenance:mimetype:update-js
• restart apache
• clear browser cache

Expected: Theme filetype icons. Actual: blue default icons.

Regarding the favicon, I have a different behavior than @mcnesium.
I experience the favicon to be loaded from /index.php/apps/theming/favicon/files?v=5 although the theming app is disabled.

The favicon path to the theming app sounds like there is still something cached? Restarting apache should clear APCu cache I guess, so I'm not sure what my problem is.

[juliusknorr]

So thx @juliushaertl for that hint  This should be added to the docs imho.

@mcnesium Pull requests are always welcome. 😉

The favicon path to the theming app sounds like there is still something cached? Restarting apache should clear APCu cache I guess, so I'm not sure what my problem is.

@mammuth Not sure about that. Maybe @MorrisJobke or @rullzer can help on that?

[rebeccaformfx]

Hi! I am running into this same problem with NextCloud 12. This is very annoying... I'd really like to use my own SVGs in the UI and I can't ask my server admin to run a command every time I want to preview image changes...

[MorrisJobke]

Fixed in #5070

[fuanegua]

Guys, thank you so much for this workflow. It still works fine on 17.0.2 except the folder-external.svg.
It stays in default blue. After refreshing the page it changes its color into the new one just for a short moment. Then it turns back into the default blue. So the icon seems to be loaded from the theme folder and seems to be overwritten afterwards.

Does anybody know the problem? Thanks for any help!