Sprigly
| 开发者 | sprigly |
|---|---|
| 更新时间 | 2026年5月8日 09:35 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 6.9 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
详情介绍:
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:
- You create a Journey, a structured programme with named milestones (e.g. "Week 1 - Setting Your Foundation")
- You assign clients to that journey
- Clients log in at
/portal/on your WordPress site and see their journey, milestone by milestone - Clients complete milestones and write rich-text reflections
- You get notified when clients complete milestones (via the welcome email or the Pro upgrade for richer events)
- Everyone can see exactly how far along the journey they are
- Unlimited journeys, clients, milestones
- Branded client portal at
/portal/ - Custom portal name, navigation logo, and brand colour
- Portal welcome message at the top of every client's dashboard
- Journey Preview, see exactly how your clients will see a journey before you assign it (signed 1-hour link)
- 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 +
.htaccesshardening + 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
- 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
- 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
- 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
安装:
- Upload the plugin zip via Plugins → Add New → Upload Plugin, or install directly from the WordPress Plugin Directory
- Click Activate
- Go to Sprigly → Settings → Branding and set your portal name, logo, and brand colour
- Go to Sprigly → Settings → Tools and send a test email to confirm delivery
- Create your first journey at Sprigly → Journeys → Add New
- Add a client at Sprigly → Clients → Add / Edit Client and assign them to a journey
- The client receives a welcome email with their portal login link
/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.屏幕截图:
常见问题:
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.
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
更新日志:
1.6.1
Follow-up to 1.6.0. Trims the Settings, Upgrade to Pro tab now that Journey Preview and the Portal welcome message have moved into Lite, then surfaces three real Pro benefits that previously weren't called out on the upgrade page.
- Removed: "Preview Journey" bullet under Authoring & workflow (now a free Lite feature).
- Removed: "Portal welcome message" bullet under Branding (now a free Lite feature). The single-bullet Branding group is dropped entirely.
- Added: "Personalised email sender identity" under Communications. Calls out that client emails arrive as "Your Name from Your Brand" with replies routed to your inbox.
- Added: "Personal practitioner settings page" under a renamed "Practitioner accounts & Team" group. Highlights the per-practitioner profile, password, and data export/import surface that's distinct from site-wide admin (matters on solo Pro, essential on Team).
- Added: New "Updates" group with a single bullet for automatic Pro updates from sprigly.co (no manual zip uploads).
- UX: "See how this looks to your clients" hint on the Journey edit screen now sits as a description line directly below the Preview Journey button instead of running off to the right of it.
- Added: Journey Preview. The "Preview Journey" button now renders directly on every journey edit screen for every Sprigly user. Clicking it opens a 1-hour signed preview link that shows you exactly what your clients will see in the portal: the journey overview, milestone tracker, milestone detail pages, guidance text, video embeds, journey-wide and milestone resources, plus a disabled-input mock of the reflection editor. Pro users continue to see disabled placeholders for their Pro-only custom check-in fields inside the preview. New file
includes/class-sp-portal-preview.php(classSprigly_Portal_Preview). - Added: Portal welcome message. Settings, Branding now has a "Portal welcome message" textarea. Whatever you write there is rendered at the top of every client's portal dashboard, immediately under the "Welcome back, {name}" heading. Plain text or a tiny bit of HTML (sanitised via
wp_kses_post). Existing customers who had a welcome message set under the older Sprigly Pro keep their text intact:SP_Admin_Settings::read_portal_welcome()reads the canonicalsprigly_portal_welcomeoption first and falls back to the legacysp_portal_welcomekey on first read, promoting the value forward. - Added: New
'html'option type inSP_Admin_Settingswithwp_kses_postsanitiser, used by the welcome message field. - Added:
Sprigly_Admin_Journeys::render_preview_button()registered onsprigly_journey_edit_after_title. Defers gracefully if an older Sprigly Pro is loaded that still ships its own preview button. - Compatibility: Sprigly Pro 2.2.58+ removes its own preview and welcome implementations; Pro versions before that continue to render their own, and Lite's new code defers to them when present so customers don't see duplicate buttons or duplicate paragraphs during the upgrade window. Pro 2.2.58 requires Sprigly 1.6.0 or later.
- 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.
- First public release on WordPress.org. No functional changes from 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.
- 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_extrasfrom thesprigly_admin_enrolment_milestone_card_extrasextension point, and$sp_item['html']from thesprigly_admin_milestone_timeline_itemsfilter) 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 standardSprigly_prefix:SP_BackupbecomesSprigly_BackupandSP_Admin_SafetybecomesSprigly_Admin_Safety. Both ship aclass_alias()for backwards compatibility so any external code that still references the old names keeps working. Thewp_localize_scriptJS object handed toportal-reflection.jsis renamed fromspReflectionStringstospriglyReflectionStrings(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 newupgrade_to_1_4_2_rename_residual_sp_options()routine copies values forsp_portal_page_idtosprigly_portal_page_idandsp_suspended_practitionerstosprigly_suspended_practitioners, then renames the_sp_client_idpost meta key on reflection attachments to_sprigly_client_idin place. Idempotent. The legacyadmin_post_sp_send_test_emailandadmin_post_sp_send_bug_reportaliases (kept for the v1.2.0 to v1.3.0 transition) are removed; the canonicalsprigly_*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
pausedstatus but had no UI to transition out of it (Pro's Pause/Reactivate buttons hide whenis_pro()returns false). Lite now renders a Reactivate button for paused enrolments whenever no add-on is hooked tosprigly_client_status_actions, so a Pro to Lite downgrade can never lock the practitioner out of their own data. The button postsnew_status=activethrough the existingupdate_client_statushandler (which already acceptsactivein its default whitelist, no DB layer change needed). - Cleanup-deleted-user no-ops on missing tables.
Sprigly->cleanup_deleted_user()now early-returns when thesp_journeystable does not exist on the site. Previously, when WordPress fireddeleted_useron 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 floodeddebug.logon every WP user deletion. The guard is oneSHOW TABLES LIKEper 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 anderror_log()debug output are unchanged. Internal punctuation only, no behaviour change.
- 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_optionscapability, 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 thesprigly_practitionerrole to every WordPress administrator onadmin_init. Pre-v1.4.1 the helper auto-added the role to ANY user withmanage_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 thesprigly_practitionerrole 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 thepluginsplural array key, missing thepluginsingular 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.
- 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_optionsavailable 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 genericsanitize_text_fieldcallback is replaced by per-option sanitizers driven by an explicit type schema:esc_url_rawfor logo URLs, boundedabsint(with min/max) for the login-logo and nav-logo heights,sanitize_hex_colorfor the brand colour, and ayes/nowhitelist 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 withwp_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, andclass-sp-admin-menus.phpis 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()andcount_hidden_pro_features_for_milestone()helpers (which existed in Lite solely to support the add-on's downgrade-detection email + dashboard banner) are removed fromclass-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 writesequential_mode;SP_Database::insert_milestone()/update_milestone()no longer writemilestone_type,unlock_type,unlock_date,unlock_days, orrequire_reflection. Add-on plugins that rely on those columns hook the existingsprigly_save_journeyandsprigly_save_milestoneactions 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=IDand the lookup fails) is moved to a real stylesheet atassets/css/portal-notice.css. The notice page exits without firingwp_head/wp_footer, so it manually callswp_register_style()+wp_enqueue_style()+wp_print_styles()to emit a standard<link rel="stylesheet">tag. No visual change, just compliance.
- 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 withmanage_spriglycannot 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.
- WPCS / Plugin Check cleanup on the new Safety & Backups stack.
class-sp-admin-safety.php: display-only$_GETreads (active tab, post-redirect notice text) wrapped in a scopedphpcs:disable WordPress.Security.NonceVerification.Recommendedblock (no form data is processed there); fivesprintf( __() )strings carrying numeric placeholders gainedtranslators:comments; the settings save handler extractsretention_daysandkeep_minimumviaabsint( 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$wpdbcall against the snapshot tables annotated with targetedphpcs:ignoreforWordPress.DB.PreparedSQL.InterpolatedNotPrepared,WordPress.DB.DirectDatabaseQuery.{DirectQuery,NoCaching,SchemaChange}, andPluginCheck.Security.DirectDB.UnescapedDBParameter(table identifiers are not parameterisable; names come fromSP_Database::table()/self::get_manifest_table()plus a server-generatedgmdate + wp_generate_passwordsuffix, so no user input touches the SQL string). No behaviour change.
SP_Portal::write_protection_files()now accepts an optional$practitioner_idargument. When supplied, the helper creates/uploads/sprigly/{practitioner_id}/and drops an emptyindex.htmlinside it (so directory listing is blocked even on hosts withOptions +Indexesenabled). 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.
- 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.
- 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-snapshotwp_sp_*_bak_*copy tables.
- 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, buttondirect 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. Withflex: 1 1 autoon 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.
- 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 overhttps://. Sameset_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.
- 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"] formhadmax-width: 120px !importantfrom when those forms only ever fit alongside View / Edit / Remove. Bumped tomax-width: 100% !importantso 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.
- 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.mdinside the plugin folder, alongside the pre-split monolithic v1.30.x history. No code changes.
- 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 awp_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 awp_diepage, 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 athandle_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.
- 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.