Init Reading Position – Remember, Return, Continue
| 开发者 | brokensmile.2103 |
|---|---|
| 更新时间 | 2026年9月10日 03:26 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
详情介绍:
Init Reading Position enhances the reading experience by remembering how far a visitor has read on a post.\
When they return, it automatically scrolls back to where they left off.
Perfect for:
- Long-form articles
- Tutorials or guides
- Web novels or manga
- Any content where readers often stop and come back later
- Saves scroll position using localStorage (guests) or a dedicated database table (logged-in users)
- Smart device-based sync: remembers position separately for PC, Mobile, and Tablet
- Automatically scrolls back on page load
- Lightweight, no jQuery, no bloat
- Easy to extend via filters
- Optional settings page to control which post types are enabled
- Automatically cleans up orphaned data when a post or a user account is permanently deleted
- Optional, off-by-default housekeeping to remove abandoned or very old reading positions on large, long-running sites
安装:
- Upload the plugin folder to
/wp-content/plugins/or install via Plugins → Add New. - Activate the plugin.
- Go to Settings → Reading Position and choose which post types should support this feature.
常见问题:
Does it sync across devices?
Yes. For logged-in users, scroll position is stored in a dedicated database table, saved separately for each device type (PC, Mobile, Tablet).
Will it work with custom post types?
Yes. You can enable it for any public post type in the plugin settings page.
Will it slow down my site?
No. It only runs a small JS script on enabled single pages and stores data efficiently in a dedicated table with indexed queries.
Does it clean up after itself when a post or user is deleted?
Yes. When a post is permanently deleted, or a user account is permanently deleted, any reading positions pointing to it are automatically removed in the background — no leftover rows for content or accounts that no longer exist.
Does it delete my readers' progress automatically?
Not unless you turn it on. Two housekeeping options are available under Settings → Reading Position, both disabled by default:
- Clean up abandoned progress — removes a single saved position only when it hasn't been touched in a long time (configurable, default 365 days) and progress on it is very low (configurable, default under 10%). A position with high progress is always kept, no matter how old, since the reader may still come back to finish it.
- Clean up inactive accounts — removes all saved positions for an account once none of its reading positions, across every post, have been updated in a long time (configurable, default 730 days).
更新日志:
1.9 – September 10, 2026
- Added: Reading positions are now automatically deleted when their post or their user account is permanently deleted — previously these rows were left behind indefinitely, silently pointing at content or accounts that no longer exist
- Added: Optional "Clean up abandoned progress" setting (disabled by default) — periodically deletes a saved position only when it is both older than a configurable number of days (default 365) and its progress is below a configurable percentage (default 10%); positions with meaningful progress are never touched, no matter how old
- Added: Optional "Clean up inactive accounts" setting (disabled by default) — periodically deletes every saved position belonging to an account once none of its reading positions, across any post, have been updated in a configurable number of days (default 730)
- Improved: Both cleanup jobs run in small self-throttling batches via WP-Cron, walking the table by primary key (or by the existing
user_post_deviceindex prefix) — no new database index required, no long-running query, and no impact on sites that leave both options off - Improved: Turning a cleanup option on from the settings page starts the corresponding job right away instead of waiting for the next scheduled check
- No breaking changes — REST API, database schema, localStorage keys, and frontend behavior remain fully compatible; both new cleanup options ship disabled and change nothing unless explicitly enabled
- Fixed: The frontend script could fail to enqueue on every page of the site whenever the option controlling enabled post types had never been saved (fresh installs, or sites where the admin never opened Settings) — a mismatched default value caused the enabled post-type list to resolve to empty instead of the intended
postdefault - Fixed: Reading position saves could silently fail intermittently ("works, then doesn't") — the script previously marked a position as synced as soon as a save request was sent, without waiting for server confirmation; combined with server-side rate limiting on sites with a persistent object cache (Redis/Memcached), some saves were silently dropped while the script believed they had succeeded, resulting in stale or incorrect resume positions
- Added: The final save sent when a tab is hidden/closed now bypasses server-side rate limiting and always writes straight to the database — this is the last chance to persist unsaved progress, so it's no longer subject to being silently throttled or deferred away
- Improved: Save requests to the REST API now return an explicit
throttledstatus instead of a false "success" when rate-limited, so the script can correctly retry instead of assuming the position was saved - Added: On sites with a persistent object cache, heartbeat saves (the periodic safety-net sync sent while a reader keeps scrolling forward, as opposed to a real re-read reversal or the final save) are now written to cache instead of the database. This cuts sustained database write load dramatically on high-concurrency sites — e.g. a manga/webtoon theme with tens of thousands of simultaneously reading logged-in users — while page reloads still resume from the correct position, since reads are cache-first. Progress is always promoted to a real, durable database write at the next meaningful checkpoint (re-read reversal or tab close). Sites without a persistent object cache are unaffected and continue writing straight to the database, same as before
- Added: The heartbeat interval (default 30s) is now filterable via
init_plugin_suite_reading_position_heartbeat, letting high-traffic sites widen the safety-net cadence to further reduce request volume at peak hours without editing plugin files - No breaking changes — REST API, database schema, localStorage keys, and frontend behavior remain fully compatible
- Added: Behavior-based sync engine replacing the fixed 5-second timer — the script now only talks to the server on meaningful checkpoints (a real upward reversal while re-reading, an occasional heartbeat while continuously reading forward, or right before the tab is hidden/closed), cutting network requests dramatically for the common case of a reader scrolling straight through an article
- Improved: The furthest scroll position ever reached is what gets persisted, not the current position — scrolling back up to re-read a section never regresses the saved/resume point, for both logged-in users and guests (localStorage)
- Improved: Scroll and resize listeners are now registered as passive — the browser no longer waits on the handler before scrolling, removing a source of jank on scroll-heavy pages
- Improved: Full-page scroll height is now cached alongside scoped-element bounds instead of being read on every debounced scroll tick — avoids repeated layout-forcing reads; refreshed on resize and once after full page load
- Added: Best-effort final save on tab hide/close (
pagehide/visibilitychange) usingnavigator.sendBeaconwhere available — the last known position is no longer lost when a reader closes the tab between two sync checkpoints - Improved: Reading position lookups now skip the legacy user_meta fallback entirely once the user_meta → database migration is confirmed complete — removes 1-2 unnecessary lookups per uncached request on the vast majority of sites
- Improved: Removed a redundant
user_iddatabase index — it duplicated the leftmost prefix of the existinguser_post_deviceunique key, so dropping it removes unnecessary index-maintenance overhead on every write with no read-performance impact. Existing sites get this cleaned up automatically and safely, exactly once, on upgrade - No breaking changes — REST API, database schema (aside from the redundant index removal above), localStorage keys, and frontend behavior remain fully compatible
- Improved: Reading position retrieval is now handled via a single bulk query instead of multiple per-device lookups — reduces database queries and improves performance for logged-in users
- Added: Bulk cache layer for multi-device reading positions with a deterministic cache key (
pc_mobile_tablet) — ensures consistent cache hits and simplifies invalidation logic - Improved: Cache invalidation now clears both single-device and bulk cache entries — prevents stale data when users continue reading across sessions
- Improved: Data flow refactored to return all device positions (
pc,mobile,tablet) in one payload — frontend now selects the correct device slot dynamically - Fixed: Inconsistent cache key generation (previous md5-based keys) that could lead to stale or non-invalidated cache entries
- Fixed: Potential PHP notice when
savedPositionswas undefined for guest users — now always initialized with default values - Improved: Internal code cleanup and minor optimizations for better maintainability and consistency
- No breaking changes — REST API, database schema, localStorage keys, and frontend behavior remain fully compatible
- Improved: Device detection is now handled entirely by JavaScript — PHP no longer performs UA sniffing on the server side, eliminating mismatches between detected device on page load vs. save
- Improved: Saved scroll position lookup now tries all three device slots (pc, mobile, tablet) in order, so the correct position is always restored regardless of which device the user was last on
- Improved: Scope element bounds (
absTop,absBottom) are now cached after DOMContentLoaded and refreshed on window resize —getBoundingClientRect()is no longer called on every scroll event - Improved: REST API rate limiting switched from transient-based to
wp_cache-based — eliminates transient writes towp_optionson high-traffic sites; works best with an object cache (Redis/Memcached), degrades gracefully without one - Fixed:
autoClearOnEndwith no CSS selector configured would never trigger the end-of-content clear; now correctly falls back to page-bottom detection in that case - No breaking changes — REST API, localStorage keys, and all existing settings remain fully compatible
- Refactored: Migration now runs via a self-scheduling WP-Cron event instead of admin_init
- Added: Automatic re-scheduling every 30 seconds until migration completes
- Improved: Removed dependency on admin requests for background processing
- Improved: Added locking to prevent overlapping migration runs
- No breaking changes
- Added: Switched from user_meta storage to a dedicated custom database table for reading positions
- Added: Automatic migration from existing user_meta data to the new database structure (runs safely in the background)
- Added: Optimized database schema with unique keys (user_id, post_id, device) for efficient upsert operations
- Improved: Faster read/write performance and better scalability for large sites
- Improved: Reduced API request frequency by adding a throttle layer on top of existing debounce
- Improved: Device detection now uses normalized lowercase values (
pc,mobile,tablet) for full backend consistency - Improved: Added fail-safe handling for REST requests to prevent JavaScript errors on network issues
- Performance: Significantly reduced server load for logged-in users and improved overall responsiveness
- Backward-compatible: Existing user_meta data is migrated seamlessly, with fallback support during transition
- No breaking changes — REST API, localStorage keys, and frontend behavior remain fully compatible
- Added: Support for multiple CSS selectors separated by commas (e.g.
.entry-content, .post-content, #main) - Added: Option "Auto-clear saved position at content end" (enabled by default)
- Improved: Scroll tracking now activates if the reader is inside any of the configured selector areas
- Improved: Percent calculation prioritizes the selector in scope, falls back to whole page when outside all selectors
- Behavior: When auto-clear is enabled, progress is cleared at the end of the content area; when disabled, it falls back to clearing at page end
- Zero breaking changes — existing settings, localStorage keys, and user_meta structure remain compatible
- Added: CSS Selector option — plugin now only tracks progress inside the selected content area (e.g.
.entry-content) - Added: i18n ready strings for new settings field (English + Vietnamese translations included)
- Improved: Scroll position tracking logic — no longer saves progress when user scrolls outside the selected content area (e.g. comments section)
- Improved: Cleanup behavior — scroll progress is deleted only when reaching end of the page, never based on selector range
- No breaking changes — keeps old localStorage keys and user meta structure
- Updated: Admin settings page UI/UX (placeholder instead of default selector)
- Initial release
- Saves scroll position using localStorage (guests) and user meta (logged-in users)
- Auto-scrolls back to last position on load
- Per-device storage (PC, Mobile, Tablet)
- Settings page to choose post types
- Filter
init_plugin_suite_reading_position_delayto adjust debounce time