Skip to main content
Frontend settings control everything visible on the public-facing side of the application and the overall branding of the platform. These settings are split across several sections in the admin panel.

Theme and branding

Navigate to Admin → Theme (/admin/theme) to manage all visual settings stored in the frontend_settings database table via FrontendSetting::set(). Settings are grouped into sections:
Basic application settings such as site name and global options.
The main banner on the landing page: headline text, subheadline, call-to-action button text and URL.
Highlights displayed in the features block: feature titles, descriptions, and icons.
Company information and description text shown in an about block.
Meta title, meta description, and Open Graph settings for search engine optimisation.

Updating a setting

Each section renders editable fields. Click Save for a section to submit all fields in that section at once. Individual settings can also be saved via the Update setting endpoint (used by toggle controls).

Logo upload

Upload a logo from the Theme page. The file is stored as public/logos/logo.{ext} in Laravel storage and served via the storage symlink. Supported formats: JPEG, PNG, JPG, SVG. Maximum size: 2 MB. For separate light and dark logos and a favicon, use Admin → System Config → Logo settings (which uses base64 upload and stores paths via BrandingService).

Reset to default

Click Reset to default to truncate all frontend_settings records and re-run the FrontendSettingsSeeder. This restores factory default values.

Export and import

  • Export — Downloads all settings as a JSON file named frontend_settings_YYYY-MM-DD_HH-mm-ss.json.
  • Import — Upload a previously exported JSON file to bulk-restore settings.

Landing page

The landing page is enabled or disabled with the FRONTEND_LANDING_ENABLED environment variable in Admin → System Config → Application settings. When disabled, visitors to / are redirected to the login page. Landing page content (hero, features, about sections) is managed through the Theme section described above. Navigate to Admin → Frontend Settings → Footer (/admin/frontend-settings/footer) to edit footer-specific content stored in the footer section of frontend_settings.
Setting keyDescription
company_descriptionShort paragraph about your company shown in the footer (max 500 characters)
social_twitterTwitter/X profile URL
social_facebookFacebook page URL
social_linkedinLinkedIn page URL
social_instagramInstagram profile URL
social_youtubeYouTube channel URL
social_githubGitHub organisation/repository URL
Navigate to Admin → Social Media (/admin/social-media) to manage social media links as separate database records (distinct from the footer settings above). These records support ordering via Admin → Social Media → Update order. Each social media record has:
  • Platform name
  • URL
  • Display order
Navigate to Admin → Footer Links (/admin/footer-links) to manage navigational links in the footer (e.g. “About”, “Careers”, “Contact”). These are separate from social media icons. Each footer link record has a label and a URL. Navigate to Admin → Legal Pages (/admin/legal-pages) to manage privacy policy, terms of service, and any other legal documents. Legal pages use a slug-based routing system. The slug determines the URL at which the page is publicly accessible (e.g. a slug of privacy-policy makes the page available at /legal/privacy-policy).
1

Click Create

Opens the legal page creation form.
2

Fill in the details

  • Title — Page title shown in the browser tab and page header.
  • Slug — URL-safe identifier (e.g. privacy-policy, terms-of-service).
  • Content — Rich text body of the legal page.
  • Published — Whether the page is publicly accessible.
3

Save

The page is created. Toggle Published to make it visible to visitors.

Publishing and unpublishing

Use the Toggle publish action on any legal page row to flip its published status without opening the edit form.

Blog

The blog is managed across three sections:

Posts

Admin → Blogs (/admin/blogs)

Categories

Admin → Blog Categories (/admin/blog-categories)

Tags

Admin → Blog Tags (/admin/blog-tags)
All blog management routes require the manage-blog permission.

Creating a blog post

1

Navigate to Admin → Blogs → Create

Opens the post editor.
2

Fill in post details

Title, content (rich text editor with image upload via /admin/blogs/upload-image), category, tags, and publication status.
3

Publish

Save and set status to published to make the post live.

Categories and tags

Create categories and tags before or during post creation. Both support full CRUD (create, edit, delete, view). Tags and categories are shown/filterable on the public blog index.

Embed codes

Navigate to Admin → Embed Codes (/admin/embed-codes) to manage JavaScript snippet codes that customers can use to embed Sniko AI agents on external websites. Each embed code record has:
  • A code snippet
  • An active/inactive toggle
Use Toggle active to enable or disable individual embed codes without deleting them.

Translations and i18n

Languages

Navigate to Admin → Languages (/admin/languages) to manage the languages available in the application.
ActionDescription
Add languageCreate a new language with a locale code (e.g. fr, de) and display name.
Toggle activeEnable or disable a language without deleting its translations.
DeleteRemove a language and all associated translations.
Generate with AIUse the OpenRouter AI integration to auto-generate translations for a new language based on the English source strings.

Translations

Navigate to Admin → Translations (/admin/translations) to edit translation strings for any active language.
ActionEndpointDescription
View allGET /admin/translationsSee all translation keys across all languages.
Update singlePUT /admin/translationsUpdate one translation key-value pair.
Bulk updatePOST /admin/translations/bulkUpdate multiple translations in one request.
ExportGET /admin/translations/exportDownload all translations as a JSON file.
ImportPOST /admin/translations/importUpload a JSON file to bulk-update translations.
FrontendSetting values and PricingPlan names/descriptions support multi-locale JSON storage. When a user’s locale is set, the application returns the matching locale key from the stored JSON, falling back to en.

Build docs developers (and LLMs) love