* introduce SystemConfig to avoid DI circle (used by database connection which is itself needed by AllConfig that itself contains the methods to access the config.php which then would need the database connection - did you get it? ;))
* use DI container and use that method in legacy code paths (for easier refactoring later)
* create and use getSystemConfig instead of query() in DI container
First step of a somewhat testable user management. - I know, the JSON returns are in an ugly format but the JS expects it that way. So let's keep it that way until we have time to fix the JS in the future.
The codepath that is executed when executing ownCloud via CLI is different than via browser. Specifically, the config is created by the user session already in `OC_Util::getInstanceId()` by a call to `setValue`. That said, this seems to be quite a bad side-effect, but for the sake of "not breaking whatever might break if we touch this" let's keep it that way for now.
When executing the autoconfig via `php -f index.php` the said session was not setup and thus no `config/config.php` file was created resulting in an installation error.
To reproduce this try to setup ownCloud via `php -f index.php` with and without that patch. (ensure to delete all existing configs before and don't access ownCloud with a browser in the meantime)
Fixes itself.
Otherwise the headers from `JSONResponse` are gone and the Content-Type of the response would be `text/html` instead of `application/json; charset=utf-8`. This leads to broken scripts since we set the `nosniff` tag, furthermore this is very bad from a security PoV.
Depending on the used environment the port might be appended to the host header resulting in an inaccessible instance when initially setting up on a system with a different HTTP or HTTPS port. (for example test:500)
To test this setup ownCloud under a different port with and without this patch. (heads-up: localhost is always white-listed, so use a different domain)
* Vector files such as Illustrator files currently show the "image"
icon. I propose to add a new type to mimetypeIcon() called
"image/vector" and which would be used by SVG as well
* We can use the current image-svg+xml icon, but would simply rename it
to image-vector
* The black and white "image" icon looks too much like a settings icon.
A simple picture representation pasted over the file icon should work
This checks that imagecreatetruecolor actually creates an image, rather than returning FALSE.
Without this check, subsequent loop might create billions of ERROR-level log messages.
Signed-off-by: Byron Marohn <combustible@live.com>