signed-off-by Bernhard Ostertag <bernio.github@gmx.de>
After upgrading to 15.0.5 this is shown in the Admin-panel:
```
Your web server is not properly set up to resolve “/ocm-provider/”. This is most likely related to a web server configuration that was not updated to deliver this folder directly. Please compare your configuration against the shipped rewrite rules in “.htaccess” for Apache or the provided one in the documentation for Nginx at it’s documentation page 1. On Nginx those are typically the lines starting with “location ~” that need an update.
Your web server is not properly set up to resolve “/ocs-provider/”. This is most likely related to a web server configuration that was not updated to deliver this folder directly. Please compare your configuration against the shipped rewrite rules in “.htaccess” for Apache or the provided one in the documentation for Nginx at it’s documentation page 1. On Nginx those are typically the lines starting with “location ~” that need an update.
```
I think for runnning nextcloud in a subdirectory of webroot, this rewrite has to be added to the nignx configuration when running nextcloud in a subdirectory of webroot
signed-off-by Bernhard Ostertag <bernieo.github@gmx.de>
After upgrading to 15.0.5 this is shown in the Admin-panel:
```
Your web server is not properly set up to resolve “/ocm-provider/”. This is most likely related to a web server configuration that was not updated to deliver this folder directly. Please compare your configuration against the shipped rewrite rules in “.htaccess” for Apache or the provided one in the documentation for Nginx at it’s documentation page 1. On Nginx those are typically the lines starting with “location ~” that need an update.
Your web server is not properly set up to resolve “/ocs-provider/”. This is most likely related to a web server configuration that was not updated to deliver this folder directly. Please compare your configuration against the shipped rewrite rules in “.htaccess” for Apache or the provided one in the documentation for Nginx at it’s documentation page 1. On Nginx those are typically the lines starting with “location ~” that need an update.
```
I think for runnning nextcloud in a subdirectory of webroot, this rewrite has to be added to the nignx configuration when running nextcloud in a subdirectory of webroot
After upgrading to 15.0.5 this is shown in the Admin-panel:
```
Your web server is not properly set up to resolve “/ocm-provider/”. This is most likely related to a web server configuration that was not updated to deliver this folder directly. Please compare your configuration against the shipped rewrite rules in “.htaccess” for Apache or the provided one in the documentation for Nginx at it’s documentation page 1. On Nginx those are typically the lines starting with “location ~” that need an update.
```
I think for runnning nextcloud in a subdirectory of webroot, this redirect has to be added to the configuration
signed-off by bernieo.github@gmx.de
Fixed the repo issue as previously discussed. Please note I added `imagick` package now as default. IMHO it is of no use to warn a user about it on the admin page if it is not to be used. This how-to should act as a one-stop page for them to get a basic Nextcloud up and running, without issues. (Excluding SSL etc which is more advanced).
Leading slashes were missing from 'class' in the object storage configuration examples (i.e. \\OC\\...) though they were called out correctly above the examples.
After upgrading from 14.04 to 15.02 I got a warning about `imagick` on my server, so it seems that although it is not compulsory, it might be a good idea to add it to minimize the number of warnings a user might experience after initial install.
This patch removes the incorrect line-breaks in the Strict-Transport-Security Headers.
Just removing the comment at the beginning of the line (and therefore having a line-break in the header field) leads to various kinds of failures across different clients and browsers.
updating to php72
adding rh-php72-php-intl
adding uninstallation commands for old php54 (sometimes updating breaks the apache config, because php54 config is recreated)
symlink command for binary for short paths for usage in cron
Shared hostings without shell access make the confirmation step impossible. Therefore you can add named argument and suppress the confirmation message. Then the conversion works even from one time cronjobs.
A number of fixes to regular expressions in the nginx config example:
* escaping forward slash by prefixing a backslash (not essential, but seems good practise anyway)
* fix the second expression in fastcgi_split_path_info to allow for uris ending in .php (which do satisfy the location definition but would result in a 404 with the current specification of fastcgi_split_path_info
* adding /nextcloud to all regex location definitions in the subdirectory example
