Server: Custom theme: odd folder icon color and default favicon

Created on 16 Jan 2017 · 22Comments · Source: nextcloud/server

Steps to reproduce

create custom theme folder
copy content of /core/img/filetypes/ to themes/mytheme/core/img/filetypes/ and change ie. the value fill="#123456" of folder.svg
add 'theme' => 'mytheme', to config
delete data/appdata_xxxxxxxxxx/theming
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/[email protected]!/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

bug theming

Source

mcnesium

👍2

All 22 comments

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

@rullzer same as with previews

nickvergessen on 16 Jan 2017

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

mcnesium on 16 Jan 2017

@nextcloud/theming

nickvergessen on 17 Jan 2017

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

rullzer on 18 Jan 2017

@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.

juliushaertl on 18 Jan 2017

👍1

@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 on 18 Jan 2017

@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.

mcnesium on 18 Jan 2017

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

juliushaertl on 18 Jan 2017

@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?

nickvergessen on 18 Jan 2017

@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.

rullzer on 18 Jan 2017

I just tried it:

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

Seems like the scanning needs some fixing before.

nickvergessen on 18 Jan 2017

O... joy...

rullzer on 18 Jan 2017

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 :(

mcnesium on 18 Jan 2017

@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

jancborchardt on 18 Jan 2017

@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.

juliushaertl on 16 Feb 2017

+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).

fancycode on 17 Feb 2017

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.

mcnesium on 17 Feb 2017

👍1

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.

mammuth on 19 Mar 2017

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

@mcnesium Pull requests are always welcome. :wink:

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?

juliushaertl on 30 Apr 2017

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...

rebeccaformfx on 24 Jun 2017

Fixed in #5070

MorrisJobke on 13 Jul 2017

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!