v2.15.4

Fixed

• Reading settings no longer queries the database on every call (#413). SettingsManager::getSetting() (and apGetSetting()) ran Schema::hasTable('settings') and a SELECT on every call, so a page that reads settings in loops issued hundreds of queries. All stored settings are now loaded at most once per request, by one query, and kept in the cms.settings.all cache entry for up to an hour, so a warm request runs no settings queries. A positive table check is remembered for the process. Any Eloquent save or delete on a Setting clears the cache, both immediately and after the surrounding transaction commits, and reads inside a transaction go straight to the database, so an uncommitted value is never cached or kept after a rollback. Queue jobs and Octane requests reset the in-memory copy, so they see writes made by other processes. Writes that skip Eloquent events (raw DB::table('settings') updates) must call the new SettingsManager::flushCache().
• Visual-editor permissions are no longer re-registered on every request (#414). When visual-editor is installed, the service provider ran Schema::hasTable('permissions') and eight Permission::firstOrCreate calls for the visual_editor.* slugs on every request, including anonymous ones. The slugs are now seeded once and remembered with a cache flag, so a warm request runs no permission queries. The flag is keyed to the permission list and the default database, so a new slug in a later release is seeded automatically and sites sharing a cache store don't skip each other's seed. It is cleared and the slugs re-seeded after every migration run, so migrate:fresh can't leave it stale, and it is only written once the rows exist. If the cache store is unavailable (a database cache store before its table exists), the seed runs uncached as before. Rows deleted by hand outside a migration come back after a cache clear or the next migrate.
• The DynamicContent capability is no longer re-registered on every request (#417). DynamicContentServiceProvider ran Schema::hasTable('permissions') and a Permission::firstOrCreate for manage_dynamic_content on every request, including anonymous ones; deferring it to booted() only helped long-lived workers, since php-fpm boots the app on every request. It now uses the same seed-once cache flag as the visual-editor permissions, and is also re-seeded after every migration run, so the capability exists as soon as migrate finishes. The flag logic is shared through a new SeedsPermissionsOnce trait used by both providers.