Web Platform Update: Block-Based Page Builder, Widgets, and Theme Settings

We view our own web platform as a showcase of the management panels we build for our clients. In this update, we re-engineered the page content structure: every page now consists of blocks that can be reordered, hidden, and have their variants changed directly from the administration panel. This article covers the scope of the update and the technical decisions behind it.

What has changed?

• Block-based pages: Hero, rich text, feature grid, stats, FAQ, timeline, two-column, gallery, testimonial logos, contact form, and embedded content blocks.
• Block settings: Variant, background (glass, grid, aurora, gradient), alignment, spacing, and animation preferences are managed individually for each block.
• Widgets: Recurring blocks such as the "Tell us about your project" call-to-action or technology banner are defined once and referenced across any desired page.
• Page templates: Landing, service, campaign, and about templates allow new pages to start with a ready-made block layout.
• Theme settings: Theme variant, accent color, and animation intensity can be changed from the panel; visitors with reduced motion preferences are fully respected.

Data model: preserving legacy fields

To transition smoothly without breaking existing page sections, I preserved the legacy title and body fields; when the new content area is empty, the interface falls back to these fields. The block type is defined as a restricted list in the database, preventing undefined block types from being saved via the panel.

alter table public.page_sections
  add column block_type text not null default 'rich_text',
  add column settings   jsonb not null default '{}'::jsonb,
  add column is_visible boolean not null default true;

alter table public.page_sections
  add constraint page_sections_block_type_check check (block_type in (
    'hero', 'rich_text', 'feature_grid', 'stats', 'cta', 'gallery', 'faq', 'logo_wall',
    'testimonial', 'contact_form', 'embed_html', 'spacer', 'two_column', 'timeline', 'widget_ref'));

Visibility and publishing rules in the database

An anonymous visitor can only read published and visible blocks of published pages. This rule is defined not in the UI, but within PostgreSQL Row Level Security policies; hence, anyone making direct requests to the API cannot view draft or hidden blocks either. We apply this same approach across all content tables.

If a "hide" button only works in the user interface, it is not actually hidden. The privacy rule must be defined where the data lives.

Demo mode: a site that runs without a database connection

Another feature of the platform is its ability to run without a database connection. All initial content is generated from a single source file; the same build step creates both the database seed file and the static demo data. This ensures development, testing, and demo environments all share the exact same content, eliminating the need to manually update changes in two places.

Accessibility and performance

Blocks are fully navigable via keyboard, FAQ accordions include proper ARIA attributes, and animations respect operating system-level reduced motion preferences. Heavy visual effects (such as 3D hero scenes) are loaded only when supported by the device and browser.

What's new in Insights?

With this update, categories, tags, and related content links went live in the Insights section. News from external sources cannot be published without passing through an editorial approval queue, and AI-assisted drafts cannot go live without verification by an editor. These rules are also enforced at the database level.

What's next?

In the upcoming period, block-level A/B variants, translation workflows for multilingual content, and media library improvements are planned. We will announce dates in this roadmap as they are finalized; our principle is never to describe an unfinished feature as if it were complete.

How do block settings work?

Each block has two data fields: content and settings. Content holds language-based texts and item lists (such as FAQ questions), while settings determine appearance. The settings schema was intentionally kept narrow: variant, background, alignment, spacing, and animation. Free-form CSS or arbitrary fields are not accepted, ensuring every change made from the panel stays within the boundaries of the design system and preserves site integrity.

{
  "variant": "accordion",
  "background": "glass",
  "align": "left",
  "padding": "md",
  "animation": "fade"
}

Content alternatives: experimenting without deleting

When modifying a block's content, you naturally want to avoid losing the previous version. In this release, blocks can carry named content alternatives: two versions of a title or description for the same block are stored, and the panel allows choosing which one is live. This also serves as the infrastructure for planned future A/B testing.

In-place editing within the administration panel

Editors modify blocks directly on the page itself rather than via a separate form screen: clicking text to type, adding items, and dragging to reorder. This editing layer is never loaded in the public view, meaning no editor code is sent to the visitor's browser. This separation is vital for both performance and security.

Audit and version history

Every block modification is written to the audit log along with who changed what and when; content revisions are stored, allowing a rollback to previous versions when needed. Publishing permissions are separated from editing permissions: an editor can prepare a draft without necessarily having the right to push it live. This role segregation is standard in our enterprise client panels.

Tech stack

• Interface: React, TypeScript, Vite, Tailwind CSS; Motion and GSAP for animations.
• Data: Supabase on PostgreSQL; permissions managed via Row Level Security policies.
• Validation: Zod schemas validate both form inputs and content structure.
• Deployment: Docker and Nginx; public pages are pre-rendered at build time.

Testing approach

Block schema, normalization functions, and the public renderer are validated with unit tests, while database policies are verified using SQL tests running on a real PostgreSQL instance. Rules like "hidden blocks are not visible to anonymous users" are checked not just in the UI, but in policy tests as well. Testing a rule in two places is not redundancy, but a conscious choice for security.

If you would like a similar management panel and content infrastructure for your own organization, you can reach out to us via our web and mobile applications service.