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.
* allow configuration of memcache options
Use production values for memcached as explained in http://apprize.info/php/scaling/15.html
The current implementiation uses ascii based serialization. This PR should reduce traffic to the memcached server.
cc @MorrisJobke @FelixBoehm
* add config sample
* merge config options, throw hint on config error
* fix typo
* fix config sample
Currently testing the updates is a big problem and not really super easy possible. Since we now have a new updater server we should also make this configurable so that people can properly test updates.
* if you install owncloud via package it is not
possible to skip migration tests
* this also allows to disable migration tests for
an instance by default
Added config.php option to replace the default implementation of system
tag manager and system tag object mapper.
Also adjusted the comments manager factory to inject the server container
register CommentsManager service, allow override, document in config.sample.php
don't insert autoincrement ids in tests, because of dislikes from oracle and pgsql
specify timezone in null date
only accepts strings for ID parameter that can be converted to int
replace forgotten hardcoded IDs in tests
react on deleted users
react on file deletion
Postgresql compatibility
lastInsertId needs *PREFIX* with the table name
do not listen for file deletion, because it is not reliable (trashbin, external storages)
add runtime cache for comments
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` ;-)
* if you install owncloud via package it is not
possible to skip migration tests
* this also allows to disable migration tests for
an instance by default
This will prevent detecting remote changes done in the data folder /
root storage by default. In the rare cases where the data folder is
shared with other apps/users outside ownCloud and change detection is
needed, the admin will have to set the option explicitly from now on.
Note that this doesn't affect external storages which have their own
setting in the mount options.
* Log condition for log level increase based on conditions. Once one of these
conditions is met, the required log level is set to debug. This allows to
debug specific requests, users or apps
* Supported conditions (setting `log_condition` in `config.php`):
- `shared_secret`: if a request parameter with the name `log_secret` is set to
this value the condition is met
- `users`: if the current request is done by one of the specified users,
this condition is met
- `apps`: if the log message is invoked by one of the specified apps,
this condition is met
* fix unit test and add app log condition test
This Pull Request introduces a SabreDAV plugin that will block all older clients than 1.6.1 to connect and sync with the ownCloud instance.
This has multiple reasons:
1. Old ownCloud client versions before 1.6.0 are not properly working with sticky cookies for load balancers and thus generating sessions en masse
2. Old ownCloud client versions tend to be horrible buggy
In some cases we had in 80minutes about 10'000 sessions created by a single user. While this change set does not really "fix" the problem as 3rdparty legacy clients are affected as well, it is a good work-around and hopefully should force users to update their client
The first time we're asked to generate a preview we'll generate one of the maximum dimension indicated in the configuration and all future resizing requests will be done on that preview in order to not waste time converting the same file over and over.
One of the fixes required for #12465
Caches divided up into two groups: distributed and local. 'Low latency' is an
alias for local caches, while the standard `create()` call tries to get
distributed caches first, then local caches.
Memcache backend is set in `config.php`, with the keys `memcache.local` and
`memcache.distributed`. If not set, `memcache.distributed` defaults to the value
of `memcache.local`.
