-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Theming kills pretty URL #6271
Comments
As addition: I face exactly the same issue, with same config.php and .htaccess, no actual theme configured BUT with theming app DISABLED.
€:
All caches were reset of course. Disabling the theming app now solves everything again. Switching AND BAM: There it is: Enabling pretty urls now while theming app is enabled, I face the same issue again and need do disable it, as it was for tflidd. So: The error seem to occur on many systems, by switching pretty urls. And it depends if the theming app is enabled meanwhile or not. The solution is in both cases to switch the state of the theming app. |
Can you try setting the server/config/config.sample.php Lines 410 to 419 in 1614b31
|
It's strange, I didn't touch the test setup since the bug report. Now it works without any modification. But now I have a problem if I delete all the entries in the .htaccess for pretty URL. Before I cleared the browser cache and restarted apache. I don't even use caching on the server:
|
You should not edit the .htaccess by hand. Just change the config.php and run the occ command to rebuild the htaccess file. 😉 |
I enabled the theming app now also again and the problem is not there anymore: All icons are shown without error. I removed Instead the top right icons (contact search & settings) and some others (e.g. navigation in files app, but folder icons are shown) do not show up. This time browser console shows a different error then for the missing whole bunch of icons before:
Don't see the connection between this and the missing icons, but who knows 😉 . Now I tried This issue was already faced before (I mean not the one described in OT with the svg patch errors and more icons missing, especially nextcloud icon on top left, but the one with the other icons missing) reported several times on help.nextcloud.com and the solution is also here to disable the theming app, if no theming is actually used. Same worked for me now. All icons show up, no error message at all. Now I try to enable pretty urls again, with
Mouse over the SVGs show again the misleading path with missing To show my final
I will have a look if somehow time solves the issue again 😉 . €: Okay, just opened my nextcloud with MS Edge and there all icons show up. So in the end it indeed seems to be a browser cache problem. I just wonder which browser cache, as I clear it in between 😕 . |
Can you use a boolean value |
Okay, sorry, set it without quotes now. First of all he wants to access pretty urls now again => Access forbidden I am again confused now. Where does it come from, that I get redirected to pretty urls now, where they are clearly unset and .htaccess does not show the lines anymore and I cleaned every cache that I know about. Even for login it tries to open
Removing
I am just wondering why this is necessary in my case: mod_env is enabled. How to check if it is "restricted (e.g. suEXEC)"? €: Okay switched to pretty urls again with all the procedure and |
I guess they are somehow cached in the generated CSS files, so changing a theming value will fix that.
Ok, that is something for https://github.com/nextcloud/documentation
I guess that is the same issue with the cached CSS files. I guess we should also drop the cache when the htaccess changes somehow. |
I tried again by using What works: Go to the admin page and change the background color. @juliushaertl Can't we use the same function in this occ-command to reset the scss cache? server/apps/theming/lib/ThemingDefaults.php Line 290 in 4edb261
|
I think I've found another way. We could just make the SCSS generation also depend on the htaccess.IgnoreFrontController by adding it to the baseurl prefix at server/lib/private/Template/SCSSCacher.php Lines 305 to 307 in 517dfdd
That way we can detect that change automatically and regenerate the CSS stuff then. |
The thing is, for me the |
@tflidd In that case there is a env variable front_controller_active set, so that should also go into the SCSS file prefix: |
I finally get the right scss files, either by waiting until the cache clears itself or by changing the default theme a bit. |
Fix is in #6352 Please help review. 😉 |
Steps to reproduce
Expected behaviour
Correct rewrite of the URL. If I disable the theming app 1.3.0, the rewrites are correct.
Actual behaviour
Some Icons in the web interface are missing, I get several 404 errors:
https://example.org/core/img/actions/more-white.svg?v=1 (not the missing nextcloud subfolder)
it applies for other *.svg?v=1 files and *.woff files
Other URLs are correctly rewritten.
Seems to be an issue on more setups: https://help.nextcloud.com/t/icons-missing-path-not-rewritten/4722/2
Server configuration
Operating system: Debian 8
Web server: Apache 2.4
Database: MySQL
PHP version: 7.0
Nextcloud version: 12.0.2
It's a pretty default straight forward setup, should be easily reproducable. My
.htaccess
after running the occ-command:and of course in the config.php:
The text was updated successfully, but these errors were encountered: