SMSocial

SMSocial Core provides the free local foundation for building a social community on WordPress. The WordPress.org distribution includes member profiles, canonical activity/feed publishing, people discovery, follows and connections, privacy controls, account security, responsive application navigation, reactions, comments, sharing and saved activity. This WordPress.org package does not contain paid feature implementations or commercial runtime and does not use an external licence server to unlock functionality. Optional commercial add-ons are distributed separately by SMitov and are not required to use SMSocial Core. SMSocial creates new accounts through email verification. Site owners can configure a transactional email provider before enabling new registrations. External services SMSocial does not contact a fixed external service unless a site administrator or member uses a feature that requires it. The following connections can occur:

• Postmark API (optional transactional email): used only when the administrator selects Postmark and supplies a server token. Recipient email addresses, message content and delivery metadata required to send the message are transmitted when SMSocial sends transactional email. Service: https://postmarkapp.com/ ; Terms: https://postmarkapp.com/terms-of-service ; Privacy: https://postmarkapp.com/privacy-policy
• Custom SMTP (optional transactional email): used only when the administrator supplies an SMTP server. Recipient email addresses, message content, delivery metadata and the configured SMTP credentials are sent to that administrator-selected mail server when email is sent. The terms and privacy policy are those of the SMTP provider selected by the administrator.
• External link previews: when a member asks SMSocial to preview a public external URL, the site server sends a bounded HTTP GET request to the URL supplied by that member so it can read public title, description, image and article-preview metadata. The remote website receives the normal server network information, the requested URL and HTTP headers; SMSocial's User-Agent also identifies the SMSocial version and the WordPress site's home URL. No SMSocial password or private account credential is sent. Because the destination is chosen by the member rather than being a fixed SMSocial provider, that destination website's own terms and privacy policy apply.
• YouTube embedded player: when a post containing a supported YouTube link is viewed, the browser can load the privacy-enhanced YouTube player from youtube-nocookie.com. The video identifier and normal browser/network request information are sent to Google/YouTube. Terms: https://www.youtube.com/static?template=terms ; Privacy: https://policies.google.com/privacy
• Vimeo embedded player: when a post containing a supported Vimeo link is viewed, the browser can load player.vimeo.com. The video identifier and normal browser/network request information are sent to Vimeo. Terms: https://vimeo.com/legal/ ; Privacy: https://vimeo.com/privacy
• TikTok embedded player: when a post containing a supported TikTok video link is viewed, the browser can load www.tiktok.com/player/. The video identifier and normal browser/network request information are sent to TikTok. Terms: https://www.tiktok.com/legal/page/eea/terms-of-service/en ; Privacy: https://www.tiktok.com/legal/page/eea/privacy-policy/en
• Dailymotion embedded player: when a post containing a supported Dailymotion link is viewed, the browser can load www.dailymotion.com/embed/. The video identifier and normal browser/network request information are sent to Dailymotion. Terms: https://legal.dailymotion.com/en/terms-of-use/ ; Privacy: https://legal.dailymotion.com/en/privacy-policy/

These connections are feature-driven; SMSocial does not transmit a site's member database to these providers.

0.17.0

• First public SMSocial Core release, based on the verified WordPress.org Core line with security hardening and first-load DB bootstrap optimization.
• Deep migration/table/column/index validation remains active for activation, DB-version changes and explicit System Health/diagnostics.
• Identity, Social Graph, Activity, Reactions, Comments, Shares and Saved deep health/count checks now run only during cold validation bootstraps.
• Added request-local memoization for schema introspection and migration-ledger reads during deep checks.
• The runtime schema stamp is persisted only after the complete SMSocial module graph boots successfully.
• DB schema remains 31.

0.17.0-beta.2-wporg.9.4.1

• Place canonical WordPress nonce verification directly in every SMSocial admin action handler before request data is consumed.
• Keep capability checks separate and explicit; no nonce suppression is used.
• DB schema remains 31.

0.17.0-beta.2-wporg.9.4

• Security Audit Gate 1: moved admin-post CSRF enforcement to canonical WordPress nonce verification after capability checks.
• Removed the broad admin nonce-warning suppression rather than masking static security findings.
• Hardened email-first identify/resend responses so public callers cannot distinguish existing from new accounts by response shape, while preserving bounded rate limits and the new-account verification email flow.
• Kept authentication failures inside SMSocial's redacted diagnostics channel and corrected the corresponding administrator guidance.
• Re-reviewed REST authorization, SQL preparation, uploads, SSRF boundaries, redirects, escaping and session controls.
• DB schema remains 31.

0.17.0-beta.2-wporg.9.3

• Rebuilt the Core Code Split from the verified wporg.8.1 UI baseline.
• Removed optional commercial backend modules, REST controllers and JavaScript runtime from the Core package.
• Preserved the shared frontend and administration shells used by Core features.
• Stopped rendering inactive Messages/Notifications top-bar placeholders in Core; those entry points now appear only when an extension is actually available, and removed the Events development-status card.
• Kept schema-31 migration compatibility for existing SMSocial-owned data.
• Added a no-persistence extension boundary for separately installed optional add-ons.

0.17.0-beta.2-wporg.8

• WordPress.org repository hygiene pass.
• Closed remaining actionable nonce/input findings while preserving opaque credentials and validated JSON imports.
• Removed direct PHP debug-log sinks from the Core package in favour of the internal redacted diagnostics channel.
• Prefixed template-scope variables and made SMSocial social-graph hooks literal.
• Documented intentional use of WordPress core lifecycle hooks and cache interoperability constants.

0.17.0-beta.2-wporg.6

• WordPress.org security-input cleanup and policy-boundary pass.
• Added nonce protection to the SMSocial admin-language preference links.
• Sanitized read-only route, session, server-context and media selector inputs.
• Removed WordPress.org Core licence activation and custom update administration paths.

0.17.0-beta.2-wporg.5

• Corrected remaining WordPress.org i18n translator-comment and renderer escaping findings.

0.17.0-beta.2-wporg.4

• WordPress.org error cleanup pass after SQL safety completion.
• Added i18n translator metadata and literal legal-page translations.
• Removed local process execution from the WordPress.org Core distribution.
• Replaced direct file deletion with WordPress file deletion helpers and documented intentional streaming boundaries.
• Added Tested up to metadata and direct-template access protection.
• No database schema change.

0.17.0-beta.2-wporg.3

• SQL safety cleanup pass 2: completed prepared identifier/value cleanup for the remaining dynamic repository queries.
• No database schema change.

0.17.0-beta.2-wporg.1

• First WordPress.org distribution preflight build.
• Removed the third-party updater and external licence-server runtime from the WordPress.org package.
• Reduced the public product catalogue to free Core capabilities only.
• Added WordPress.org-focused documentation and external-service disclosure.