Background & Rationale

Oxwall natively includes a modular widget system for profiles, groups, and dashboards. Users and admins can freely add, remove, and reorder widgets (such as SAFE html boxes, SAFE css codes, rss feeds, photogalleries, calendar, weather widgets etc ) , creating personalized pages that go beyond a fixed feed layout.

Sngine is a modern platform but currently lacks user-level page customization beyond its feed-driven structure. Adding an Oxwall-style widget layer would give creators, communities, and groups more control, increasing engagement and platform differentiation.

This concept is developed by ChatGPT and builds on Oxwall’s strengths while addressing Sngine-specific constraints and modern security, scalability, and UX requirements.

Concept Overview

• Data-driven widget system layered on top of Sngine core
• Profiles and groups can dynamically add, configure, and arrange widgets
• Update-safe: no core modifications, uses template hooks and includes
• Mobile-ready design and fallback logic for empty zones
• Scalable caching for high-volume deployments

Architecture & Technical Design

1. Widget Data Model

widgets – widget definitions

id
key_name
title
description
render_handler    -- PHP class or function
settings_schema   -- JSON
css (optional)
js (optional)
dependencies      -- array of required plugins/data
active

widget_instances – placements

id
widget_id
entity_type (user | group | page)
entity_id
zone
position
settings (JSON)
enabled
last_updated

2. Zones & Template Hooks

• Zones are placeholders in templates (e.g., profile_sidebar, group_main_top)
• Smarty includes are used but abstracted via a WidgetRenderer layer for future-proofing

Example Smarty include:

{include file='widgets/zone.tpl'
 zone='profile_sidebar'
 entity_type='user'
 entity_id=$user.user_id}

3. Rendering Flow

1. Zone is requested
2. Widget instances fetched for entity and zone
3. Dependencies are checked; missing dependencies skip the widget with admin notice
4. Instances sorted by position
5. Each widget rendered via its PHP handler
6. CSS and JS injected conditionally

WidgetManager::renderZone('profile_sidebar', 'user', $user_id);

4. Render Handlers

class HtmlBlockWidget {
    public function render($settings, $context) {
        return $settings['html'];
    }
}

5. Widget Settings & Security

• Settings defined in JSON schema
• User-configurable but safe: no raw code execution
• Phase 3 “creator-built widgets” use a restricted DSL or pre-approved templates

{
  "html": {
    "type": "textarea",
    "label": "Custom HTML",
    "required": true
  }
}

6. Mobile UX & Drag-and-Drop

• Desktop: drag-and-drop supported
• Mobile: use “Add widget → Select zone → Choose position” flow
• Touch-friendly interface ensures 60%+ mobile user base is supported

7. Fallbacks for Empty Zones

• If no widgets exist, default Sngine content renders
• Admin can override default content per zone

8. Caching & Performance

• Widget queries cached per entity and zone
• Use Redis or Memcached for high-volume platforms
• Cache invalidated on widget update, reorder, or enable/disable

9. Rollout Strategy

Phase 1 (MVP)

• Groups only
• Single widget type: HTML Block
• No schema UI, no marketplace
• Focus: validate concept and core rendering flow

Phase 2

• Profile widgets
• Drag & drop support
• Schema-driven settings for multiple widget types

Phase 3

• Advanced creator-built widgets using restricted DSL/templates
• Optional widget marketplace

10. TL;DR for Developers

Build a modular widget engine on top of Sngine rather than inside it.
Ensure update-safety, caching, mobile UX, dependency checks, and secure widget configuration.
Rollout gradually: MVP in groups, then profiles, then advanced creators.
This concept draws inspiration from Oxwall but modernizes it for Sngine.