Signed-off-by: Julius Härtl <jus@bitgrid.net>

Signed-off-by: Julius Härtl <jus@bitgrid.net>

Signed-off-by: Joas Schilling <coding@schilljs.com>

Signed-off-by: Joas Schilling <coding@schilljs.com>

Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>

* Nextcloud is not properly loaded in the standalone version (especially the theming)
* it is already not listed anymore in the Nginx config (see nextcloud/documentation#392)
* the index.php-free version doesn't support this

Signed-off-by: Morris Jobke <hey@morrisjobke.de>

Signed-off-by: Joas Schilling <coding@schilljs.com>

Fixme:
- Install and update of apps
- No revert on live systems (debug only)
- Service adjustment to our interface
- Loading via autoloader

Signed-off-by: Joas Schilling <coding@schilljs.com>

Signed-off-by: Lukas Reschke <lukas@statuscode.ch>

Signed-off-by: Lukas Reschke <lukas@statuscode.ch>

* currently there are two ways to access default values:
  OCP\Defaults or OC_Defaults (which is extended by
  OCA\Theming\ThemingDefaults)
* our code used a mixture of both of them, which made
  it hard to work on theme values
* this extended the public interface with the missing
  methods and uses them everywhere to only rely on the
  public interface

Signed-off-by: Morris Jobke <hey@morrisjobke.de>

* preparation for followup PRs to clean up the DB bootstrapping

Signed-off-by: Morris Jobke <hey@morrisjobke.de>

* minor fixes in preparation of a bigger DB and config PR

Signed-off-by: Morris Jobke <hey@morrisjobke.de>

Signed-off-by: Robert Scheck <robert@fedoraproject.org>

Signed-off-by: Robert Scheck <robert@fedoraproject.org>

Signed-off-by: Morris Jobke <hey@morrisjobke.de>

* we only require the PDO driver
* fixes #481

Signed-off-by: Morris Jobke <hey@morrisjobke.de>

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 setup check is still there

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.

add 'last_activity' column to session tokens and delete old ones via a background job

* \OC\OCSClient
* \OC\Preview
* \OC\PreviewManager
* \OC\Repair
* \OC\RepairException
* \OC\Search
* \OC\ServerContainer
* \OC\ServerNotAvailableException
* \OC\ServiceUnavailableException
* \OC\Setup
* \OC\Streamer
* \OC\SubAdmin
* \OC\SystemConfig
* \OC\TagManager
* \OC\Tags
* \OC\TempManager
* \OC\TemplateLayout
* \OC\URLGenerator
* \OC\Updater

ownCloud may be configured to live at the root folder without a
trailing slash being specified. In this case manually set the
rewrite base to `/`

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.

As per https://github.com/owncloud/core/issues/23098 and https://github.com/owncloud/core/issues/23117

In case Apache is configured with an `Alias` such as with the ownCloud packages the rewrite rules will fail when no valid RewriteBase is configured.