When pages_enabled.search is false, instead of blocking search entirely,
the search bar now searches within the user's subscriptions and saved
playlists only. YouTube's search API is never called.
Changes:
- routes/search.cr: detect search_disabled, force subscription+playlist
search for logged-in users, 403 for anonymous users
- search/processors.cr: new subscriptions_and_playlists() method that
queries both the subscription materialized view and playlist_videos
table, merges and deduplicates results
- before_all.cr: let /search through to the route handler (APIs still
blocked), keep /hashtag/* blocked
- search_box.ecr: dynamic placeholder ("Search subscriptions & playlists")
- search_homepage.ecr: hint text when in subscription-only mode
- search.ecr: hide YouTube filters, show lock icon + notice, custom
empty-results message
- template.ecr: always show search bar (subscription search needs it)
- en-US.json: 6 new locale strings for subscription-only search UX
- Fix kemal_static_file_handler directory_listing to use Path types (Crystal API compat)
- Add missing search_page_disabled translation key to en-US.json
- Filter preferences default_home options based on pages_enabled config
- Add admin-only /debug_config route for verifying configuration state
* fix: restore dmca_content functionality
This restores (or adds) the functionality of the `dmca_content` config
option that at this date, has been unused and makes no effect.
* only disable download widget for dmca video ids
textcaptcha.com seems to be down since April and it does not appear that
service will be restored.
Text captchas can be easily automated using free LLMs, so keeping the
text captcha is more like a gate to create accounts in mass on public
Invidious instances.
It also gives headaches like bots automating account creation to modify
the videos that appear popular page of each instance (since the popular
page is based on the subscriptions of the registered users).
This PR adds a configuration option to control the preloading of video data on
page load with the HTML5 'preload'[1] attribute on the `<video>` element.
The option is enabled by default, meaning that the `preload` attribute's value
will be 'auto'. If users want to prevent preloading of video data, they
can disable the option, which will set the attribute value to 'none'.
[1](https://www.w3schools.com/tags/att_video_preload.asp)
Closes issue 4110
Fix#4110 by adding an option to control the preloading of video data on
page load. If disabled ("false"), the browser will not preload any video
data until the user explicitly hits the "Play" button.
If enabled ("true"), the default behavior will be used, which means the
browser decides how much of the video will be preloaded.
