Everything you need to run SMSocial.

From a clean WordPress site to a working community.

Use this order for a new deployment. It keeps registration, branding and content testing predictable before real members are invited.

Hosting and platform requirements.

SMSocial deactivation is non-destructive. Do not treat plugin deactivation as a data-removal procedure.

Install or update SMSocial safely.

Fresh installation

1. Back up the WordPress database and files.
2. Open Plugins → Add New → Upload Plugin.
3. Select the official SMSocial ZIP and install it.
4. Activate SMSocial.
5. Open the SMSocial admin area and review Setup/System Health before creating real accounts.

Updating an existing installation

Install the newer official ZIP using WordPress replacement/update flow. Do not delete SMSocial data tables manually between versions. Database changes are migration-led and designed to preserve existing social records.

Registration, verification, login and password recovery.

WordPress users remain the account source of truth. SMSocial owns the public email-first Access experience and only creates a new WordPress user after verification is complete.

New-user registration flow

1. The visitor enters an email address.
2. For a new email, SMSocial creates a short-lived encrypted pending registration instead of creating a real user immediately.
3. A one-time verification link is sent to the same email and is valid for approximately 15 minutes.
4. After the link is consumed, SMSocial sends a separate six-digit verification code.
5. After successful code verification, password creation is unlocked.
6. The WordPress account is created, mapped into SMSocial Identity and signed in.

Existing-user login

When an existing email is identified, SMSocial reveals the password step and authenticates against the canonical WordPress user account.

Password recovery

The public SMSocial Access experience includes native password recovery. Reset is performed inside SMSocial rather than sending members into the default WordPress login screen. Reset links are one-time and time-limited.

Email delivery readiness

New-user registration is deliberately fail-closed. Configure a production transport, send a real test email to a mailbox you control, verify that it arrives, and confirm receipt in SMSocial. Changing the email configuration invalidates the previous readiness confirmation.

Make the community look like your network.

SMSocial → Branding is the canonical source for the public network identity. Administrators can configure the network name, short PWA name, Access headline/supporting text, accent/application background colours, main logo, login showcase artwork and installable app icon.

Brand media is stored through the WordPress Media Library after validation. Portable settings export can include textual and colour settings, but local media attachment IDs are intentionally not portable between WordPress installations.

Languages

English is the source/fallback language. SMSocial currently includes first-party Bulgarian, German and Spanish translations. The selected SMSocial language can be changed from Access and from the in-app Context area without forcing WordPress, the active theme or unrelated site content into the same locale.

Public identity and account-owned profile settings.

Public Profile and Profile Settings are separate SMSocial routes. Display name remains tied to the WordPress account. SMSocial stores social profile fields such as bio, visibility and profile media.

Profile visibility is enforced by SMSocial identity policy. Ownership is checked on write operations, mutations are rate-limited and route caches are invalidated after successful changes.

One canonical Activity model across SMSocial.

The Feed is not a separate content silo. SMSocial Activity is the canonical social record used across Feed, Profile, Groups, Pages, Discover, Saved and native video entry points. This keeps reactions, comments, shares, visibility and deletion state synchronized.

Publishing

• Text posts and highlighted text posts.
• Image/media attachments through the native Composer.
• Native video posts.
• Poll/media capabilities where exposed by the active build.
• Visibility/ownership rules enforced by the canonical Activity policy.

Interactions

Reactions, canonical comments, sharing, saving and post actions operate on the same Activity identity. Removing an Activity through moderation or deletion therefore removes it consistently from surfaces that render the canonical record.

On desktop, Enter can submit supported post/comment/message forms while Shift+Enter inserts a new line. Mobile keyboard behaviour remains touch-oriented.

Followers, following and accepted connections.

SMSocial separates directional following from accepted connections. People discovery/search helps members find profiles; Network presents the signed-in member’s social graph and pending connection requests.

• Follow is directional.
• Connection requires acceptance.
• Blocking/restriction policy can override active social relationships.
• Private messages between people are available only where the messaging policy allows them, including accepted connection boundaries.

Private first-party conversations.

Messages use a protected SMSocial conversation layer rather than public Activity. Desktop uses a two-pane workspace; mobile uses a dedicated full-screen experience with separate conversation-list and thread states.

• Private conversations with policy/relationship checks.
• Auto-growing composer and touch-safe mobile controls.
• Private message attachments are protected and encrypted at rest.
• Attachments are delivered as protected downloads rather than exposed as normal public files.
• REST reads/writes require authentication, permission checks and no-store response boundaries.

One notification state across the application.

Notifications are part of the authenticated SMSocial shell. Counters, list state and navigation use the same notification source rather than separate duplicated UI stores. Opening notification destinations should preserve normal route behaviour and authenticated privacy boundaries.

Community spaces with roles and moderation.

Groups use canonical Activity for posts while adding group membership and moderation policy around it.

• Public/private membership models supported by the current Group policy.
• Owner, administrator, moderator and member role boundaries.
• Private-group membership approvals.
• Group rules and announcement fields.
• Member management, search and bans.
• Group-scoped reports and moderation queue.

Public identities for organisations, brands and projects.

Pages have their own public presentation and owner/admin workspace while Page posts still resolve through canonical SMSocial Activity. Page profile/cover media, following and Page publishing are managed without creating a second reaction/comment system.

Community event discovery and RSVP.

SMSocial Events currently supports future scheduling, timezone, venue or online location, public/members/private visibility and RSVP state.

• Event discovery and detail views.
• Going / Interested / Remove RSVP states.
• Attendee counts and preview.
• Compact event cover media and responsive creation experience.

Current scope: recurring events, event invitations, event discussions, organiser analytics and built-in ticket inventory/orders/payments are not core SMSocial event features at this stage.

Community classified listings.

Marketplace is a social classified-listing layer. Sellers can create listings, add a validated cover image and manage lifecycle state such as Active, Sold and Archived.

Important: SMSocial Marketplace does not provide built-in checkout, payment processing, shipping or fulfilment. It is intentionally provider-neutral.

Short-lived Story visibility without deleting Activity.

Stories use a compact rail and the same underlying SMSocial social state. Administrators can configure how many Story cards are shown and how long they remain visible in the Story rail.

• Default rail count: 20 Stories.
• Default visibility window: 24 hours.
• Admin-configurable count: 1–100.
• Admin-configurable window: 1–720 hours.
• Expiry removes the item from the Stories rail; it does not automatically delete the underlying Feed Activity.

Native video, compatibility processing and adaptive delivery.

Native video remains attached to canonical Activity, so ownership, visibility, reactions, comments, shares, saves, reporting and deletion remain synchronized with the rest of SMSocial.

Basic playback

The original MP4 remains the authoritative fallback. Native video can open the immersive viewer from Feed, Profile, Groups, Pages, activity collections and Videos without creating duplicate social state.

FFmpeg / HLS

When FFmpeg, FFprobe and the required PHP process capability are available, SMSocial can generate useful HLS variants such as 360p, 720p and 1080p without intentionally upscaling normal source video. Processing is queued and retried in bounded background jobs. If the processing stack is unavailable, publication is not blocked; SMSocial falls back to the original compatible MP4.

Compatibility processing

Problematic MP4 codecs can be normalized to broadly compatible H.264/AAC delivery when the server processing tools are available.

Private HLS delivery

Generated derivatives are served through an authenticated gateway that re-checks Activity visibility. Optional S3/R2/S3-compatible private storage can hold generated derivatives while SMSocial remains responsible for authorization.

Private saved Activities and collections.

Saved is owner-only. A member can save any Activity they are currently allowed to view, create private collections and place one saved item into multiple collections.

• No public Saved directory.
• No public save count is required by the private Saved contract.
• Collection names and membership are private to the owner.
• Visibility is re-checked when a saved Activity is loaded, so saving never bypasses later privacy changes.
• Deleting a collection does not delete the source Activity.

Report handling with evidence and audit history.

SMSocial has a canonical moderation layer for Activity/post reports. Moderators with the SMSocial moderation capability can review cases without exposing case data publicly.

• Start review.
• Remove content through the canonical Activity soft-delete path.
• Resolve with no action.
• Dismiss a report.
• Reopen a case.
• Append-only audit records for moderator decisions.
• Immutable evidence snapshots for review integrity.

Current moderation foundation focuses primarily on Activity/post reports. Additional reporting domains can be introduced separately as the trust-and-safety surface expands.

WordPress privacy tools plus SMSocial social-data handling.

SMSocial integrates with WordPress privacy export/erasure workflows for supported SMSocial data. WordPress remains the canonical account owner.

• SMSocial export avoids authentication tokens, OTP hashes, pending encrypted email records and protected attachment storage tokens.
• Erasure is designed to be repeatable/batch-safe for supported social data.
• Private message files uploaded by the requesting user can be removed together with supported attachment metadata.
• Deleting/erasing SMSocial data is not the same as deleting the WordPress user account.
• Some integrity-protected moderation evidence or ownership records may require an explicit site-owner decision rather than silent automatic rewriting.

Security boundaries used by SMSocial.

SMSocial security controls do not replace normal WordPress/server hardening, patching, backups, least-privilege access, malware monitoring or professional penetration testing.

Installable app behaviour with a privacy-safe cache boundary.

The isolated SMSocial application can expose a Web App Manifest and service worker. The service worker is intentionally limited to versioned first-party SMSocial static assets.

• Authenticated HTML is not cached as offline social content.
• SMSocial REST responses, messages, notifications, uploads, media files and video streams are not placed in the static PWA cache.
• Offline mode returns a generic shell rather than cached private community data.
• Route lifecycle includes in-memory route caching, invalidation, scroll restoration and connection-aware prefetch behaviour.

Settings, roles, System Health and diagnostics.

SMSocial uses its own administration shell and SMSocial-specific WordPress capabilities. Administrator retains the full SMSocial management capability set.

Core capability model

Role synchronization changes SMSocial capabilities only; it does not rewrite arbitrary WordPress core capabilities.

System Health

Health checks are read-only and scoped to SMSocial resources and required WordPress services. Use System Health after installation, after infrastructure changes and after upgrades.

Tools & support diagnostics

SMSocial includes bounded repair/diagnostic tooling such as settings/role checks, redacted support export, SMSocial cron visibility and error/trace diagnostics. Support reports are designed to omit secrets and sensitive values.

Start here when something does not behave as expected.

Final checks before inviting members.