Use firstLogin event to trigger creation of default calendar and default address book
Delay login of admin user after setup so that firstLogin event can properly be processed for the admin
Fixing tests ...
Skeleton files are not copied over -> only 3 cache entries are remaining
Use updateLastLoginTimestamp to properly setup lastLogin value for a test user
The current logic for mod_rewrite relies on the fact that people have properly configured ownCloud, basically it reads from the `overwrite.cli.ur
l` entry and then derives the `RewriteBase` from it.
This usually works. However, since the ownCloud packages seem to install themselves at `/owncloud` (because subfolders are cool or so…) _a lot_ of people have just created a new Virtual Host for it or have simply symlinked the path etc.
This means that `overwrite.cli.url` is wrong, which fails hard if it is used as RewriteBase since Apache does not know where it should serve files from. In the end the ownCloud instance will not be accessible anymore and users will be frustrated. Also some shared hosters like 1&1 (because using shared hosters is so awesome… ;-)) have somewhat dubious Apache configurations or use versions of mod_rewrite from the mediveal age. (because updating is money or so…)
Anyhow. This makes this explicitly an opt-in configuration flag. If `htaccess.RewriteBase` is set then it will configure index.php-less URLs, if
admins set that after installation and don't want to wait until the next ownCloud version they can run `occ maintenance:update:htaccess`.
For ownCloud 9.0 we also have to add a repair step to make sure that instances that already have a RewriteBase configured continue to use it by copying it into the config file. That way all existing URLs stay valid. That one is not in this PR since this is unneccessary in master.
Effectively this reduces another risk of breakage when updating from ownCloud 8 to ownCloud 9.
Fixes https://github.com/owncloud/core/issues/24525, https://github.com/owncloud/core/issues/24426 and probably some more.
The new updater as shipped with ownCloud 9.0.x invokes `occ` via `shell_exec`. This means that the `\OC::$CLI` code is used when updating.
This removes the manual `.htaccess` modifications, effectively leading to the fact that URLs without index.php in it stop working. This also affects share URLs which could be considered a rather serious regression.
- User installs 9.0.0 via web
- User shares /s/1234
- User updates to 9.0.1 via ownCloud updater
- Link to /s/1234 is broken, /index.php/s/1234 works
The ownCloud update routine also runs the "updateHtaccess" code in case only an application gets updated. This leads to having entries multiple time in the .htaccess file leading to unpredictable behaviour.
With 9.0 we added the "#### DO NOT CHANGE ANYTHING ABOVE THIS LINE ####" entry to the .htaccess file, this change uses it to ensure that only to the .htaccess gets written if the file has not been modified already. Since the .htaccess modifications are optional this is not a big deal.
Without this change updates of applications can break the rewrite rules (ending in endless redirects) as well as breaking the code integrity checker.
After the initial installation ownCloud will write some content into the .htaccess file such as the 404 or 403 directives. This adds a magic marker into the .htaccess file and only the content above this marker will be compared in the integrity checker.
When `DirectorySlash off` is set then Apache will not lookup folders anymore. This is required for example when we use the rewrite directives on an existing path such as `/core/search`. By default Apache would load `/core/search/` instead `/core/search` so the redirect would fail here.
This leads however to the problem that URLs such as `localhost/owncloud` would not load anymore while `localhost/owncloud/` would. This has caused problems such as https://github.com/owncloud/core/pull/21015
With this change we add the `DirectorySlash off` directive only when the `.htaccess` is writable to the dynamic part of it. This would also make `localhost/owncloud` work again as it would trigger the 404 directive which triggers the redirect in base.php.
mod_rewrite as used by the front controller may require a `RewriteBase` in case the installation is done using an alias. Since we cannot enforce a writable `.htaccess` file this will move the `front_controller_active` environment variable into the main .htaccess file. If administrators decide to have this one not writable they can still enable this feature by setting the `front_controller_active` environment variable within the Apache config.
This changeset allows ownCloud to run with pretty URLs, they will be used if mod_rewrite and mod_env are available. This means basically that the `index.php` in the URL is not shown to the user anymore.
Also the not deprecated functions to generate URLs have been modified to support this behaviour, old functions such as `filePath` will still behave as before for compatibility reasons.
Examples:
http://localhost/owncloud/index.php/s/AIDyKbxiRZWAAjP => http://localhost/owncloud/s/AIDyKbxiRZWAAjPhttp://localhost/owncloud/index.php/apps/files/ => http://localhost/owncloud/apps/files/
Due to the way our CSS and JS is structured the .htaccess uses some hacks for the final result but could be worse... And I was just annoyed by all that users crying for the removal of `index.php` ;-)
Morris Jobke
Frank Isemann
KB7777
Robert Scheck
Thomas Müller
Joas Schilling
Robin Appelman
Lukas Reschke
Christoph Wurst
Lukas Reschke
Roeland Jago Douma
Joas Schilling
Jenkins for ownCloud
Vincent Petry