Title: Sprigly
Author: sprigly
Published: <strong>May 4, 2026</strong>
Last modified: May 6, 2026

---

Search plugins

![](https://ps.w.org/sprigly/assets/banner-772x250.png?rev=3522119)

![](https://ps.w.org/sprigly/assets/icon-256x256.png?rev=3522119)

# Sprigly

 By [sprigly](https://profiles.wordpress.org/sprigly/)

[Download](https://downloads.wordpress.org/plugin/sprigly.1.5.1.zip)

 * [Details](https://en-ca.wordpress.org/plugins/sprigly/#description)
 * [Reviews](https://en-ca.wordpress.org/plugins/sprigly/#reviews)
 *  [Installation](https://en-ca.wordpress.org/plugins/sprigly/#installation)
 * [Development](https://en-ca.wordpress.org/plugins/sprigly/#developers)

 [Support](https://wordpress.org/support/plugin/sprigly/)

## Description

Sprigly gives practitioners a structured way to guide their clients through a journey,
and gives clients a beautiful portal where they can see exactly where they are, 
complete milestones, and write reflections.

Whether you’re a life coach, personal trainer, mentor, tutor, instructor, teacher,
nutritionist, or any kind of practitioner, Sprigly replaces scattered emails and
spreadsheets with a clear, trackable progress experience your clients will love.

**How it works:**

 1. You create a Journey, a structured programme with named milestones (e.g. “Week 
    1 – Setting Your Foundation”)
 2. You assign clients to that journey
 3. Clients log in at `/portal/` on your WordPress site and see their journey, milestone
    by milestone
 4. Clients complete milestones and write rich-text reflections
 5. You get notified when clients complete milestones (via the welcome email or the
    Pro upgrade for richer events)
 6. Everyone can see exactly how far along the journey they are

**What’s included in Sprigly (free, uncapped):**

 * Unlimited journeys, clients, milestones
 * Branded client portal at `/portal/`
 * Custom portal name, navigation logo, and brand colour
 * Welcome email when a new client account is created (always on)
 * Rich-text editor for milestone descriptions
 * Video URL embeds on milestone descriptions (YouTube, Vimeo)
 * Plain-text and clickable-URL reflections (Pro adds the rich-media embed)
 * Image lightbox in the portal
 * Standard milestone type with immediate unlock
 * Reflection privacy: file proxy + `.htaccess` hardening + media library filter
 * Self-hosted Poppins typography (no Google Fonts call-out)
 * Built-in SMTP plugin detection, test-email tool, bug-report form
 * Designated Sprigly Owner so multiple admins on one site can’t accidentally manage
   each other’s data
 * Mobile-responsive admin and portal

**Built for:**

 * Life coaches running structured programmes
 * Personal trainers with weekly check-ins
 * Mentors guiding clients through structured growth
 * Tutors and music teachers running multi-week courses
 * Nutritionists tracking client progress
 * Instructors, business coaches, and anyone running multi-step client work

**Available as a paid upgrade (Sprigly Pro, sold separately):**

Sprigly Pro is a separate plugin available from sprigly.co that adds the practitioner
toolkit on top of Sprigly Lite:

 * **Authoring and workflow:** checkpoint sign-offs, scheduled milestone unlocks,
   per-milestone custom check-in fields (7 input types) with required-field validation,
   Require Reflection toggle, sequential-only journeys, duplicate journey/milestone,
   bulk-add milestones, Preview Journey (signed 1-hour link)
 * **Client experience:** Resources library (PDFs, links, videos attached to journeys
   or specific milestones), practitioner notes per client and per milestone, video
   URL embeds in reflection bodies, file uploads on reflections (image, PDF, doc),
   re-enrol, pause, resend welcome
 * **Reports and data:** branded PDF Progress Reports, JSON export and import, Pro
   insights dashboard widget (pending sign-offs, average completion, reflections
   this week vs last)
 * **Communications:** 7 additional email events with per-event toggles (milestone
   completed, journey assigned, journey completed, reflection submitted, sign-off
   requested, practitioner note, checkpoint signed off), and a branded login page
   that matches your portal
 * **Multi-practitioner Team plan:** up to 5 practitioner seats with strict per-
   practitioner data isolation, branded invite emails, ownership transfer with a
   signed time-limited confirmation link
 * **Branding:** hide the “Powered by Sprigly” footer, portal welcome message

Pro requires Sprigly to be installed and active. Learn more at https://sprigly.co/
pricing/.

### External Services

Sprigly is designed to keep your client data on your own WordPress installation.
Plugin emails are sent through your site’s own `wp_mail()` (which you can route 
through any SMTP plugin you choose), and the plugin’s typography is loaded from 
font files that ship inside the plugin (no Google Fonts request, no preconnect).

There are two narrow exceptions where the plugin reaches out to a third party. Both
are documented below.

#### 1. YouTube and Vimeo oEmbed (only when you paste a YouTube or Vimeo URL into a milestone)

When a practitioner pastes a YouTube or Vimeo video URL into a milestone’s “Video
URL” field, Sprigly uses WordPress’s built-in oEmbed system (`wp_oembed_get()`) 
to fetch the embed metadata so the milestone page can show the video. This sends
one HTTP request to the relevant provider’s oEmbed endpoint to retrieve the iframe
HTML; the provider sees the milestone’s video URL plus a referrer header from your
site. The response is cached by WordPress for 24 hours, so subsequent page loads
do not re-fetch.

 * What is sent: the video URL the practitioner pasted (and the standard request
   headers WordPress emits, including a referrer pointing at your site).
 * When it is sent: when a portal page or admin page renders a milestone that contains
   a YouTube or Vimeo URL, and only on the first render within the 24-hour cache
   window.
 * Service providers and policies:
    - YouTube (Google LLC), https://policies.google.com/terms, https://policies.
      google.com/privacy
    - Vimeo, https://vimeo.com/terms, https://vimeo.com/privacy

The feature is opt-in by behaviour: pasting a video URL into a milestone is the 
only way to trigger it. Leave the field blank and Sprigly never contacts either 
service.

#### 2. Bug report email (only when you click “Send Bug Report”)

The optional Report a Bug form in Sprigly, Settings, Tools sends a single email 
through your site’s own `wp_mail()` to the Sprigly support address. The form is 
never submitted automatically. When you click the button, the email contains:

 * The description you typed in the form
 * The screenshot you attached, if any
 * The System Information block: Sprigly version, WordPress version, PHP version,
   site URL, active theme name, and the name of any SMTP plugin you have installed
 * What is sent: only what you typed plus the System Information block above.
 * When it is sent: only when you click “Send Bug Report”.
 * Service provider: Sprigly support (https://sprigly.co/), terms https://sprigly.
   co/terms-and-conditions/, privacy https://sprigly.co/privacy-policy/.

Sprigly’s Privacy Policy: https://sprigly.co/privacy-policy/
 Sprigly’s Terms and
Conditions: https://sprigly.co/terms/

## Screenshots

 * [[
 * Practitioner dashboard, with recent activity feed and per-client progress overview.
 * [[
 * Journeys list, where you manage and organise your client programmes.
 * [[
 * Milestone editor, with rich text descriptions and video URL embedding.
 * [[
 * Client list, with progress overview and one-click resend welcome email.
 * [[
 * Backup/Restore, with nightly auto-snapshots and reversible restore for safe data
   recovery.
 * [[
 * Client portal, a clean dashboard showing assigned journeys with progress.
 * [[
 * Client milestone page, with guidance and an inline reflection form.
 * [[
 * Branding settings, where you set your portal name, logos, primary colour, and
   footer credit.

## Installation

 1. Upload the plugin zip via **Plugins  Add New  Upload Plugin**, or install directly
    from the WordPress Plugin Directory
 2. Click **Activate**
 3. Go to **Sprigly  Settings  Branding** and set your portal name, logo, and brand
    colour
 4. Go to **Sprigly  Settings  Tools** and send a test email to confirm delivery
 5. Create your first journey at **Sprigly  Journeys  Add New**
 6. Add a client at **Sprigly  Clients  Add / Edit Client** and assign them to a journey
 7. The client receives a welcome email with their portal login link

**Important:** Set your WordPress permalink structure to **Post name** (Settings
Permalinks  Post name) before activating Sprigly. This is required for the `/portal/`
URL to work correctly.

**Recommended:** Install and configure an SMTP plugin (WP Mail SMTP, Post SMTP, 
FluentSMTP, or Easy WP SMTP) to ensure reliable email delivery. By default, WordPress
sends mail through your hosting server, which can be filtered or junked by Gmail/
Outlook/Yahoo. Sprigly detects an active SMTP plugin and shows its status in **Sprigly
Settings  Tools**.

## FAQ

### Does Sprigly work with any WordPress theme?

Yes. The client portal at `/portal/` is fully self-contained and does not inherit
your theme’s styles. It works correctly with any theme — including page builders
like Divi, Elementor, and Beaver Builder.

### Do clients need a WordPress account?

Yes, each client has a WordPress user account with the `sprigly_client` role. This
role gives them access only to the client portal — they cannot access wp-admin. 
Sprigly creates the account automatically when you add a client.

### Where is the client portal?

At `/portal/` on your WordPress site (e.g. `yourdomain.com/portal/`). You can find
the full URL in **Sprigly  Settings  Portal**. Share this link with your clients.

### What happens to my data if I deactivate the plugin?

Nothing, by default. The “Protect data on uninstall” setting is ON by default, which
means all your journeys, clients, milestones, and reflections are kept in the database
even if the plugin is deactivated or deleted. You can change this behaviour in **
Sprigly  Settings  Tools**.

### Does Sprigly work with my SMTP plugin?

Yes. Sprigly detects WP Mail SMTP, Post SMTP, FluentSMTP, and Easy WP SMTP automatically
and routes all email through whichever is active. We strongly recommend installing
an SMTP plugin for reliable delivery.

### Can I use my own branding?

Yes. You can set a custom portal name, upload separate logos for the login page 
and the portal nav bar, set logo heights, and pick a primary brand colour (used 
for buttons, progress bars, and accents in the portal and emails).

### Can I change how I’m referred to in client emails?

Yes. When creating or editing a journey, set the “Client-facing role” field to whatever
suits your profession, coach, trainer, mentor, teacher, tutor, instructor, guide,
etc. This replaces the default “practitioner” in all client-facing emails for that
journey. A suggestion is auto-filled based on the Industry/Category you select, 
but you can change it to anything you like.

### What does the paid Sprigly Pro plugin add?

Sprigly Pro (sold separately at sprigly.co) layers on the practitioner toolkit: 
checkpoint sign-offs, scheduled milestone unlocks, custom check-in fields, a Resources
library, practitioner notes, file uploads on reflections, branded PDF progress reports,
JSON export and import, multi-practitioner Team support, and a branded login page.
See https://sprigly.co/pricing/ for the full feature list.

### Does Sprigly contact any external services?

Sprigly keeps your client data on your own WordPress installation, sends emails 
through your own site’s `wp_mail()`, and ships its display font (Poppins) inside
the plugin so the portal does not contact Google Fonts.

There are two narrow situations where the plugin does reach out to a third party,
both opt-in by behaviour:

 * When a practitioner pastes a YouTube or Vimeo URL into a milestone’s Video URL
   field, Sprigly uses WordPress’s standard `wp_oembed_get()` to fetch the embed
   metadata from YouTube or Vimeo so the video can render. The response is cached
   for 24 hours.
 * When you click the optional “Send Bug Report” button under Settings, Tools, Sprigly
   emails Sprigly support with the description you typed plus a System Information
   block.

Both are documented in full in the External Services section of this readme, including
Terms and Privacy links for each provider.

### Is Sprigly GDPR-compliant?

Sprigly is built to support GDPR compliance. Client data is stored only on your 
own WordPress installation. You remain the data controller for all client data on
your site.

### How do I back up my Sprigly data?

Sprigly ships a built-in Safety & Backups page (Sprigly, Safety & Backups, admin-
only). It takes snapshots of all nine Sprigly DB tables (journeys, milestones, clients,
progress, reflections, notes, resources, custom fields, field responses) directly
inside your own database. Nothing is sent off-site. By default the plugin takes 
a snapshot every night and after every Sprigly plugin update, plus you can take 
a manual snapshot any time. Restores are reversible (a pre-restore safety snapshot
is taken automatically). Both automatic behaviours can be disabled in the Settings
tab. This is a safety net for routine “before I touch this” moments, your hosting
provider’s full-site backups remain the authoritative recovery path for catastrophic
loss.

### What are the hosting requirements?

 * PHP 7.4 or higher (PHP 8.0+ recommended)
 * WordPress 6.0 or higher
 * MySQL 5.7+ or MariaDB 10.4+
 * HTTPS (SSL certificate) — required for the client portal login

## Reviews

There are no reviews for this plugin.

## Contributors & Developers

“Sprigly” is open source software. The following people have contributed to this
plugin.

Contributors

 *   [ sprigly ](https://profiles.wordpress.org/sprigly/)

[Translate “Sprigly” into your language.](https://translate.wordpress.org/projects/wp-plugins/sprigly)

### Interested in development?

[Browse the code](https://plugins.trac.wordpress.org/browser/sprigly/), check out
the [SVN repository](https://plugins.svn.wordpress.org/sprigly/), or subscribe to
the [development log](https://plugins.trac.wordpress.org/log/sprigly/) by [RSS](https://plugins.trac.wordpress.org/log/sprigly/?limit=100&mode=stop_on_copy&format=rss).

## 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 `#ID`s, 
   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](https://en-ca.wordpress.org/plugins/sprigly/CHANGELOG.md?output_format=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.

## Meta

 *  Version **1.5.1**
 *  Last updated: **1 day ago**
 *  Active installations: **Fewer than 10**
 *  WordPress Version: ** 6.0 or higher **
 *  Tested up to: **6.9.4**
 *  PHP Version: ** 7.4 or higher **
 *  Language
 * [English (US)](https://wordpress.org/plugins/sprigly/)
 * Tags:
 * [client portal](https://en-ca.wordpress.org/plugins/tags/client-portal/)[coaching](https://en-ca.wordpress.org/plugins/tags/coaching/)
   [mentoring](https://en-ca.wordpress.org/plugins/tags/mentoring/)[wellness](https://en-ca.wordpress.org/plugins/tags/wellness/)
 *  [Advanced View](https://en-ca.wordpress.org/plugins/sprigly/advanced/)

## Ratings

No reviews have been submitted yet.

[Your review](https://wordpress.org/support/plugin/sprigly/reviews/#new-post)

[See all reviews](https://wordpress.org/support/plugin/sprigly/reviews/)

## Contributors

 *   [ sprigly ](https://profiles.wordpress.org/sprigly/)

## Support

Got something to say? Need help?

 [View support forum](https://wordpress.org/support/plugin/sprigly/)