Project Settings & Presets
Relevant source files
The following files were used as context for generating this wiki page:
- app/Support/Settings/ProjectSettingsManager.php
- app/Models/ProjectSettings.php
- app/Actions/Settings/ApplyProjectPresetAction.php
- config/project_presets.php
- app/Filament/Pages/ProjectSettingsPage.php
- tests/Feature/Support/Settings/ProjectSettingsManagerTest.php
- tests/Feature/Actions/ApplyProjectPresetActionTest.php
The Project Settings & Presets system provides a centralized mechanism for managing global application configurations, site identity, and feature toggles. It allows administrators to customize the platform's behavior and terminology without modifying code, or to quickly pivot the entire platform focus using predefined domain templates known as "Presets."
This system ensures that the application remains highly configurable for different domains (e.g., Food, Nature, Cats) while maintaining a consistent architectural pattern for settings resolution and caching.
Sources: app/Filament/Pages/ProjectSettingsPage.php:30-40, app/Support/Settings/ProjectSettingsManager.php:7-10
Architecture Overview
The settings architecture is built on three main layers: the database persistence layer, the manager/resolution layer, and the administration UI layer.
Core Components
| Component | Responsibility |
|---|---|
ProjectSettings Model | Database representation of settings, stored as a single record. |
ProjectSettingsManager | Resolves settings by merging database values with code-defined defaults. |
ApplyProjectPresetAction | Business logic for applying a configuration template from project_presets.php. |
ProjectSettingsPage | Filament-based admin interface for manual settings adjustment. |
Sources: app/Models/ProjectSettings.php, app/Support/Settings/ProjectSettingsManager.php, app/Actions/Settings/ApplyProjectPresetAction.php, app/Filament/Pages/ProjectSettingsPage.php
Data Flow Diagram
The following diagram illustrates how settings are resolved from the database and defaults, and how they are updated via the Admin UI.
The diagram shows the interaction between administrative actions (Presets/Manual Edits) and the runtime resolution of settings through the Manager.
Sources: app/Support/Settings/ProjectSettingsManager.php:51-70, app/Actions/Settings/ApplyProjectPresetAction.php:15-30
Project Settings Resolution
The ProjectSettingsManager is the primary service used to access configuration at runtime. It implements a fallback mechanism where missing database values are automatically replaced by hardcoded defaults.
Resolution Logic
- Attempt to find a record in the
project_settingstable with ID 1. - If found, merge the database array with the
DEFAULTSconstant. - Specifically merge the
feature_flagsarray to ensure missing flags still receive their default values. - Cache the result in memory (the
resolvedproperty) for the duration of the request.
Sources: app/Support/Settings/ProjectSettingsManager.php:51-70, tests/Feature/Support/Settings/ProjectSettingsManagerTest.php:15-30
Feature Flags
Feature flags are stored as a JSON/array cast in the database and control specific UI and functional capabilities:
show_comments: Toggles comment sections.allow_user_uploads: Controls if non-admin users can upload content.allow_guest_viewing: Manages public access.post_detail_overlay_mode: Switches between page-based and overlay-based post views.
Sources: app/Support/Settings/ProjectSettingsManager.php:26-36, app/Filament/Pages/ProjectSettingsPage.php:121-131
Project Presets
Presets are predefined configuration templates stored in config/project_presets.php. They allow the platform to change its "domain" (the type of objects being rated) instantly.
Available Presets
The system includes several default presets:
generic: Standard "RateGuru" branding using "posts".food: "FoodGuru" branding focusing on "dishes".nature: "NatureGuru" branding focusing on "photos".cats: "CatGuru" branding focusing on "cats".
Sources: config/project_presets.php, tests/Feature/Support/Settings/ProjectPresetsConfigTest.php:10-15
Apply Preset Sequence
The sequence demonstrates the process of applying a preset, ensuring the database is updated and the runtime cache is invalidated.
Sources: app/Filament/Pages/ProjectSettingsPage.php:181-205, app/Actions/Settings/ApplyProjectPresetAction.php:15-30
Administrative Interface
The settings are managed via a Filament Custom Page located at /admin/project-settings. This page is restricted to users with the admin role.
Configuration Sections
- Site Identity: Site name, tagline, and description.
- Object Labels: Customizing the singular/plural names of rated objects (e.g., "Dish" vs "Photo").
- Defaults: Standard locale, theme, and sort order.
- Feature Flags: Boolean toggles for application features.
- Translations: Tabbed interface for managing localized versions of site identity and labels.
Sources: app/Filament/Pages/ProjectSettingsPage.php:68-155, app/Filament/Pages/ProjectSettingsPage.php:50-55
Localization Support
The settings model includes translation fields (e.g., site_name_translations). The ProjectSettingsPage dynamically generates tabs for every locale defined in config/locales.supported.
Sources: app/Filament/Pages/ProjectSettingsPage.php:133-160
Data Schema
The ProjectSettings model (persisted in the project_settings table) uses the following structure:
| Field | Type | Description |
|---|---|---|
site_name | String | The main title of the website. |
object_singular_name | String | Label for a single item (e.g., "post"). |
active_preset_key | String | Identifies which preset was last applied. |
feature_flags | Array/JSON | Key-value store for boolean toggles. |
site_name_translations | Array/JSON | Localized versions of the site name. |
Sources: app/Models/ProjectSettings.php, app/Support/Settings/ProjectSettingsManager.php:12-40
Summary
The Project Settings & Presets system provides the flexibility required for a multi-domain rating platform. By combining a rigid resolution manager with a dynamic preset configuration, RateGuru can be reconfigured from a food-rating site to a nature-rating site without manual database migrations or code changes. The implementation ensures that feature flags and site identity are always available via safe fallbacks, maintaining application stability even if the settings record is missing.
Sources: app/Support/Settings/ProjectSettingsManager.php:51-75, tests/Feature/Actions/ApplyProjectPresetActionTest.php:38-45