Themes background don't stick with local images #23239

enoch85 opened this Issue Mar 14, 2016 · 11 comments


None yet

5 participants

enoch85 commented Mar 14, 2016

Steps to reproduce

  1. Upgrade from 8.2.2 to 9.0

Expected behaviour

The themes background image should stay the same

Actual behaviour

The themes background image are not used in the theme (visible) if it's local, but works with remote address.

Server configuration

Operating system:
Ubuntu Server 14.04
Web server:
Apache 2.4
MySQL 5.5
PHP version:
ownCloud version: (see ownCloud admin page)
Updated from an older ownCloud or fresh install:
Updated from 8.2.2
Where did you install ownCloud from:
ownCloud repos
Signing status (ownCloud 9.0 and above):

No errors have been found.

List of activated apps:

  - activity: 2.2.1
  - calendar: 1.0
  - comments: 0.2
  - contacts:
  - dav: 0.1.5
  - documents: 0.12.0
  - federatedfilesharing: 0.1.0
  - federation: 0.0.4
  - files: 1.4.4
  - files_pdfviewer: 0.8
  - files_sharing: 0.9.1
  - files_texteditor: 2.1
  - files_trashbin: 0.8.0
  - files_versions: 1.2.0
  - files_videoplayer: 0.9.8
  - firstrunwizard: 1.1
  - gallery: 14.5.0
  - mail: 0.3.0
  - notifications: 0.2.3
  - provisioning_api: 0.4.1
  - systemtags: 0.2
  - updatenotification: 0.1.0
  - encryption
  - external
  - files_external
  - templateeditor
  - user_external
  - user_ldap

The content of config/config.php:

    "system": {
        "instanceid": "ocdd06e12069",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
        "datadirectory": "\/var\/www\/owncloud\/data",
        "overwrite.cli.url": "https:\/\/\/owncloud",
        "dbtype": "mysql",
        "version": "",
        "dbname": "owncloud",
        "dbhost": "localhost",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "preview_libreoffice_path": "\/usr\/bin\/libreoffice",
        "default_language": "sv",
        "allow_user_to_change_display_name": true,
        "mail_smtpmode": "smtp",
        "mail_smtpauth": 1,
        "mail_smtphost": "",
        "mail_smtpport": "587",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "mail_from_address": "admin",
        "mail_domain": "",
        "forcessl": true,
        "mail_smtpsecure": "tls",
        "mail_smtpauthtype": "LOGIN",
        "theme": "fsgo",
        "maintenance": false,
        "secret": "***REMOVED SENSITIVE VALUE***",
        "forceSSLforSubdomains": true,
        "loglevel": 2,
        "app.mail.server-side-cache.enabled": true,
        "app.mail.imaplog.enabled": true,
        "logtimezone": "Europe\/Stockholm",
        "memcache.local": "\\OC\\Memcache\\Redis",
        "filelocking.enabled": "true",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "\/var\/run\/redis.sock",
            "port": 0,
            "timeout": 0,
            "dbindex": 0
        "appstore.experimental.enabled": true,
        "trashbin_retention_obligation": "30",
        "updatechecker": false

Are you using external storage, if yes which one: local/smb/sftp/...
Are you using encryption: yes/no
Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...

Client configuration

Chrome 49
Operating system:
Deepin 15 and Windows (tested both)


Web server error log

No error log

ownCloud log (data/owncloud.log)

No errors

Browser log

No error log



You mean relative vs absolute URLs ?

Can you click on that "../img/back.jpg" and find out what the full URL is ?
Usually the relative URL is relative to the CSS file itself. So if "styles.css" is inside the themes folder, then the path is relative to that.

@PVince81 PVince81 added the needs info label Mar 21, 2016
20xx commented Mar 22, 2016

Hi, I'm having exactly the same issue described.
The background image reference wasn't changed when updating from 8.2.2 to 9.0.

Is this related to Content Security Policy?

enoch85 commented Mar 22, 2016

@PVince81 I use the exact same settings as in 8.2.2.

drwxr-x--- 2 root www-data  4096 Oct 23 22:37 ./
drwxr-x--- 4 root www-data  4096 Dec  6 00:50 ../
-rw-r----- 1 root www-data 12519 Oct  4 16:22 apps.css
-rw-r----- 1 root www-data   913 Dec  6 00:58 header.css
-rw-r----- 1 root www-data   745 Mar 10 02:15 styles.css
root@en0ch:/var/www/owncloud/themes/custom/core/css# ll /var/www/owncloud/themes/custom/core/img/
total 504
drwxr-x--- 3 root www-data   4096 Mar 10 02:10 ./
drwxr-x--- 4 root www-data   4096 Dec  6 00:50 ../
drwxr-x--- 2 root www-data   4096 Jan  6 23:57 actions/
-rw-r----- 1 root www-data 363682 Sep 21  2015 back.jpg
-rw-r----- 1 root www-data   2910 Sep 21  2015 logo-icon.svg
-rw-r----- 1 root www-data   5051 Oct 21 03:50 logo.svg
-rw-r----- 1 root www-data 123125 Mar 10 02:10 tech.jpg

Have you changed something in 9.0?


I'm not aware of any theming related changes, but often there are security hardenings so it could be that.

@enoch85 @20xx can you guys check the network console and find the call that retrieves your background image from the theme ? Goal is to find out what the return code is and what the full URL is.
Either the URL is wrong, or it's blocked for some reason (wrong permissions, .htaccess restrictions, etc)

20xx commented Mar 23, 2016

bildschirmfoto 2016-03-23 um 14 20 14
bildschirmfoto 2016-03-23 um 14 22 07

The Full URL is correct, but I cannot load the image via this full URL directly (being redirected to login page)

In Firebug I receive this error on the landing page:

Content Security Policy: Settings of this page have blocked loading a resource on self
("script-src https:// 'unsafe-eval'").
onsubmit attribute on DIV element

Thanks for your support, Matthias


If you're getting a redirect when trying to access the full URL of the image, then either the permissions are wrong in your themes folder (the web server needs to be able to access it) or your web server config or .htaccess config is forbidding it somehow.

20xx commented Mar 23, 2016

bildschirmfoto 2016-03-23 um 14 31 03
bildschirmfoto 2016-03-23 um 14 31 16
bildschirmfoto 2016-03-23 um 14 31 26

Thanks, but I can open styles.css directly with the same permissions as sbit_one.jpg ...

enoch85 commented Mar 25, 2016

@PVince81 As I said earlier, nothing changed except the upgrade to 9.0 stable. I see this on several instances, not just mine.

The permissions are theese:

20xx commented Mar 26, 2016

bildschirmfoto 2016-03-26 um 09 20 40

Hi there, it works now. I had to adapt the main .htaccess file in the root directory.
there was no jpg extension in the expression below.
See screenshot:

# Rewrite rules forfront_controller_active
RewriteCond %{REQUEST_FILENAME} !\.(css|jpg|js|svg|gif|png|html|ttf|woff|ico)$

Is it possible to generally add "jpg" to this expression?

Best, Matthias

enoch85 commented Mar 26, 2016

@PVince81 Yes, this should go in the default settings of .htaccess as it breaks all the themes with custom background images that are jpg otherwise IMHO.

I can confirm that the fix works. Thanks @20xx!

@enoch85 enoch85 added a commit that referenced this issue Mar 26, 2016
@enoch85 enoch85 Fix for #23239
Without it it breaks all the themes with .jpg as background.
@enoch85 enoch85 added this to the 9.0.1-current-maintenance milestone Mar 26, 2016

Fix for 9.1 is in #23129

Backport for stable9.0: #23590

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment