I recently upgraded from 5.1.x to 6.0.6 (raspberry pi version).
In my regular user account in the web UI I have a a “Clients” link at the bottom left of the screen (right next to Help and About). This link points to http://myowndomain.com/download_client_program/ which is simply an empty page with the default header that is common to all of seahub’s web pages.
Is this normal? Is it the intended behaviour?
Anyway, I would have expected that this link points to the official download page on seafile.com. (Of course the server admin should have the possibility to override this link, but the default should not be an essentially broken link.)
I also noticed that the “box” containing the text inputs on the login page is positioned slightly wrong (it seems off somehow). So I had a closer look at the download_client_program page (“view source”) and sure enough: the page contents with a reference to seafile.com are in the source code, but they are not shown on screen!
That’s when I tried refreshing the css cache in /tmp/seahub_cache as documented in the manual.
But this didn’t change anything. Here’s my procedure: service seafile-server stop service nginx stop rm /tmp/seahub_cache/* service nginx start service seafile-server start
The css files in the cache directory are recreated but the Web UI still has the same issues: weird positioning on the login page and empty download client page.
There’s also a mention in the manual to “If the problem is not fixed, check whether seafile-server-latest point to the correct folder. Then check whether seafile-server-latest/seahub/media/CACHE is correctly being generated (it should contain the auto-generated CSS file(s)).”
But what does “correctly generated” mean? Here are the current contents of the CACHE folder:
root@myserver:CACHE# find .
Both files have timestamps some minutes after my upgrade from 5.1.x to 6.0.6. That seems correct to me?
What is the exact procedure of completely resetting all relevant caches?
Ok, I’m feeling stupid now. I had to manually clear the cache … of my web browser!
But still, I’m wondering if this is the correct behaviour. Shouldn’t a cache refresh be triggered automatically if the contents of the files change? (I don’t know the specifics about correct cache handling in web applications, so I can’t really tell. But it’s quite some time ago that I had to resort to this kind of manipulation for the last time.)
I think that the Seafile team seriously needs to update the manual and write a new overview of all subfolder, links and items that are important as well as a step by step guide to setup Seafile server.
Right now the manual is more or less a mess and only people who know their way arround can work their way through.
I started a best practise manual but it was not approved by the Seafile team. Maybe the community needs to get loud about the need for this.
I think it’s fixed. I found a download.html file in /custom apparently leftover from an earlier foray into custom CSS that seemed to be the cause. I mistakenly thought that the server would disregard it if custom CSS (BRANDING_CSS) was disabled but it apparently still goes into that folder and reads the file anyway. Maybe it’s because I do have a custom logo. Anyway, once I deleted the file and restarted a normal-looking Seafile download page appeared.
Thanks for the feedback and comments. I have to concur that at this point in the process the docs need to be brought up-to-date and cleaned up a bit. I hope someone takes it to heart and makes some improvements there.
As for your best practices guide, it’s a great idea. There are so many dark corners now it’s a real risk to wade into Seafile without one.
-Thanks again![details=Summary]This text will be hidden[/details]