π A simple, fully translatable admin interface for sabre/dav based on Symfony 5 and Bootstrap 5, initially inspired by BaΓ―kal.
MIT License
Bot releases are visible (Hide)
[!WARNING]
This is a pre-release pending further testing
This is a major update of Symfony to the 7.0 version, but including no new features.
β οΈ This release drops PHP 8.0 and PHP 8.1 support
Full Changelog: https://github.com/tchapi/davis/compare/v4.4.4...v5.0.1-rc
Published by tchapi 3 months ago
[!WARNING]
This is a pre-release pending further testing
This is a major update of Symfony to the 7.0 version, but including no new features.
β οΈ This release drops PHP 8.0 and PHP 8.1 support
Full Changelog: https://github.com/tchapi/davis/compare/v4.4.4...v5.0.0-rc
Published by tchapi 3 months ago
This is a minor fix addressing Docker improvements and other things
This release contains only improvements for Docker image: Switch to PHP 8.3, standalone image package build, as well as fixes in the example compose files.
[!NOTE]
Note that the standalone version of the image is now generally available in the packages section here. Starting from this release, every new version will trigger both standard and standalone builds. For an example on how to use the standalone image, please refer to the related docker compose file
Nothing if you're on v4.4.2+
Full Changelog: https://github.com/tchapi/davis/compare/v4.4.3...v4.4.4
Published by tchapi 5 months ago
This is a minor fix addressing Docker improvements and other things
Nothing if you're on v4.4.2
Full Changelog: https://github.com/tchapi/davis/compare/v4.4.2...v4.4.3
Published by tchapi 7 months ago
Nothing. There is a new WEBDAV_HOMES_DIR
env var (default to an empty string, disabling the home directories), check the README for more information.
Thanks @Ramblurr, @AkselMeola and @de-es for their help
Full Changelog: https://github.com/tchapi/davis/compare/v4.4.1...v4.4.2
Published by tchapi 9 months ago
There's nothing much to do, but you can:
Add the (optional) APP_TIMEZONE
env var if you want to enforce the timezone. By default, timezone is not enforced (which should yield the same behavior as before).
If you use an external auth provider (such as Authelia) in front of Davis, you can now disable the baked-in auth easily with the ADMIN_AUTH_BYPASS
env var (set it to true
). By default, nothing changes from the previous release.
ππΌββοΈ Also, if you're coming from a release before 4.4.0, please do not forget to run the migration process below
Thanks @MuratovAS for the challenge on auth mechanisms
Full Changelog: https://github.com/tchapi/davis/compare/v4.4.0...v4.4.1
Published by tchapi 9 months ago
[!TIP]
The added migration will only make changes if you're on MySQL; it's expected, you can ignore if you're using PostgreSQL or SQLite
This is a safety precaution in case you end up messing with a migration or the database in general. It's highly recommended, even if you know exactly what you're doing.
You can now update the code (either directly or get the up to date container), and then run the remaining migrations with:
bin/console doctrine:migrations:migrate --allow-no-migration
[!NOTE]
Some migrations are for PostgreSQL, some for MySQL, so it's perfectly normal if you always have a "New" migration that is skipped, and if you're not at the latest one.
Full Changelog: https://github.com/tchapi/davis/compare/v4.3.0...v4.4.0
Published by tchapi 11 months ago
ππΌββοΈ If you're coming from a release before 4.2.0, please do not forget to run the migration process below
Warning
While not exactly breaking, you have to update the database schema to have the correct column type. Follow the instructions below.
This is a safety precaution in case you end up messing with a migration or the database in general. It's highly recommended, even if you know exactly what you're doing.
You can now update the code (either directly or get the up to date container), and then run the remaining migrations with:
bin/console doctrine:migrations:migrate
Note
Some migrations are for PostgreSQL, some for MySQL, so it's perfectly normal if you always have a "New" migration that is skipped, and if you're not at the latest one.
Full Changelog: https://github.com/tchapi/davis/compare/v4.2.1...v4.3.0
Published by tchapi 11 months ago
Warning
THIS RELEASE IS YANKED. Please update to 4.3.0 directly, following the migration process of 4.2.0
Full Changelog: https://github.com/tchapi/davis/compare/v4.2.0...v4.2.1
Published by tchapi 11 months ago
Warning
While not exactly breaking, you have to update the database schema to have the correct column type. Follow the instructions below.
This is a safety precaution in case you end up messing with a migration or the database in general. It's highly recommended, even if you know exactly what you're doing.
You can now update the code (either directly or get the up to date container), and then run the remaining migrations with:
bin/console doctrine:migrations:migrate
Note
Some migrations are for PostgreSQL, some for MySQL, so it's perfectly normal if you always have a "New" migration that is skipped, and if you're not at the latest one.
Full Changelog: https://github.com/tchapi/davis/compare/v4.1.0...v4.2.0
Published by tchapi 12 months ago
Full Changelog: https://github.com/tchapi/davis/compare/v4.0.0...v4.1.0
Published by tchapi about 1 year ago
Warning
β οΈ This release drops support for PHP < 8.0 β οΈ
Full Changelog: https://github.com/tchapi/davis/compare/v3.3.0...v4.0.0
Published by tchapi about 1 year ago
Full Changelog: https://github.com/tchapi/davis/compare/v3.3.0...v3.3.1
Published by tchapi over 1 year ago
stream_get_contents()
in https://github.com/tchapi/davis/pull/95
Note
This is 3.X branch's latest feature release. 4.X will drop support for PHP < 8.0.
You can now use SQLite as a datastore. A sample docker-compose for SQLite is available in the repo to get you started. Please note that it is not extensively tested and that MariaDB is still the recommended database to run Davis
Nothing to do, but make sure that you have upgraded to v3.1.0 before.
Full Changelog: https://github.com/tchapi/davis/compare/v3.2.0...v3.3.0
Published by tchapi over 1 year ago
Nothing to do, but make sure that you have upgraded to v3.1.0 before.
Full Changelog: https://github.com/tchapi/davis/compare/v3.1.0...v3.2.0
Published by tchapi almost 2 years ago
Warning
The previous 3.0.0 was yanked β you should switch to 3.1.0 (this release) directly
This change will also allow Davis to be used with a PostgreSQL database.
Specify DATABASE_DRIVER
in your env file like so:
DATABASE_DRIVER=mysql
Warning
If you already use PostgreSQL (not supported), DO NOT FOLLOW THESE STEPS. See the "How to upgrade (PostgreSQL)" paragraph below for more information
This upgrade is a good time to enforce the use of migrations.
To do so, you will need to follow the necessary steps BEFORE UPGRADING:
This is a safety precaution in case you end up messing with a migration or the database in general. It's highly recommended, even if you know exactly what you're doing.
serverVersion
and charset
This is highly recommended as various database engines will yield different migration plans. You only need to change your DATABASE_URL
env var to reflect the actual version of your server, and its charset:
For MariaDB, for instance:
DATABASE_URL=mysql://davis:password@mysql:3306/davis?charset=utf8mb4&serverVersion=mariadb-10.6.10
For MySQL:
DATABASE_URL=mysql://davis:password@mysql:3306/davis?charset=utf8mb4&serverVersion=5.7
Use the correct version of your database of course
bin/console doctrine:migrations:status
It should yield a table, like so (some rows have been cut for readability):
+----------------------+----------------------+------------------------------------------------------------------------+
| Versions | Previous | DoctrineMigrations\Version20210928132307 |
| | Current | DoctrineMigrations\Version20221106220411 |
| | Next | DoctrineMigrations\Version20221106220412 |
| | Latest | DoctrineMigrations\Version20221106220412 |
|----------------------------------------------------------------------------------------------------------------------|
| Migrations | Executed | 7 |
| | Executed Unavailable | 0 |
| | Available | 8 |
| | New | 1 |
+----------------------+----------------------+------------------------------------------------------------------------+
The important bit is if you have ever executed the migration, ie. if Migrations | Executed
is not 0
You don't need to do much more, just skip to 4.
It means that you haven't run any migration before and that the schema was created ad-hoc. To fix this and make sure your db is in sync, we're going to do two steps:
bin/console doctrine:schema:update --force
bin/console doctrine:migrations:sync-metadata-storage
bin/console doctrine:migrations:version 'DoctrineMigrations\Version20191030113307' --add --no-interaction
bin/console doctrine:migrations:version 'DoctrineMigrations\Version20191113170650' --add --no-interaction
bin/console doctrine:migrations:version 'DoctrineMigrations\Version20191125093508' --add --no-interaction
bin/console doctrine:migrations:version 'DoctrineMigrations\Version20191202091507' --add --no-interaction
bin/console doctrine:migrations:version 'DoctrineMigrations\Version20191203111729' --add --no-interaction
bin/console doctrine:migrations:version 'DoctrineMigrations\Version20210928132307' --add --no-interaction
bin/console doctrine:migrations:version 'DoctrineMigrations\Version20221106220411' --add --no-interaction
Note
If you have an error like soThe metadata storage is not initialized, please run the sync-metadata-storage command to fix this issue.
, this means that you have not updated yourDATABASE_URL
env var to use the server version as indicated in point 1.
You can now update the code (either directly or get the up to date container), and then run the remaining migrations with:
bin/console doctrine:migrations:migrate
Note
Some migrations are for PostgreSQL, some for MySQL, so it's perfectly normal if you always have a "New" migration that is skipped, and if you're not at the latest one.
β οΈ if for some reason you are using a modified version of Davis with a PostgreSQL database, the latest migrations will likely not work as the data will not be converted when changing the column type.
In this case, you need to update manually the database structure and cast all necessary values accordingly (from bytea to varchar), and then mark the single PostgreSQL migration as run with:
bin/console doctrine:migrations:version 'DoctrineMigrations\Version20221106220412' --add
You can see all the columns that have been changed in the migrations\Version20221106220411.php
file
Full Changelog: https://github.com/tchapi/davis/compare/v2.1.0...v3.1.0
Published by tchapi almost 2 years ago
Warning
THIS RELEASE IS YANKED
## What's Changed
Published by tchapi almost 2 years ago
If you don't use Docker or have not enabled WebDAV, there's nothing to do β¨
Otherwise, you need to be careful when updating:
On the previous Docker image, the www-data
user had a uid of 33
Switching to Alpine, this same user now has a uid of 82
and the uid of 33
is assigned to the xfs
user.
π¨ If you had a shared WebDAV volume used by the Davis container, make sure that the user set for the root WebDAV folder is correct, ie. you need this folder to be owned by www-data:www-data
and not xfs:xfs
(ie. 82:82
and not 33:33
)
Full Changelog: https://github.com/tchapi/davis/compare/v2.0.2...v2.1.0
Published by tchapi over 2 years ago
This is just a minor release addressing an issue with the Docker container missing the freetype flag
Full Changelog: https://github.com/tchapi/davis/compare/v2.0.1...v2.0.2
Published by tchapi over 2 years ago
This is just a minor release containing a fix regarding the map marker image that was not searched in the right folder
Full Changelog: https://github.com/tchapi/davis/compare/v2.0.0...v2.0.1