Fixed file quota as well.
There can be more than one file for the same filehash IF the url are different.
Possible states:
- A file with no url and with filename is a local file.
- A file with an url but no filename is a remote file that wasn't fetched,
not even the thumbnail.
- A file with an url and filename is a fetched remote file (maybe just a
thumbnail of it).
- A file with no filename nor url is a redirect.
Routes:
Given these states, updated routes so that an attachment can only be
retrieved by id and a file by filehash.
Major API changes:
File::getByHash now returns a yield of files
Major UI changes:
- Now remote non stored files are presented.
- /view became preferred
- Redirects to remote originals are preferred.
Many other minor bug fixes...
Fix OAuth and Realtime issues introduced in 9a515b9234
[DATABASE] Fix an empty default value mistake introduced in
fde929b151
[DATABASE][PostgreSQL] Avoid use of pg_constraint.consrc, which was removed in
PostgreSQL 12.
[DATABASE][MariaDB] Fix a typo introduced in aed2344bd4
[DAEMON] Wrap an assignment inside "switch":
a follow-up to adc689cb15
Ideally the character set should be set with the connection, and so this is
exactly what's being done now.
And now the character set code is attempted to be generalised.
Changing `character_set_server` requires root permissions and rebooting
the server.
Which is impossible on shared web hosting services.
So use `character_set_database`. This variable can be changed with
user permissions using `ALTER DATABASE`.
"Magic quotes" were removed in PHP 5.4, no need to mitigate it anymore.
Avoid implode() with the join()-like order of arguments which was deprecated
since PHP 7.4 and implicitly since PHP 5.3.
Also avoid implode() with an implicit separator for stylistic reasons.
mktime() with no arguments has been deprecated since PHP 5.1.
The previous approach sent the key values twice, which for large sets is
twice as bad.
As an optional feature of this approach multiGet now allows retrieving tuples
in exact order and amount of the requested key values.
Before now table definitions could define collations only for MariaDB using the
MariaDB's collation names directly.
Now instead definitions get a slightly more abstract collation name syntax, but
only supporting the collations utf8mb4_bin and utf8mb4_unicode_(cs|ci) (wrapped
as utf8_bin, utf8_general_(cs|ci)), because those are the ones that have
practical use for GNU social.
Which also means that on MariaDB the formerly used utf8mb4_general_(cs|ci) have
been superseded by utf8mb4_unicode_(cs|ci), as they are the more modern
replacement.
Introduce collation support on PostgreSQL which results in use of the C (POSIX)
collation as utf8_bin and the und-x-icu collation as utf8_general_cs.
utf8_general_ci is also mapped to und-x-icu, which makes it case-sensitive,
unfortunately.