recommendedProxySettings only adds proxy_* directives (proxy_redirect,
proxy_connect_timeout, proxy_set_header Connection, etc.), which only
take effect on locations using proxy_pass. This vhost only ever uses
fastcgi_pass for PHP, so the setting was inert here.
recommendedOptimisation (sendfile/tcp_nopush/tcp_nodelay/keepalive)
does apply regardless of proxy_pass vs fastcgi_pass, so it's kept.
Verified via the full automated test suite (both proxy backends).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Migration 2025_08_31_224356_additional_languages_af_ca_id.php runs
during `migrate`, before db:seed's LanguageSeeder has populated the
other 42 rows of the languages table, and does
Cache::forever('languages', Language::all()) - permanently caching
just the 3 languages (Afrikaans, Catalan, Indonesian) it sees at that
moment. StaticServiceProvider checks this cache key before ever
querying the DB again, so every fresh install's language dropdown
(e.g. the "Welcome to Invoice Ninja" company setup wizard) was stuck
showing only those 3 entries, in their own native-language spelling
(ctrans() translates each name using the active locale).
Adds an unconditional `invoiceninja-manage cache:forget languages` to
invoiceninja-data-setup.service, and a regression test asserting
/api/v1/statics returns more than 40 languages. Verified directly:
before the fix, a fresh account's statics call returned exactly 3
languages; after, it returns all 45.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Caddy strictly matches vhosts on the exact Host header, unlike nginx
where a single vhost acts as the default regardless of Host. With
hostname = "localhost" (the local-dev default), visiting the VM via
http://127.0.0.1:PORT instead of http://localhost:PORT sent a Host
header matching no vhost, and Caddy silently returned an empty 200 OK
- a genuine white screen with no error anywhere (not in the console,
not in the network tab).
Adds serverAliases for 127.0.0.1:80 and [::1]:80 to the caddy vhost
when hostname is "localhost", so all three ways of reaching the local
VM resolve to the same site block. Verified directly: before this
fix, curl with `Host: 127.0.0.1` got an empty response while `Host:
localhost` got the full app shell; after, all three (localhost,
127.0.0.1, [::1]) return the same 200 response.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Laravel's own CORS middleware already sends a complete, correct set of
Access-Control-* headers on every response. The nginx and caddy vhost
configs were additionally setting a second, static set of the same
headers, producing duplicates with conflicting values (e.g. two
Access-Control-Allow-Methods headers, one "*" and one the app's real
list). Browsers reject responses with duplicate/conflicting CORS
headers - curl-based checks never noticed since only browsers enforce
CORS header validation, but it broke real browser usage (login/API
calls failing silently).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Invoice Ninja relies on Laravel's scheduler for recurring invoices,
scheduled reports, and other internal cron-driven jobs. Without a
systemd unit invoking `artisan schedule:run` periodically, the app's
dashboard reports "cron jobs are not enabled" after login.
Adds invoiceninja-scheduler.timer (every minute, matching upstream's
documented cron cadence) and its oneshot service, and extends the
automated test to assert the timer is active and schedule:run succeeds.
Note: the app's own is_scheduler_running flag only flips on a 5-minute
wall-clock boundary (app/Console/Kernel.php's everyFiveMinutes() job),
so the dashboard warning can take a few minutes to clear after boot -
confirmed working via the "Refresh Data" button in that same modal.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
awkawbandClaude Sonnet 5