Closed croessner closed 7 years ago
Thanks for the detailed report!
The bug is already fixed in the stable12 branch (see #6067), so it will be fixed in the next Nextcloud 12 maintenance release :-)
Thank you very much :-) I am happily looking forward to the next release.
Just tested theming in NC-12.0.3RC2 and it still does not work :-(
I can chose a logo and it tells that it got saved, but it is not used by NC. If logging out and back in, it still shows the default NC logo and background. So the issue is still open
Also the preview shows a broken image link in the thumbnail.
@danxuliu can you please re-open this issue?
I think this really should be fixed before releasing 12.0.3, as it exists since 11 release now.
Here is my nginx config
fastcgi_cache_path /var/cache/nginx/nextcloud levels=1:2 keys_zone=nextcloud:100m inactive=60m;
fastcgi_cache_key $scheme$request_method$host$request_uri;
map $request_uri $skip_cache {
default 1;
~*/thumbnail.php 0;
~*/apps/galleryplus/ 0;
~*/apps/gallery/ 0;
}
if_modified_since before;
# output compression saves bandwidth
gzip on;
gzip_vary on;
gzip_comp_level 4;
gzip_proxied any;
gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;
gzip_min_length 256;
# make sure gzip does not lose large gzipped js or css files
# see http://blog.leetsoft.com/2007/07/25/nginx-gzip-ssl.html
gzip_buffers 16 8k;
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
server {
listen 134.255.226.244:443 ssl http2;
listen [2a05:bec0:28:1:134:255:226:244]:443 ssl http2;
server_name cloud.roessner-net.de;
root /var/www/localhost/htdocs/nextcloud;
ssl on;
ssl_certificate /etc/letsencrypt/live/cloud.roessner-net.de/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/cloud.roessner-net.de/privkey.pem;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
ssl_dhparam /etc/ssl/private/dhparams.pem;
# OCSP Stapling ---
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;
#ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;
resolver 134.255.226.242;
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains";
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
add_header X-Robots-Tag none;
add_header X-Download-Options noopen;
add_header X-Permitted-Cross-Domain-Policies none;
add_header Referrer-Policy "same-origin";
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}
# The following 2 rules are only needed for the user_webfinger app.
# Uncomment it if you're planning to use this app.
#rewrite ^/.well-known/host-meta /nextcloud/public.php?service=host-meta last;
#rewrite ^/.well-known/host-meta.json /nextcloud/public.php?service=host-meta-json last;
location = /.well-known/carddav {
return 301 $scheme://$host/nextcloud/remote.php/dav;
}
location = /.well-known/caldav {
return 301 $scheme://$host/nextcloud/remote.php/dav;
}
client_max_body_size 10250M;
# Uncomment if your server is build with the ngx_pagespeed module
# This module is currently not supported.
#pagespeed off;
error_page 403 /core/templates/403.php;
error_page 404 /core/templates/404.php;
location / {
rewrite ^ /index.php$uri;
}
# Spreed WebRTC
location ^~ /webrtc {
proxy_pass http://127.0.0.1:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_buffering on;
proxy_ignore_client_abort off;
proxy_redirect off;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
proxy_next_upstream error timeout invalid_header http_502 http_503 http_504;
}
location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)/ {
deny all;
}
location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
deny all;
}
location ~ ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+)\.php(?:$|/) {
fastcgi_split_path_info ^(.+\.php)(/.*)$;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param HTTPS on;
#Avoid sending the security headers twice
fastcgi_param modHeadersAvailable true;
fastcgi_param front_controller_active true;
fastcgi_param front_controller_active true;
fastcgi_pass unix:/var/run/php5-fpm-system.sock;
fastcgi_intercept_errors on;
fastcgi_request_buffering off;
fastcgi_buffers 64 64K;
fastcgi_buffer_size 256k;
fastcgi_cache_key $http_cookie$request_method$host$request_uri;
fastcgi_cache_use_stale error timeout invalid_header http_500;
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
fastcgi_cache nextcloud;
fastcgi_param PHP_VALUE "upload_max_filesize = 10250M post_max_size = 10240M max_execution_time = 3600";
}
location ~ ^/(?:updater|ocs-provider)(?:$|/) {
try_files $uri/ =404;
index index.php;
}
# Adding the cache control header for js and css files
# Make sure it is BELOW the PHP block
location ~ \.(?:css|js|woff|svg|gif)$ {
try_files $uri /index.php$uri$is_args$args;
add_header Cache-Control "public, max-age=15778463";
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains";
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
add_header X-Robots-Tag none;
add_header X-Download-Options noopen;
add_header X-Permitted-Cross-Domain-Policies none;
add_header Referrer-Policy "same-origin";
# Optional: Don't log access to assets
access_log off;
}
location ~ \.(?:png|html|ttf|ico|jpg|jpeg)$ {
try_files $uri /index.php$uri$is_args$args;
# Optional: Don't log access to other assets
access_log off;
}
access_log /var/log/nginx/access_ssl-nextcloud.log main;
error_log /var/log/nginx/error_ssl-nextcloud.log info;
}
I can't test 12.0.4 here but in 13beta at least it works flawlessly.
(background pic is Banana Bungalow in San Diego - location where in Jan 2010 oC was announced by Frank - 🎂 now 8 years ago)
Are you sure nothing is broken on your server? Our company server is also already upgraded to 13Beta otherwise I could simply show you there that it works, there, too...
I did test it on demo.nextcloud.com and it works without issues there so it must be a config on your side...
I just installed the latest stable release (12.0.4snap1 4371) and it's broken.
The small logo in the upper left corner (when you are logged in) is updated correctly, but the big logo in the login page and the background image remain the default ones. Also the preview is never shown and the status remains at "Loading preview…" forever. No error is logged in the console nor in the system logs.
Edit: is this an issue with the snap package not being able to write the files into the webroot?
Ah, you use the Snap? @croessner you too? If so, then it should be filed as an issue there...
@jospoortvliet well I suppose most people coming here with user-level feedback are using the snap, since it's the recommended way to install Nextcloud, according to the documentation.
Here's the snap issue
If the snap is the default install method, why is it a second class citizen for release testing? Next cloud version bumps should probably depend on issues being cleared up there as well since it seems pathologically behind and broken compared to docker or manual methods.
I don't believe we say Snap is the recommended way, the docs just say that if there are no packages and you don't want to use the tarball, you can use snaps... But yeah, we could put more effort in making the Snap work well, that's true. At the moment our primary 'product' is still the zip/tar file.
After upgrading 13.0.0.1 having exact same issue. i can see uploaded logo in small window but no change, even can't see background at all. I did fresh install and straight to theming. The only change i made prior to my previous installation is i've upgraded my php version from 7.0 to 7.2 don't know whether related with php version or new release. Would be great if someone can confirm this is working stable in 13.0.0.1 ?
Same here with a fresh install of 13.0.1.
I'm using the official VM.
Fresh install of 13.0.1 and same problem. I can see the correct logo when hovering in the console, still not beeing displayed. Console gives SourceMap Error. As well the errorlog is flodded with:
Error | no app in context | issuetemplate |
---|
EDIT: Everything shows up fine in the app!
Fresh install from Nextcloud VM scripts, 13.0.1, no way to display custom color logo or background on web GUI. Title and url ok. background and color in app ok. web app is the affected part.
Same here! 13.01. just previews the color and login-image under Settings-Theming, but does not actually use it then....
Maybe I have solution. I did fresh install of 13.0.1, tried to change logo and background, but nothing happend. After that I have instaled Unsplash app, turn it ON and logouted. And so I have changes on the first page! After that I turned it OFF and got changes of logo and background. Try this solution please.
That's totally weird... It is working just fine here, I can't reproduce the issue with a normal install, but perhaps it is something in the VM; if that is the case @enoch85 should know/test this! :rocket:
I can confirm that the installation of any app does solve the problem. @jospoortvliet yes, i´ve been installing via the vm on a fresh ubuntu 16.04. Thanks! 👍
Same here!
I did fresh a install of 13.0.1, tried to change logo and background, but nothing happend. (vm)
The workaround with the Unsplash app is only working for the Logo. Background isn´t working...
The Theming App works fine! The problem is the image cache. The trick, changing the logo and background image in the Theming App and then enabling and disabling the Unsplash App, seams to update the image cache.
As described in the theming doc it may be necessary to update the image cache. This is done by executing:
sudo -u www-data php occ maintenance:theme:update
had the same issue, latest NC 13.0.1, using wonderfall/nextcloud docker image.
enabling and disabling Unsplash app did the trick for me (for logo AND background image), command maintenance:theme:update
did not work for me, so unsplash app seems to do a bit more..
Noticed this exact issue today. You can force your theme changes to update by removing or renaming the data/appdata_(instanceid)
and data/updater-(instanceid)
directories and then resetting whichever application cache you're using, usually by restarting your web service.
It's pretty annoying to have to do this, and I hope it gets fixed, but hopefully this helps some people. Plus, it's a little more sustainable than the "install a new app to force the update" workaround since it only seems to work the first time you install a given app.
I'm using NextCloud 13.0.2 on Debian Stretch and neither installing and enabling then disabling Unsplash worked nor removing the data/appdata_(instanceid) directory. Changing the name, slogan, URL, or logo in the Theming app has no effect. php occ config:list shows the changes but the interface itself does not change.
Snaps are probably not going anywhere even faster now that the closed-control market has also been compromised by malware. This thread also indicates that the problem we are experiencing is inherent to how snaps organize data and what remains writeable relative to how the actual application does it. If you want customization, a read-only container depending on a closed-source distribution mechanism may not be the best way to go. The same can be accomplished with docker images in a compose file without loss of functionality (but an increase in administrative overhead). Maybe we should just be glad that grandma can run her own with snapd and not expect plugins to work? That makes the other 98% of plugins which do work a pleasant surprise instead of this functionality being a thorn in one's side. :)
On Thu, May 17, 2018 at 6:02 AM, Pawel Herman notifications@github.com wrote:
I'm using NextCloud 13.0.2 on Debian Stretch and neither installing and enabling then disabling Unsplash worked nor removing the data/appdata_(instanceid) directory. Changing the name, slogan, URL, or logo in the Theming app has no effect. php occ config:list shows the changes but the interface itself does not change.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nextcloud/server/issues/6267#issuecomment-389814445, or mute the thread https://github.com/notifications/unsubscribe-auth/ABRPjElxKF_zikue-jDhWFqQNBD94y8Eks5tzUrRgaJpZM4PDadr .
-- Boris Lukashev Systems Architect Semper Victus https://www.sempervictus.com
Just FYI, I'm not using Docker.
Same problem on 13.0.5 Installed via official docker image! And my problem is exactly the same as described by @pherman . Also, app unsplash can change background normally. But nither the slogan nor the logo changed with the setting of the theming app. The only thing happens when enabling the theming app is that the background image (the one with blue dots) disappeared. And I cannot find any related error logs. @jospoortvliet
This is not a caching problem, since running occ maintenance:repair
is made to clear all caches yet does not resolve this issue.
I am experiencing the issue on the latest version, when modifying theme using occ. Doing it in the GUI works.
I still can not change logo nor background on nextcloud 29.0
Steps to reproduce
Expected behaviour
Logo should be changed
Actual behaviour
The info says that the logo was saved and it stays endless at "Loading preview...". The background image below logo also shows a broken image link.
Server configuration
Operating system: Gentoo Linux 64bit
Web server: Nginx-1.13.4
Database: MariaDB 10
PHP version: 7.0.22 with pecl-imagick /jpeg, png and svg support builtin)
Nextcloud version: (see Nextcloud admin page) 12.0.2
Updated from an older Nextcloud/ownCloud or fresh install: 11.0.4 (which had the same problem)
Where did you install Nextcloud from: Official download page
Signing status: No signing issues
List of activated apps:
Nextcloud configuration:
Are you using external storage, if yes which one: local/smb/sftp/... no
Are you using encryption: yes/no no
Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/... LDAP
LDAP configuration (delete this part if not used)
-
Client configuration
Browser: Mac Sierra Safari and latest Google Chrome tested
Operating system: macOS 10.12.6
Logs
Web server error log
2017/08/26 10:18:49 [info] 3421#3421: *3 client canceled stream 483 while sending request to upstream, client: 193.239.106.201, server: roessner-net.de, request: "GET /nextcloud/apps/theming/styles?reload=1503735523907 HTTP/2.0", upstream: "fastcgi://unix:/var/run/php5-fpm-system.sock:", host: "roessner-net.de"
Nextcloud log (data/nextcloud.log)
For reasons I do not understand, there does not exist such log file. I only have php error logs for the user stored in another path /var/log/fpm-php/system/php_errors.log, which only shows errors, if the database server is rebooted. No other messages.
Browser log
See in the screenshot attached
Nginx config
It is mostly identical to the example on the nextcloud webside (I think ;-) )
Browser JavaScript
Steps to reproduce in pictures