[stable30] fix(a11y): Add OTF font loading check

[backportbot]

Backport of PR #48063

[joho1968]

For 29.0.8, this persistently generates the following error messge:

Could not check for otf loading support. Please check manually if your webserver serves .otf files. To allow this check to run you have to make sure that your webserver can connect to itself. Therefor it must be able to resolve and connect to at least one its trusted_domains or the overwrite.cli.url.

The link to the documentation in question points to https://docs.nextcloud.com/server/29/admin_manual/installation/nginx.html

Searching for .otf or otf gives no matches.

This error was not present in 29.0.7.

[nickvergessen]

This error was not present in 29.0.7.

Yeah it's newly added there. Seems like no one updated the nginx documentation yet.

[nickvergessen]

change is in nextcloud/documentation#12273

[joho1968]

This error was not present in 29.0.7.

Yeah it's newly added there. Seems like no one updated the nginx documentation yet.

Thanks.

I'm not complaining here, but it feels "somewhat" odd that a configuration change would be required for a "minor" upgrade from 29.0.7 to 29.0.8. I would expect that minor bump to mean fixes only.

Just my two cents.

[nickvergessen]

I would expect that minor bump to mean fixes only.

Yeah we ship otf fonts since quite some time, but only now it was noticed that some servers don't serve it correctly. It went unnoticed a long time as other fonts whip woff+otf and then the fall back to otf never happened.

[z3ntu]

Worth noting that on my Apache-based setup I needed to run occ maintenance:update:htaccess to "regenerate" the .htaccess file to make otf loading work. This is probably related to me using 'htaccess.RewriteBase' => '/', but the htaccess never got updated to include otf by any regular maintenance step.

[nickvergessen]

Hmm that's kind of surprising. I would have thought the updater does it automatically.