Sprigly

Changelog

1.5.1

• Updated: Industry/Category dropdown refreshed. Removed “Therapy / Counselling”, renamed “Business Mentoring” to “Mentoring”, added “Creative / Performance”. Existing journey records keep their stored category.
• Updated: Plugin description and audience copy refreshed for non-clinical practitioners (coaches, mentors, trainers, tutors, instructors, teachers).
• Updated: WordPress.org tags refreshed (added “wellness” and “mentoring”, removed “therapist” and “progress tracker”).
• Updated: Client-facing role auto-fill includes “teacher” suggestion for the new Creative / Performance category.

1.5.0

• First public release on WordPress.org. No functional changes from 1.4.3.

1.4.3

• Full-site backup heads-up on the Backup/Restore page. A new yellow callout under the existing description paragraph reminds operators that Sprigly snapshots cover only Sprigly’s own database tables and aren’t a substitute for a full-site backup. Suggests running regular hosting-provider or backup-plugin backups (UpdraftPlus, BlogVault, Solid Backups) so a corrupted database has a fallback that doesn’t live in the same database. Display only, no behaviour change.

1.4.2

WordPress.org pre-approval response cycle 3: addresses the two issues flagged in the third reviewer email (escape-on-output and unique prefixes).

• Escape on output. The chronological timeline inside each milestone card on the admin client-profile page now wraps the rendered HTML in wp_kses_post() before echoing. The two affected echoes ($milestone_card_extras from the sprigly_admin_enrolment_milestone_card_extras extension point, and $sp_item['html'] from the sprigly_admin_milestone_timeline_items filter) previously trusted contributing renderers to pre-escape; they now late-escape regardless, so a future filter callback returning unfiltered HTML cannot inject into the admin screen.
• Unique prefixes. Two remaining classes still using the short SP_ prefix are renamed to the standard Sprigly_ prefix: SP_Backup becomes Sprigly_Backup and SP_Admin_Safety becomes Sprigly_Admin_Safety. Both ship a class_alias() for backwards compatibility so any external code that still references the old names keeps working. The wp_localize_script JS object handed to portal-reflection.js is renamed from spReflectionStrings to spriglyReflectionStrings (the JS file is updated in lockstep).
• Option-key migration. Three residual sp_* keys missed by the v1.2.0 prefix migration are now handled. A new upgrade_to_1_4_2_rename_residual_sp_options() routine copies values for sp_portal_page_id to sprigly_portal_page_id and sp_suspended_practitioners to sprigly_suspended_practitioners, then renames the _sp_client_id post meta key on reflection attachments to _sprigly_client_id in place. Idempotent. The legacy admin_post_sp_send_test_email and admin_post_sp_send_bug_report aliases (kept for the v1.2.0 to v1.3.0 transition) are removed; the canonical sprigly_* action hooks remain. Stale _sp_* references in doc comments are corrected to match the live _sprigly_* keys.
• Paused enrolment fallback. When a Pro user lets their license lapse with paused enrolments still on the books, those clients used to be stranded. Lite recognised the paused status but had no UI to transition out of it (Pro’s Pause/Reactivate buttons hide when is_pro() returns false). Lite now renders a Reactivate button for paused enrolments whenever no add-on is hooked to sprigly_client_status_actions, so a Pro to Lite downgrade can never lock the practitioner out of their own data. The button posts new_status=active through the existing update_client_status handler (which already accepts active in its default whitelist, no DB layer change needed).
• Cleanup-deleted-user no-ops on missing tables. Sprigly->cleanup_deleted_user() now early-returns when the sp_journeys table does not exist on the site. Previously, when WordPress fired deleted_user on an install where Sprigly was loaded but its tables had never been created (or had been dropped by a cleanup utility), the cascade fired several queries against missing tables and flooded debug.log on every WP user deletion. The guard is one SHOW TABLES LIKE per call.
• Em-dash cleanup across user-facing strings. ~28 em-dashes in admin info boxes (Settings → Branding, Tools, License, SMTP setup), portal page titles, system-page labels (Sprigly: Do not delete), client-profile and journey-list dropdown placeholders (Select journey..., Select user..., Select...), bug-report email subject, and admin notices are replaced with commas, periods, parentheses, or colons depending on context. Single em-dash placeholders for empty values (Phone, Industry, First Assigned columns) become empty strings. Code comments and error_log() debug output are unchanged. Internal punctuation only, no behaviour change.

1.4.1

Follow-up release after v1.4.0 testing. Bundles 16 fixes flagged during the cycle-2 reviewer-response testing pass plus a security tightening on the Backup/Restore admin.

• Preview Journey is no longer in Sprigly itself. The 1-hour signed-token preview link is removed from Lite entirely (no preview code, no preview button, no preview-mode body class). Preview returns to being an add-on-only feature, with neutral extension points in class-sp-portal.php (sprigly_portal_skip_auth_check, sprigly_portal_skip_form_actions, sprigly_portal_skip_role_autorestore, sprigly_portal_resolve_user_id, sprigly_portal_skip_render_dispatch + sprigly_portal_render, sprigly_portal_url, sprigly_portal_body_class, sprigly_portal_after_shell_open, sprigly_portal_nav_html, sprigly_portal_head) so add-ons can re-implement preview without Sprigly carrying any preview-specific code itself. The Settings → Upgrade tab lists Preview Journey again under Authoring & workflow.
• Backup/Restore is owner-only. The Settings → Backup/Restore tab, its render, and its post handler are gated on the designated Sprigly owner instead of the generic manage_options capability, so a hosting account, web designer, accountant, or any other non-owner administrator on the site cannot create, restore, or delete snapshots.
• ensure_admin_practitioner_role() no longer leaks the sprigly_practitioner role to every WordPress administrator on admin_init. Pre-v1.4.1 the helper auto-added the role to ANY user with manage_options, which meant a brand-new WP admin (hosting account, web designer, etc.) was silently treated as a Sprigly practitioner the first time they loaded wp-admin: they showed up in Sprigly → Team and saw the full Sprigly menu. The auto-grant is now scoped to the designated Sprigly owner. Non-owners only become practitioners through an explicit Team → Invite Practitioner / “Add me as a practitioner” banner / practice-setup form path.
• is_practitioner() no longer treats every WordPress administrator as a Sprigly practitioner. Only the designated owner OR users explicitly carrying the sprigly_practitioner role pass the helper now.
• Reflection save flow keeps the client moving. Marking a milestone complete now redirects back to the same milestone view (with the Continue to next milestone CTA already on screen) instead of bouncing to the journey overview. The locked “Up next” line is rendered as a styled disabled button matching the unlocked Continue button instead of as plain text.
• Snapshot operation messages reference timestamps instead of internal #IDs, matching the table’s “When” column. Post-update snapshots now also fire on single-plugin updates (the previous handler only listened for the plugins plural array key, missing the plugin singular set by core’s standard upgrade flow).
• Per-enrolment “Remove Client” button renamed to “Unenrol from this journey”, with confirm copy that makes it explicit the unenrol is per-journey and the client account stays put. A separate “Delete client account” destructive action lives under a danger-zone block on the Client Directory profile page, with cascade-delete of all the practitioner’s enrolments + reflections + attachments and a tenant-aware skip when the client is also enrolled with another practitioner.
• Plugin Check warning at class-sp-admin-settings.php:191 (WordPress.Security.ValidatedSanitizedInput.InputNotSanitized) is suppressed with a phpcs:ignore comment naming the per-type whitelist (sanitizer_for_type) — sanitization is happening, just dynamically dispatched.

1.4.0

WordPress.org pre-approval response cycle 2: this release lands the changes flagged in the second reviewer email so the plugin can clear the trialware, attribution, sanitization, hardcoded-URL, and text-domain checks.

• Trialware cleanup. Two features the reviewer flagged as “implemented but locked” are resolved at the source. (1) Preview Journey is now a free, fully functional Sprigly feature: the “Preview Journey” button renders directly on the journey edit screen for every user, with the same 1-hour signed-token preview link that previously existed only when the Sprigly Pro add-on was active. (2) The “Paused” enrolment status is no longer exposed in Sprigly itself; the status filter dropdown now lists only the statuses Sprigly can actually transition into (Active / Completed / Archived), with sprigly_admin_client_filter_status_options available for add-on plugins that introduce additional workflow states.
• “Powered by Sprigly” footer is now opt-in. The credit link in the client portal footer and in client-facing emails is OFF by default. A new “Powered by Sprigly footer” checkbox in Settings → Branding is the explicit opt-in control; the credit only renders when the site administrator ticks it. Existing installs that previously relied on the on-by-default behaviour will see the credit disappear until the admin opts in via the new setting.
• Per-option sanitization on register_setting(). The single generic sanitize_text_field callback is replaced by per-option sanitizers driven by an explicit type schema: esc_url_raw for logo URLs, bounded absint (with min/max) for the login-logo and nav-logo heights, sanitize_hex_color for the brand colour, and a yes/no whitelist for toggles. The custom save handler in Settings → Branding now routes every posted value through the same sanitizer table, so writes via the Settings UI and writes via the Options API stay consistent.
• home_url('/wp-login.php?...') replaced with wp_login_url() + add_query_arg() in the SiteGround Security login-redirect branch (class-sp-portal.php), so subdirectory installs and renamed-login plugins resolve the login URL correctly.
• Two __( '...', 'default' ) calls in the Plugins-page row-meta de-duplication helper are removed. The helper now compares against the canonical English labels emitted by WordPress core; a non-English locale may show a benign extra row-meta link, which is the smaller of the two trade-offs.
• Code-comment scrub. Every “Pro feature”, “Pro extends”, “Pro hooks here”, “Pro plugin”, “Pro tier”, “Pro overrides”, “Lite/Pro extension point”, and similar phrase across class-sp-portal.php, class-sp-email.php, class-sp-roles.php, class-sp-database.php, class-sp-install.php, class-sp-login.php, class-sp-admin-clients.php, class-sp-admin-journeys.php, class-sp-admin-settings.php, and class-sp-admin-menus.php is rewritten in neutral “extension point” / “add-on plugins can hook here” language. The Settings → Upgrade tab no longer lists Preview Journey or Hide Powered by Sprigly as Pro features (Preview is free now; the Powered by toggle ships in Sprigly itself).
• count_hidden_pro_features() and count_hidden_pro_features_for_milestone() helpers (which existed in Lite solely to support the add-on’s downgrade-detection email + dashboard banner) are removed from class-sp-database.php. The add-on plugin owns this functionality at its own callsite now.
• CRUD scrub. SP_Database::insert_journey() / update_journey() no longer write sequential_mode; SP_Database::insert_milestone() / update_milestone() no longer write milestone_type, unlock_type, unlock_date, unlock_days, or require_reflection. Add-on plugins that rely on those columns hook the existing sprigly_save_journey and sprigly_save_milestone actions to persist them via direct $wpdb->update() (the patterns Sprigly Pro already uses). Database schema is unchanged so existing rows keep their values.
• Inline <style> block on the file-proxy notice page (the page rendered when a portal user requests a private file via /?sp_file=ID and the lookup fails) is moved to a real stylesheet at assets/css/portal-notice.css. The notice page exits without firing wp_head/wp_footer, so it manually calls wp_register_style() + wp_enqueue_style() + wp_print_styles() to emit a standard <link rel="stylesheet"> tag. No visual change, just compliance.

1.3.4

• Backups moved into Settings. The “Safety & Backups” admin submenu link has been retired; its contents now live under Sprigly, Settings, Backup/Restore (sits between Tools and License). The two inner sub-tabs (Snapshots, Settings) are unchanged. The page is still admin-only (manage_options), so non-owner admins with manage_sprigly cannot see it even though they can reach the rest of Settings. All existing snapshot / restore / delete / prune / save handlers and URLs were re-pointed at the new tab; no data migration needed.

1.3.3

• WPCS / Plugin Check cleanup on the new Safety & Backups stack. class-sp-admin-safety.php: display-only $_GET reads (active tab, post-redirect notice text) wrapped in a scoped phpcs:disable WordPress.Security.NonceVerification.Recommended block (no form data is processed there); five sprintf( __() ) strings carrying numeric placeholders gained translators: comments; the settings save handler extracts retention_days and keep_minimum via absint( wp_unslash( $_POST[…] ) ) so WPCS sees them as sanitized (the previous inline (int) cast was equivalent at runtime but not recognised by the input-sanitization rule). class-sp-backup.php: every $wpdb call against the snapshot tables annotated with targeted phpcs:ignore for WordPress.DB.PreparedSQL.InterpolatedNotPrepared, WordPress.DB.DirectDatabaseQuery.{DirectQuery,NoCaching,SchemaChange}, and PluginCheck.Security.DirectDB.UnescapedDBParameter (table identifiers are not parameterisable; names come from SP_Database::table() / self::get_manifest_table() plus a server-generated gmdate + wp_generate_password suffix, so no user input touches the SQL string). No behaviour change.

1.3.2

• SP_Portal::write_protection_files() now accepts an optional $practitioner_id argument. When supplied, the helper creates /uploads/sprigly/{practitioner_id}/ and drops an empty index.html inside it (so directory listing is blocked even on hosts with Options +Indexes enabled). Pairs with Sprigly Pro v2.2.53, which uses this to partition reflection + resource uploads into per-practitioner subfolders. Lite-only installs are unaffected (Lite has no file upload features); the helper just exposes the new arg for Pro to consume.

1.3.1

• Snapshot retention default lowered from 60 days to 30 days. Halves baseline disk usage on new installs (~30 nightly snapshots instead of ~60). Existing customers keep saved settings. The ‘keep at least N most recent’ floor (default 5) is unchanged. Configurable on the Safety tab.

1.3.0

• New, Safety & Backups page (Sprigly, Safety & Backups, admin only). Snapshot/restore for the nine Sprigly DB tables (journeys, milestones, clients, progress, reflections, notes, resources, custom fields, field responses). Snapshots live on the customer’s own database, nothing is sent off-site. Restores are reversible: a pre-restore safety snapshot is taken automatically before live data is overwritten. The Restore confirmation explicitly warns that ALL practitioners’ data on the site is replaced. Three operator-controlled toggles in Settings: nightly auto-snapshot (default ON), post-plugin-update snapshot (default ON), and the manual snapshot button (always available regardless). Retention defaults to 60 days with a minimum of 5 most-recent always kept. Page is gated to manage_options (the practice owner / WP admin), hidden from team practitioners. No activity log, no per-practitioner view: this is a backend safety net, not a monitoring tool. New tables: wp_sp_backup_manifest (snapshot ledger) plus per-snapshot wp_sp_*_bak_* copy tables.

1.2.26

• UX, mobile clients table: removed the 120px hard cap on Actions-cell buttons so the v1.2.24 form full-width fix actually takes effect. v1.2.24 lifted the cap on the FORM child (so Pro’s Resend Welcome form could span full row when wrapped) but a sibling rule on .button, button direct children still capped each button at 120px, which kept the button INSIDE the form at 120px even when its form parent had grown to 100%. Lifted the button cap to 100% to match. With flex: 1 1 auto on every Actions-cell child, View / Edit / Remove still distribute the row width evenly when they fit on one line, and the wrapped Resend Welcome (Pro) now actually fills its row.

1.2.25

• Bug fix, Settings, Branding tab: the Login Page Logo and Portal Nav Logo previews are now scheme-normalised so an http:// upload URL doesn’t trigger a Mixed Content warning when the admin page is served over https://. Same set_url_scheme() fix as v1.2.19’s portal nav and v2.2.38’s branded login page; the Branding admin preview was the third render path that was missed. The hidden form inputs intentionally keep the original (un-normalised) value so saving the form doesn’t silently rewrite the option, scheme normalisation stays a display-only concern.

1.2.24

• UX, mobile clients table: Actions cell child forms (e.g. Pro’s Resend Welcome, Pro’s Pause/Reactivate) can now grow to the full cell width when wrapped to their own row. The mobile rule on .sp-table-clients td[data-label="Actions"] form had max-width: 120px !important from when those forms only ever fit alongside View / Edit / Remove. Bumped to max-width: 100% !important so a wrapped form gets a comfortable full-width tap target instead of staying capped at 120px. Sibling buttons in the same cell still cap at 120px (unchanged) so the View / Edit / Remove row stays balanced.

1.2.23

• Plugin Check pass: trimmed the readme.txt Changelog section to the most recent four releases so it fits under the 5000-character limit Plugin Check enforces. Older entries (v1.0.0 → v1.2.19) are preserved verbatim in CHANGELOG.md inside the plugin folder, alongside the pre-split monolithic v1.30.x history. No code changes.

1.2.21

• UX, “Protect data on uninstall” toggle on Settings → Tools is now visible only to the Sprigly Owner. Pre-1.2.21 the form rendered for every admin who could reach the settings page, even though handle_save() already rejected non-owner saves with a wp_die() (so non-owners could TRY to change the value but the change wouldn’t persist). The visible-but-inert form was confusing — admins saw the checkbox in their preferred state, clicked Save, were dumped on a wp_die page, and had no obvious “this is owner-only” signal. Now non-owners see a read-only status block instead: “Status: Data is protected — deleting the plugin will keep your journeys, clients, milestones, reflections, and settings. Only the Sprigly Owner can change this setting. Contact the owner if it needs adjusting.” The owner sees the form unchanged. Server-side gate at handle_save() line 95 stays as defence-in-depth. The amber “Data protection is OFF” warning still renders for all admins regardless of who can edit, since they all need to know if the site is currently in the unprotected state.

Earlier releases

• For the full Lite changelog (1.0.0 -> 1.2.19) plus the pre-split monolithic v1.30.x history, see CHANGELOG.md inside the plugin folder. Older entries are kept in a separate file so the readme.txt Changelog section fits under WordPress.org’s 5000-character limit.