Visual feedback system for WordPress sites. Clients leave comments directly on pages with pin placement, screenshots, and annotations. Uses DOM serialization for pixel-perfect screenshot capture via a centralized screenshot service.
Same-day follow-up to 2.1.5. After shipping the \"blank screen\" fix, live QA surfaced a distinct visual regression: the kanban drawer screenshot region was rendering at 0px height on common laptop viewports. The <button class=\"r2fb-drawer__screenshot\"> existed in the DOM with a valid data-src, the <img> inside had currentHeight: 332px, but the button reported height: 0px with overflow: hidden, clipping the screenshot completely. Pure one-file CSS fix.
.r2fb-drawer__body is a flex column with overflow-y: auto, and .r2fb-drawer__screenshot has overflow: hidden (added 2.0.4 to tame user-agent button styling). Per CSS Flexbox, a flex item with non-visible overflow gets its implicit min-height: auto computed to 0 — so with default flex-shrink: 1, the flex algorithm is free to shrink the button below its content. On viewports where the sum of drawer panels exceeded the drawer height (every laptop under ~1080px), flex picked the screenshot button as shrinkable and collapsed it to 0, clipping the 332px image via the overflow: hidden. Invisible on tall external monitors (no overflow ⇒ no shrinking), which is why it survived 2.1.3 → 2.1.5 internal review. Fix: pin flex-shrink: 0 on the shared .r2fb-drawer__screenshot rule so the button always renders at intrinsic height; excess content continues to be handled by the drawer body's own overflow-y: auto. Covers both the real <button> and the --empty placeholder <div> state.All three were QA'd on a tall external display where scrollHeight ≤ clientHeight, so the flex algorithm had no reason to shrink anything. The bug only manifests when drawer content overflows the viewport — the default on every laptop. The user's 2.1.5 screenshot against a shorter viewport was the first repro.
Everything else. Zero JS, zero PHP (beyond the version string), zero option keys, zero REST surface, zero CPT / meta, zero notifications, zero rewrite rules, zero data model. Single CSS property addition. Forward + backward compatible with 2.1.5 data.
\nZIP-level: overwrite with any prior 2.x ZIP or the archives/r2-site-feedback-1.9.0.zip baseline. Behavioural caveat on rollback to ≤ 2.1.5: the drawer screenshot region collapses to 0px on laptop-height viewports; the screenshot data is still reachable via the full detail page.
Same-day follow-up to 2.1.4, isolating the true cause of the board-delete \"blank screen\" regression. 2.1.3 and 2.1.4 both targeted the detail-page delete flow (URL synthesis, then setTimeout-race), but live QA on projects.rise2.studio/parra surfaced that the bug was actually triggered by the drawer delete path — a different code path that never navigates. After REST 200 the drawer closes and the list re-renders in place; the screen went blank anyway. One-file CSS fix, no JS, no data-model, no REST.
R2FB_UI.modal / confirm() closes (admin only). The shared UI runtime mounts a persistent <div id=\"r2fb-modal-layer\" class=\"r2fb-v2 r2fb-modal-layer\"> on first use and keeps it in the DOM forever; only the child .r2fb-modal__backdrop is added / removed per modal. assets/css/r2fb-components.css correctly styles the layer as position: fixed; inset: 0; pointer-events: none; with no background — but admin/css/r2fb-admin.css (loaded after components.css) applies background: var(--r2fb-bg-page) to every .r2fb-v2 element. The cascade wins for admin, so the layer ends up with an opaque #FAF7F2 paint covering the whole viewport. pointer-events: none means it doesn't block clicks — but visually the admin UI vanishes the moment a confirm dialog has ever opened. The detail-page delete path hid this by navigating away (destroying the layer with the page); the drawer-delete path stays on the list view, so the orphaned layer stays visible and the user sees a \"blank cream screen.\" Added a targeted !important override in admin/css/r2fb-admin.css so .r2fb-v2.r2fb-modal-layer, .r2fb-modal-layer.r2fb-v2, .r2fb-v2.r2fb-toast-layer, .r2fb-toast-layer.r2fb-v2 resolve to background: transparent. The layer is now truly ambient: invisible when empty, paints via its backdrop / toast children only. Also fixes a latent cosmetic issue where the toast-layer fixed-corner container would have painted a small beige rectangle bottom-right.Why 2.1.3 + 2.1.4 didn't catch this. 2.1.3 targeted URL synthesis in the detail-page delete; 2.1.4 targeted the setTimeout-navigation race in the same path. Both verified the detail-page flow — neither touched the drawer-delete path because it never had a URL race to begin with (it stays on the list view). The modal layer's opaque background is created as a side effect of the shared .r2fb-v2 admin rule and only manifests after a confirm modal has closed. Both earlier fixes happened to end with a page navigation that destroyed the layer, so the bug was masked by the fix. The drawer's R2FB_UI.confirm(...) → delete → refresh-in-place path was the first to keep the page alive past the modal close and expose it.
Files modified: r2-site-feedback.php (version header & constant → 2.1.5); admin/css/r2fb-admin.css (single new rule forcing background: transparent !important on the modal-layer + toast-layer containers). No other files changed.
No changes to: JS, other PHP, option keys, REST API surface, CPT / meta, notifications, rewrite rules, access control, migrations. 2.1.4 data is transparently forward + backward compatible with 2.1.5.
Rollback: overwrite with archives/r2-site-feedback-1.9.0.zip (pre-v2 baseline) or any prior 2.x ZIP. Behavioural caveat on rollback to ≤ 2.1.4: confirming and closing any R2FB_UI modal / confirm dialog in the admin paints the whole admin UI beige until a hard reload.
PATCH follow-up to same-day 2.1.3. Three post-install issues on projects.rise2.studio: the board-view delete blank-screen returned, the kanban drawer silently omitted the screenshot region when no capture existed, and the drawer was too loose (oversized serif comment body, thick header padding, large gaps). Zero data-model / REST / option / migration changes.
ajaxUrl string-surgery to a localised CFG.listUrl, which was correct but not sufficient. The handler was still wrapping window.location.href = back in a setTimeout(…, 500) so the “Feedback deleted.” toast could be read before navigation; on tabs that lost focus, on throttled background tabs, under memory pressure, or when the modal’s 160ms close animation raced with the timer, the navigation never fired and the user landed on a half-torn-down detail view (blank cream page with the toast orphaned in the corner). Rewrote admin/js/r2fb-admin.js detail-page delete to: drop the setTimeout entirely — navigate immediately on REST 200; switch from location.href to location.replace() so the Back button skips the now-deleted detail URL; append r2fb_deleted=1 to the destination URL and drop the local toast; admin/views/page-feedback-list.php now reads $_GET['r2fb_deleted'] and emits a one-shot inline <script> that fires R2FB_UI.toast('Feedback deleted.', {type: 'success'}) via the already-enqueued shared runtime. Net: the deleted state is communicated on a guaranteed-rendered page, no race, no orphan.renderDrawer() was gated on if (data.screenshot_url) and rendered nothing otherwise — users saw the modal jump straight from the status / priority row to the comment block, with no indication whether the capture was pending, failed, or simply missing. Drawer now always renders a .r2fb-drawer__screenshot region: the real <button> variant when a URL exists (clicking it opens the fullscreen lightbox, unchanged from 2.1.3), otherwise a dashed-border <div class=\"r2fb-drawer__screenshot--empty\"> placeholder showing “Screenshot is being captured…” / “Screenshot capture failed.” / “No screenshot available.” based on data.screenshot_status. Matches the detail page’s pending/failed/empty handling..r2fb-comment-block__text was rendering user-generated text (often single-line pastes, URLs, test strings) in var(--r2fb-font-serif) (Lora variable) at var(--r2fb-fs-lg) (18px) — editorial treatment that looked wrong for short UGC and forced the drawer to scroll more than necessary. Changed the global comment-text rule to Inter at 14px with neutral letter-spacing. Scoped compactness on top of that, only inside .r2fb-drawer: header padding 16/20 → 12/16, title 18px → 16px, body padding 16/20/20 → 12/16/16 with inter-panel gap trimmed from 16px to 12px, and inner panels each get 12/16 padding instead of 16/20 when rendered inside the drawer. .r2fb-drawer .r2fb-replies capped at max-height: 360px.No changes to: CPT schema, meta keys, option keys, REST API surface, notifications, screenshot service protocol, rewrite rules, access control, or migrations. 2.1.3 ↔ 2.1.4 data is bidirectionally compatible.
Rollback: ZIP-level only — overwrite with any prior 2.x ZIP or archives/r2-site-feedback-1.9.0.zip. 2.1.3 is not promoted to archives/ (same-day predecessor).
Five-bug cleanup release after a live round of in-browser QA on projects.rise2.studio/parra. All five are surface / UX defects — no data-model, REST schema, option, or server-side behaviour changes beyond one permission_callback widening on GET /stats (previously admin-only, now public + scope-aware). Drop-in upgrade from 2.1.2 with zero migration.
/parra/ the CMS sidebar showed “19 opened, 2 in progress” while the widget badge above the FAB read “20”. Non-admin visitors saw the correct number. Root cause: updateBrowseBadge() in assets/js/r2fb-widget.js was computing the count from state.feedbackItems — the per-page list loaded via GET /feedback?page_url=… — but the CMS sidebar’s figures are site-wide. For a non-admin those two numbers happen to coincide because GET /feedback is always scoped to the caller’s own email + admin-excluded; for an admin viewing the widget they diverge whenever there’s even one extra non-resolved item on a different page (the /parra/za-racunovode/ row in this reproduction). Rewired in two places: (a) server-side, GET /stats in includes/class-r2fb-rest.php is now public via client_permission and its get_stats() implementation is scope-aware — admins get unscoped site-wide counts (so the badge matches the CMS), non-admins get email-scoped + admin-authored-excluded + r2fb_show_resolved — and (b) client-side, loadFeedback() fires a parallel GET /stats (no page_url), stores the result on state.stats, and updateBrowseBadge() prefers state.stats.counts.open + state.stats.counts.in_progress when available, falling back to the per-page state.feedbackItems filter when the stats call fails or hasn’t landed yet. Response shape unchanged: { total, counts: { open, in_progress, resolved } }.window.r2fbAdmin.ajaxUrl via string surgery (ajaxUrl.replace('admin-ajax.php', 'admin.php?page=r2-feedback')). If ajaxUrl was ever absent from the localisation payload the fallback was a bare relative ?page=r2-feedback that some host configurations (permalink rewrites, plugins that hook admin_url, sites behind a reverse proxy) resolved to an empty document. Explicitly localised listUrl => admin_url('admin.php?page=r2-feedback') in enqueue_admin_assets() in includes/class-r2fb-admin.php; both the detail-page delete handler and the drawer’s “Open” button in admin/js/r2fb-admin.js now consume CFG.listUrl with safe fallbacks. Also hardened the drawer-delete flow so it closes the drawer immediately, refreshes the affected column’s count inline, and only reloads the page if every card in the board has been deleted — no more blank screen even if a later failure occurs.<img> inherits the HTML5 native drag behaviour for images, which on Chromium / WebKit takes precedence over the draggable=\"true\" on the parent <article>. The browser was dragging the image’s data URL / blob, not the card payload the DnD handlers expected. Fix is two-pronged: draggable=\"false\" attribute on the card <img> in admin/views/page-feedback-list.php, plus a CSS belt-and-braces block in admin/css/r2fb-admin.css that sets -webkit-user-drag: none; user-select: none; pointer-events: none on .r2fb-feedback-card__screenshot img. The pointer-events: none also means the image can never receive a click — the parent card is now the only event target inside that region, so its drag + click handlers fire cleanly.renderDrawer() rendered the screenshot with cursor: zoom-in + a hidden data-r2fb-zoom attribute but no visible affordance. Users had no visual cue that clicking the image would open the lightbox. Added a floating zoom badge overlay: inline magnifying-glass SVG + “Click to zoom” label positioned over the top-right corner of the drawer screenshot, rendered with position: absolute inside a now-position: relative .r2fb-drawer__screenshot container. The existing openLightbox(src) call path is unchanged — only the visibility / discoverability is new. Same -webkit-user-drag: none; user-select: none treatment applied to the drawer <img> for visual consistency with the card./wp-content/plugins/r2-site-feedback/assets/fonts/Inter-variable.woff2 and Lora-variable.woff2. Root cause: templates/portal-standalone.php shipped two <link rel=\"preload\" as=\"font\"> tags referencing a planned assets/fonts/ directory that was never created — the v2 plan called for self-hosted Inter + Lora variable subsets, but the actual portal stylesheet never added matching @font-face rules and fell through to the system-font stack instead. The preload tags produced ERR_ABORTED 404 on every portal load and (for modern Chrome) an additional warning about an unused preload after 3s. Removed both preload declarations and the two $font_inter / $font_lora variable assignments that built them; left a two-line PHP comment explaining the 2.1.3 removal for the next maintainer. No CSS changes — the existing system-font fallback was already doing the rendering.GET /r2-feedback/v1/stats is now public (permission_callback = client_permission). Previously restricted to admin_permission. The endpoint is now scope-aware: authenticated WP admins (or any user with manage_options) receive unscoped site-wide counts so the widget badge matches the CMS sidebar; everyone else receives counts filtered by the same rules GET /feedback applies — _r2fb_client_email match (via current_client_identity()), _r2fb_author_is_admin != '1' (via hide_admin_authored_clause()), and respect for the r2fb_show_resolved option. Optional page_url query parameter adds per-page scoping on top of the identity rules. Response shape { total, counts: { open, in_progress, resolved } } is unchanged — any caller that worked against the admin-only endpoint keeps working against the public one.r2-site-feedback.php (version header + R2FB_VERSION constant → 2.1.3), includes/class-r2fb-rest.php (/stats route public + scope-aware get_stats()), includes/class-r2fb-admin.php (listUrl localisation), assets/js/r2fb-widget.js (state.stats + parallel GET /stats + updated updateBrowseBadge()), admin/views/page-feedback-list.php (card <img> draggable=\"false\"), admin/css/r2fb-admin.css (drag-suppression + drawer zoom-badge rules), admin/js/r2fb-admin.js (CFG.listUrl consumption + drawer delete hardening + zoom-badge markup), templates/portal-standalone.php (dropped font preload tags). No CPT / option / REST-schema / DB changes.r2-site-feedback-2.1.2.zip if preserved, or archives/r2-site-feedback-1.9.0.zip (pre-v2 baseline). Both are ABI-compatible with the 2.1.3 data on disk. The one behaviour rollback caveat is Bug 1’s badge: on 2.1.2 the admin will again see the per-page open count, not the site-wide count.Two-part fix for the “can’t reach the attachments zone in the comment editor on short viewports” bug originally reported on 2.1.0. 2.1.1 tried to solve it with a more visible scrollbar and never reached production because the site owner reported “still not good, i cant scroll inside of that area, and when i try to get to that area with pointer, it triggers the scrollbar of website.” Reproduced live on projects.rise2.studio/parra (Lenis + GSAP) at 1200×341: the sidebar body was logically scrollable (scrollHeight=925, clientHeight=251) but (a) the custom scrollbar never painted on Chromium and (b) the mouse wheel did not scroll it at all because Lenis hooked wheel at window with preventDefault, consuming every event before the modal’s native scroll could fire. Separately, macOS popped the document’s overlay scrollbar on the viewport right edge because the page behind the modal was still vertically scrollable. 2.1.2 ships both the CSS visibility fix and a JS-side body-scroll-lock + capture-phase wheel handler that together make the editor fully usable on any short viewport regardless of host-site scroll-jacker.
scrollbar-width: thin, scrollbar-color) with the legacy ::-webkit-scrollbar* pseudo-elements — but per the CSS Scrollbars Styling spec as implemented by Chromium/Blink, setting any of scrollbar-width or scrollbar-color to a non-initial value silently disables the pseudos on that scroller. With the pseudos disabled and the standards path active, Chrome on macOS falls back to the OS overlay-scrollbar mode (auto-hide, only painted during active scroll). Stripped both properties from the .r2fb-editor-sidebar-body base rule so the ::-webkit-scrollbar* pseudos can paint again; explicit width: 10px; -webkit-appearance: none on the pseudo forces an always-visible classic scrollbar on macOS Chrome / Safari regardless of the system “Show scroll bars” preference. Warm-stone palette retained (--r2fb-bg-muted track with --r2fb-border-soft left hairline, --r2fb-text-soft thumb with 6 px radius and 2 px track-coloured border).@supports isolation. Moved scrollbar-color: var(--r2fb-text-soft) var(--r2fb-bg-muted) into an @supports (-moz-appearance: none) block — a Firefox-only feature query that never matches on Chromium/WebKit/Blink, so the declaration is invisible to those engines and can’t disable the pseudos above. Firefox desktop renders always-visible scrollbars by default, so no visibility hack is required there — only the recolour.lockBodyScroll() / unlockBodyScroll() helpers in assets/js/r2fb-widget.js wired into openEditor() / closeEditor(). On open: save window.pageYOffset, apply overflow: hidden to <html>, compensate any removed scrollbar gutter with padding-right: Npx on <html> (no-op on macOS overlay scrollbars, preserves horizontal layout on Windows/Linux), then position: fixed; top: -scrollY; left: 0; right: 0; width: 100%; overflow: hidden on <body>. The page visually freezes at the exact position the user was looking at — macOS no longer pops its document-level overlay scrollbar on the right edge because the document isn’t scrollable anymore. On close: restore every touched inline style to its pre-lock value (empty string, not removeProperty — preserves any inline style the host theme had set before we came along), force scroll-behavior: auto temporarily so window.scrollTo(0, savedScrollY) is instant even on sites with scroll-behavior: smooth on <html>, restore the previous scroll-behavior. End result: close the editor and the page is exactly where it was when the editor opened — no visible jump at any scroll depth.handleEditorWheel() attached to the editor overlay with { passive: false, capture: true }. Walks up from the wheel target to find the first ancestor inside the overlay that has overflow-y/x: auto|scroll AND room to scroll in the event’s direction; replicates the scroll manually with node.scrollTop += deltaY / node.scrollLeft += deltaX (with deltaMode translation: LINE×16 px, PAGE×clientHeight), then preventDefault() + stopPropagation(). This is bulletproof against window-level preventDefault: even if a scroll-jacker already cancelled the native default upstream (Lenis does this on every wheel), the manual scroll still runs on the sidebar body because our scrollTop assignment doesn’t depend on the default action. Verified on parra: afterFirstWheel=100, afterSecondWheel=180 after dispatching 100 / 80 px wheel deltas, bodyTopUnchanged=true, lenisScrolled=false.initWidget(). If a prior session left the page frozen (tab closed mid-editor, bfcache restore with the old closure dead, uncaught JS error between lock and unlock), the next initWidget() run heuristically detects the lock (body.style.position === 'fixed' && top starts with '-' && width === '100%'), parses the scroll offset back out of top, clears every inline style we set, and restores scroll with window.scrollTo(0, recovered). Belt-and-braces — the normal close path already handles everything, this only catches pathological cases.scrollbar-gutter: stable on the sidebar body (prevents form-field shift when content transitions between fitting and overflowing), overscroll-behavior: contain (blocks trackpad rubber-band leakage even without the lock), scroll-padding-bottom (keyboard-focus scrollIntoView lands above the fixed footer shadow), and the @media (max-height: 760px) / @media (max-height: 520px) editor-height tuning blocks — unchanged.r2-site-feedback.php (version header + R2FB_VERSION constant → 2.1.2), assets/css/r2fb-widget.css (header comment, .r2fb-editor-sidebar-body rule + ::-webkit-scrollbar* pseudos + @supports Firefox block), assets/js/r2fb-widget.js (new lockBodyScroll() / unlockBodyScroll() / handleEditorWheel() helpers, wiring in openEditor() / closeEditor(), safety recovery in initWidget()). No PHP class / REST / CPT / option / DB-schema changes; drop-in upgrade from 2.1.1 with no migration. No r2fb_db_version bump (no data changes).archives/r2-site-feedback-1.9.4.zip (last 1.9.x) or archives/r2-site-feedback-1.9.0.zip (pre-v2 baseline). 2.1.1 is a same-day internal build and is not promoted to archives/; the CSS regression + wheel-event leak are the reasons 2.1.2 supersedes it.CSS-only patch. Reported by the site owner: on laptops / tablets with shorter viewports, opening the comment editor clipped the Attachments upload zone below the fold and the scrollbar was too subtle to find, so users couldn't attach files. No data-model, REST, option or JS behaviour changes.
auto 1fr auto sidebar layout from 2.0.0 was already producing a scrollable body when content exceeded the viewport, but the custom scrollbar thumb was tinted with --r2fb-border (a warm off-white that disappeared against the card background) and the gutter was transparent — so on touch devices and on Chromium/Firefox overlay-scrollbar default builds the user had no visual cue that the body was scrollable. The attachments zone was therefore unreachable on viewports under ~760px tall. Changed the thumb colour to --r2fb-text-soft (muted ink, still quiet but clearly present), gave the track a subtle --r2fb-bg-muted lane with a hairline border so the scroll corridor is visible even when empty, bumped the thumb from 8px to 10px, added scrollbar-gutter: stable so the gutter is always reserved (no layout shift when content transitions from fitting to overflowing), added overscroll-behavior: contain (Chromium trackpad rubber-band can't leak to the document behind), and added scroll-padding-bottom so programmatic scrollIntoView() (focus-jumps on keyboard nav) lands fields comfortably above the fixed footer.@media (max-height: 760px) block that trims the WYSIWYG editor from min-height: 140px / max-height: 260px to 110px / 180px, tightens the sidebar title / body / footer padding from --r2fb-s-6 to --r2fb-s-5, and shrinks the body gap from --r2fb-s-4 to --r2fb-s-3. Net effect on a 1366×768 laptop or a landscape tablet: the full form (name + comment + attachments + upload drop-zone) fits without any scroll in the common case; when it does scroll, the beefed-up scrollbar makes it obvious. A secondary @media (max-height: 520px) block further shrinks the WYSIWYG to 80px / 140px and drops the sidebar title font down one step, for landscape-phone cases.assets/css/r2fb-widget.css only. PHP, JS, REST, and data schema are untouched. Existing open editor sessions pick up the new styles on the next reload.archives/r2-site-feedback-1.9.4.zip or archives/r2-site-feedback-1.9.0.zip. No partial rollback to 2.1.0 (same-day internal build, not promoted to archives/).Minor version bump combining three tightly-coupled changes: closing the final non-admin-sees-admin-ticket leak, retiring the legacy v1 UI bundle, and styling the previously-unstyled WP dashboard widget in v2. Rollback surface simplifies — the in-plugin Settings → Advanced → Interface Version kill-switch and the assets/{css,js}/legacy/ + admin/{css,js}/legacy/ frozen bundles are gone; ZIP-level rollback to archives/r2-site-feedback-1.9.4.zip or archives/r2-site-feedback-1.9.0.zip remains the single escape hatch. No REST / option / CPT / data-model changes; existing feedback, screenshots, replies, notes, and API keys are preserved across upgrade and downgrade.
_r2fb_author_is_admin meta flag. 2.0.4 / 2.0.6 hardened non-admin scoping to email-only across R2FB_REST::get_feedback_list(), current_client_owns_post(), and the [r2fb_portal] shortcode — but email-only cannot distinguish “a ticket I submitted” from “an admin submitted a ticket with an email value that happens to match my cookie” (shared test inboxes, admin's WP-profile email overlap, stale cookies set while browsing as admin, etc.). Reported by the site owner as “as regular user, i still see the comment admin left.” Fixed by: (a) registering a new CPT meta key _r2fb_author_is_admin ('0' or '1'); (b) stamping the flag at ticket-create time in R2FB_REST::create_feedback() via current_user_can('manage_options'); (c) short-circuiting current_client_owns_post() to return false for any post whose flag is '1', regardless of email match; (d) inserting a new hide_admin_authored_clause() helper into the non-admin branch of get_feedback_list() so the meta_query now requires _r2fb_client_email exact match AND _r2fb_author_is_admin = '0'; (e) mirroring the same AND-clause in class-r2fb-portal.php::render_portal(). Because pre-2.1.0 rows have no meta at all, a synchronous r2fb_backfill_author_is_admin() migration walks every r2_feedback post on activation and on plugins_loaded priority 5 (before REST init at priority 10) and stamps the flag based on the stored author's current capabilities — post_author = 0 (anonymous) → '0'; author has manage_options → '1'; otherwise '0'. Idempotent: skips any row already carrying '0' or '1'. Migration is gated by R2FB_VERSION vs the new r2fb_db_version option, so it runs once per upgrade and is a no-op on steady-state.r2fb_ui_version kill-switch. Per user request to simplify the codebase and focus privacy work on a single surface. Deleted: assets/css/legacy/ (1.9.4 r2fb-widget.css, r2fb-portal-standalone.css), assets/js/legacy/ (1.9.4 r2fb-widget.js, r2fb-portal-app.js), admin/css/legacy/ (1.9.4 r2fb-admin.css), admin/js/legacy/ (1.9.4 r2fb-admin.js). class-r2fb-widget-loader.php and class-r2fb-admin.php collapse their per-request “v1 or v2?” branches — the v2 token→base→components→widget/admin cascade is now unconditionally enqueued. R2FB_Admin::get_ui_version() and resolve_admin_assets() methods are gone; wp_localize_script no longer ships the uiVersion key. admin/views/page-settings.php drops the entire Advanced → Interface Version dropdown; save_settings() drops the matching option-save handler. On upgrade from any <2.1.0 install, r2fb_maybe_upgrade() deletes the orphan r2fb_ui_version option from wp_options. ZIP-level rollback remains supported via the preserved archives/r2-site-feedback-1.9.4.zip / archives/r2-site-feedback-1.9.0.zip.wp_add_dashboard_widget() renders into WP core's #dashboard-widgets which sits outside any .wrap.r2fb-v2 ancestor, so every .r2fb-v2 .r2fb-dash-* rule silently fell through to bare wp-admin defaults. Fixed by wrapping the render output in a <div class="r2fb-v2 r2fb-dashboard-widget"> root and rewriting the admin CSS to scope under a compound .r2fb-v2.r2fb-dashboard-widget selector. Rewrote the markup so the three status counts (Open / In progress / Resolved) are individual clickable anchor cards that deep-link into pre-filtered list views (admin.php?page=r2-feedback&status=open, etc.), each with a hover-lift translateY(-1px) + tinted focus ring driven by existing tokens (--r2fb-warning-soft / --r2fb-info-soft / --r2fb-success-soft / --r2fb-shadow-2 / --r2fb-shadow-focus). Added a summary line (“N unresolved out of N total feedback items.”) and a friendlier empty state for fresh installs.r2-site-feedback.php (version header + constant + activation defaults cleanup + new r2fb_maybe_upgrade() + r2fb_backfill_author_is_admin()), includes/class-r2fb-cpt.php (register new meta), includes/class-r2fb-rest.php (stamp flag at create-time, hide-admin clause helper, current_client_owns_post() short-circuit, list-query AND-filter), includes/class-r2fb-portal.php (list-query AND-filter), includes/class-r2fb-widget-loader.php (drop legacy branch), includes/class-r2fb-admin.php (drop legacy branch + rewrite render_dashboard_widget()), admin/views/page-settings.php (drop Advanced section), admin/css/r2fb-admin.css (dashboard widget scoping + styles).assets/css/legacy/r2fb-widget.css, assets/css/legacy/r2fb-portal-standalone.css, assets/js/legacy/r2fb-widget.js, assets/js/legacy/r2fb-portal-app.js, admin/css/legacy/r2fb-admin.css, admin/js/legacy/r2fb-admin.js.archives/r2-site-feedback-1.9.4.zip (last 1.9.x) or archives/r2-site-feedback-1.9.0.zip (pre-v2 baseline) and WP will accept the downgrade. All 2.1.0 privacy meta is ignored by pre-2.1.0 code; feedback rows stay intact and the email-OR-name matching leak returns (this is the expected pre-2.0.4 behaviour).Follow-up privacy hardening to 2.0.4. 2.0.4 closed the name-OR-email leak in current_client_owns_post() and the own_feedback_only = ON branch of get_feedback_list(), but field-testing surfaced three remaining paths where a regular visitor with an email cookie could still see admin-created tickets. Reported by the site owner as “Privacy is still not good, when on feedback page, i can still see new tickets from admin as regular user who used email.” No data-model or API-surface changes.
[r2fb_portal] shortcode now email-only for non-admins. includes/class-r2fb-portal.php::render_portal() was still running the pre-2.0.4 OR-based meta_query (_r2fb_client_email OR _r2fb_client_name), had no admin bypass, and gated the query only on “email or name present”. A non-admin whose cookie name matched an admin's stored _r2fb_client_name — or the widget default that every anonymous visitor shares — could see admin-filed tickets. The shortcode now (a) resolves is_admin = current_user_can('manage_options') and returns the unscoped list for admins, (b) requires a verifiable client_email for non-admins — empty returns an empty view with a friendly prompt, (c) hard-scopes the meta_query to _r2fb_client_email exact match (case-insensitive via MySQL's default utf8mb4_*_ci collation), and (d) keeps client_name only for the header greeting, never in the query. Matches the R2FB_REST::get_feedback_list() contract from 2.0.4.R2FB_REST::get_feedback_list() else branch dropped the client_name OR fallback. The own_feedback_only = ON path was already email-only in 2.0.4, but the own_feedback_only = OFF branch still accepted client_email || client_name from the request and ran an OR meta_query — the same leak pattern, just gated by a different option. Non-admins in this branch now always resolve their identity server-side via current_client_identity(), drop any client-sent name param, and get an empty list when no email is resolvable. Admins remain unscoped.R2FB_REST::get_feedback(), add_reply(), and upload_attachments() ownership checks are now unconditional. Pre-2.0.6 the current_client_owns_post() check was gated with '1' === get_option( 'r2fb_own_feedback_only', '1' ) — meaning a non-admin with an email cookie could fetch, reply to, or upload to any feedback post by ID whenever that option was off. That option governs list-view presentation (breadth), not per-ID access control (the 2.0.2 help-text rewrite spells out the distinction). Ownership now applies to every non-admin request regardless of option state. 404 (not 403) is returned on failure so ID enumeration cannot probe for other users' records.client_name query param. assets/js/r2fb-portal-app.js::loadFeedback() previously pushed both client_email and client_name into the REST query string. The server now ignores client_name entirely, but shipping dead data was a vector risk — a future dev could accidentally re-introduce the name-based match on the server side. Only client_email is forwarded, as a hint; authoritative identity resolution stays server-side.render_portal(), get_feedback(), add_reply(), and upload_attachments() carry a 2.0.6 note documenting the “email-only is strictly stronger than name-OR-email” argument so future edits don't re-add the name fallback.includes/class-r2fb-portal.php, includes/class-r2fb-rest.php, assets/js/r2fb-portal-app.js.archives/r2-site-feedback-1.9.0.zip — last build that accepted name || email matching (leak returns). Partial rollback to 2.0.5 re-introduces the legacy-shortcode and own_feedback_only = OFF branch leaks.UX follow-up to 2.0.4. The required-email validation added in 2.0.4 surfaced its error via R2FB_UI.toast(), which flashed in the bottom-right toast layer (visually disconnected from the email field) and auto-dismissed after ~4 seconds — user report: “jumping all around and hiding quickly”. No data-model, API, or option changes.
<small class=\"r2fb-field-error\" role=\"alert\" aria-live=\"polite\"> anchored directly under the email input inside its .r2fb-editor-form-group. The message stays put until the user edits the field — an input listener on the email field clears the error text, resets the red border, and removes aria-invalid. No auto-hide timer..r2fb-editor-input.r2fb-has-error and .r2fb-has-error:focus rules use --r2fb-danger + --r2fb-danger-soft, matching the rest of the v2 palette instead of the raw #dc3232 fallback.prefers-reduced-motion override. Focus moves to the email input so keyboard users land on the field they need to correct and screen readers re-announce the aria-describedby-linked error.assets/js/r2fb-widget.js, assets/css/r2fb-widget.css.archives/r2-site-feedback-1.9.4.zip or archives/r2-site-feedback-1.9.0.zip. 2.0.4 was a same-day internal build and was not promoted to archives.Bundled patch covering five live-site defects reported on projects.rise2.studio/parra after 2.0.3 was deployed. No data-model or API-surface changes; existing feedback, options and screenshots are preserved.
requestScreenshot directly on every click, and the REST screenshot proxy is capped at 10 requests per IP per 5 minutes (plus host WAFs often cap lower). Rapid or impatient double-clicks — which happened routinely because the loading overlay takes ~300ms to appear — multiplied the request count and tripped the rate limit, surfacing as a silent \"server keeps blocking me\" with no captured screenshot. assets/js/r2fb-widget.js now guards requestScreenshot with a screenshotInFlight boolean plus state.mode === 'loading' || 'editor' early-return; the guard is released in the success, error, and \"screenshot service not configured\" branches. Net effect: a user clicking the FAB ten times in a row now fires exactly one capture..r2fb-table thead in admin/views/page-feedback-list.php is a custom table (not WP_List_Table) so it never picked up WordPress's native #cb-select-all-1 jQuery wiring. Clicking the select-all box left every row unchecked. Fixed by giving the master checkbox id=\"r2fb-cb-all\" and wiring a new bindBulkSelect() block in admin/js/r2fb-admin.js that (a) ticks/unticks every input[name=\"r2fb_selected[]\"] within the enclosing form when the master toggles, and (b) recomputes the master state (checked / unchecked / indeterminate) on every per-row change — matching the native WP list-table behaviour users already expect.<button> (so Enter / Space open the lightbox), and the .r2fb-drawer__screenshot CSS rule set only border-radius / overflow: hidden / background / cursor: zoom-in. UA defaults on <button> (inline-block, buttonface background, 1px 6px padding, 2px outset border, middle baseline) were collapsing the inner <img> to zero visible height. admin/css/r2fb-admin.css now resets the button — display: block; width: 100%; padding: 0; margin: 0; border: 0; font: inherit; color: inherit; text-align: left — and enforces max-width: 100%; height: auto on the child <img>. Keyboard/lightbox semantics unchanged.$post->post_date equals $post->post_date_gmt, but the REST layer was returning that UTC value on the date field. The shared R2FB_UI.time() helper fed it into new Date(\"YYYY-MM-DD HH:MM:SS\") which modern Chromium parses as local time — so a UTC value got re-interpreted as browser-local, adding a CEST two-hour offset to every relative timestamp. Two-part fix: (1) class-r2fb-rest.php format_feedback(), get_replies() and get_notes() now return $post->post_date_gmt / $comment->comment_date_gmt on the canonical date field (with date_gmt preserved for any consumer that was relying on the explicit field). (2) assets/js/r2fb-ui.js::time() also defensively normalises any MySQL-format datetime string (YYYY-MM-DD[ T]HH:MM:SS) to a fully-qualified ISO UTC (…THH:MM:SSZ) before handing off to new Date().r2fb_default_client_name that every anonymous visitor shares, and the name field is freely editable in the submit form. Two different anonymous visitors on the same site therefore saw each other's tickets in the browse panel and the portal, and could reply on each other's threads. R2FB_REST::current_client_owns_post() and R2FB_REST::get_feedback_list() now scope email-only. To make this workable for anonymous flows, assets/js/r2fb-widget.js promotes the email field from optional to required whenever ownFeedbackOnly is on and the visitor is not logged in — placeholder becomes Email *, aria-required=\"true\", and submitFromEditor() validates a basic x@y.z pattern before enabling submission. A new ownFeedbackOnly flag is localised to r2fbConfig by class-r2fb-widget-loader.php. The settings-page help text under Client Privacy → Scope to Client carries a 2.0.4 note explaining that scoping is now email-only and recommending Access mode = Logged-in users only for the strongest guarantee.archives/r2-site-feedback-1.9.0.zip (pre-v2 baseline) and set version=1.9.0 in info.json; all 2.0.x data — feedback, meta, screenshots, API keys, options, replies, notes — re-renders correctly under 1.9.0. Or flip Settings → Advanced → Interface Version to v1 for a style-only fallback while keeping 2.0.4's PHP fixes.dev.vrep.de). After 2.0.2's scoping fix every widget rule correctly matched body-appended roots, but live inspection on one site still showed the \"Leave Feedback\" button as a full-width red banner. The v2 stylesheets were applying (position, height, padding, border-radius, z-index, design tokens all correct on the FAB) but the computed font-size came out as 82.3168px and the background as an inline rgb(234, 11, 11). Two distinct root causes: (1) The VREP theme sets html { font-size: 101.313px } (fluid vw-based root font-size, common for theme-wide fluid typography). All --r2fb-fs-* tokens were authored in rem, so .8125rem × 101.313 ≈ 82.32px — exactly the observed value. Fixed by authoring font-size tokens in px (--r2fb-fs-sm: 13px, etc.) in assets/css/r2fb-tokens.css; px still scales with browser zoom (browsers multiply) so accessibility is unchanged, and it's immune to fluid-root hosts. A contract comment was added to r2fb-widget.css so edits don't switch back to rem without first anchoring a font-size on every body-appended root. (2) The widget JS (assets/js/r2fb-widget.js) was hard-coding the admin-configured primary color as an inline style.background on the FAB, password gate submit, annotation-editor submit and ticket-reply buttons. Inline styles beat every :hover, focus-ring and var(--r2fb-accent) rule, so a configured red drowned out v2's coral hover. Fixed: the widget now forwards the admin color via --r2fb-accent CSS custom property (plus a JS-derived 12% darker --r2fb-accent-hover) on each root. The CSS owns background: var(--r2fb-accent) and :hover { background: var(--r2fb-accent-hover) }, so hover / focus / chip tints cascade from one source. New accentStyle(extra) helper built the style object at four call sites; the el() helper routes --* keys through setProperty() (since Object.assign is a no-op for custom properties). New darkenHex(hex, amount) utility parses #rgb / #rrggbb and returns a darker hex; safe to reuse.r2-site-feedback-2.0.2.zip, by restoring archives/r2-site-feedback-1.9.0.zip (pre-v2 baseline), or by flipping Settings → Advanced → Interface Version to v1 to fall back to the frozen 1.9.4 bundle.dev.vrep.de — with v2 enabled the \"Leave Feedback\" button appeared as a giant red unstyled block instead of the coral pill FAB. Same class of bug that 2.0.1 fixed for the admin kanban drawer, replayed across the whole widget surface. Seven root-level widget elements (FAB, browse badge, password gate, loading overlay, editor overlay, list panel, legacy toast) are appended directly to document.body and carry .r2fb-v2 on themselves — but r2fb-widget.css was targeting them exclusively with descendant selectors (.r2fb-v2 .r2fb-fab), which require .r2fb-v2 to be an ancestor. Since <body> isn't .r2fb-v2, zero rules matched and each element fell back to the host theme's bare styling. Fixed by pairing every root-level rule with a compound form (.r2fb-v2 .r2fb-fab, .r2fb-v2.r2fb-fab { … }) across FAB, browse badge, menu, password gate, loading / editor overlays, list panel, legacy toast, and all their :hover / :active / positional / media-query / reduced-motion variants. Children of these roots keep working via descendant selectors because the root itself is their .r2fb-v2 ancestor. Added a scoping-contract docblock at the top of the file so future edits don't regress..r2fb-form-sublabel — small italic muted line stacked under a form label, available for any settings row where the label alone is ambiguous.archives/r2-site-feedback-1.9.0.zip (pre-v2.0.0 baseline) or flip Settings → Advanced → Interface Version to v1 to fall back to the frozen 1.9.4 bundle.document.body (so they escape the .wrap.r2fb-v2 stacking context) and carry .r2fb-v2 on themselves, but the admin stylesheet targeted them with descendant selectors like .r2fb-v2 .r2fb-drawer, which require .r2fb-v2 to be an ancestor, not the same element. The drawer was created correctly, it just received zero positioning / z-index / background / transform, so it lived invisibly off-screen. Added compound selectors (.r2fb-v2.r2fb-drawer, .r2fb-drawer.r2fb-v2, same for .r2fb-drawer-overlay, .r2fb-drawer.is-open, .r2fb-lightbox) in admin/css/r2fb-admin.css..r2fb-switch component expected a class-prefixed <input class=\"r2fb-switch__input\"> and drove the thumb via .r2fb-switch__track::before, but every settings-page switch ships the native <input type=\"checkbox\"> (no class) with a real <span class=\"r2fb-switch__thumb\"> child. Result: the input wasn't hidden (visible native checkbox next to every switch), and the checked-state / thumb-slide rules never matched. Rewrote the switch CSS in assets/css/r2fb-components.css to target input[type=\"checkbox\"] directly and drive the real .r2fb-switch__thumb span; kept old .r2fb-switch__input selectors as aliases; added disabled + focus-visible styles.#E8624A on #FAF7F2), Inter sans + Lora display serif, and a shared design-token system across all three surfaces: the frontend widget (FAB, browse badge, annotation editor, sidebar form, list panel), the standalone portal at /rise2-feedback (sticky header with search + filter tabs, two-pane list/detail on ≥960px, mobile push-over detail, skeleton loaders, empty states), and the WordPress admin (kanban board + list toggle, detail drawer with screenshot lightbox, settings page grouped by concern).R2FB_UI (assets/js/r2fb-ui.js) — modal(), confirm(), toast(), trapFocus(), time(). Every native alert() / confirm() replaced across widget, portal, and admin.r2fb-tokens.css → r2fb-base.css → r2fb-components.css → surface stylesheets. All v2 styles scoped to .r2fb-v2 so host themes and wp-admin remain untouched.r2fb_ui_version option (default 'v2'; flip to 'v1' to restore the frozen 1.9.4 bundle from assets/{css,js}/legacy/ and admin/{css,js}/legacy/). Configurable in Settings → Appearance. Applies to the widget + admin; the standalone portal is v2-only.#/item/{id} with hashchange + popstate wiring, debounced (150 ms) client-side search across comment_text + page_path + client_name, skeleton cards during initial fetch, optimistic reply submission with revert on failure, priority-dot indicator per card.<select> on every card as the a11y fallback, Esc closes the detail drawer, / focuses search.role=\"dialog\" + aria-modal + aria-labelledby; every icon-only button has aria-label; focus traps on open + focus restore on close; portal tab bar follows the WAI-ARIA tab pattern with Arrow/Home/End keys; live regions for toasts and async list updates.#r2fb-main.@media (prefers-reduced-motion: no-preference).grid-template-rows: auto 1fr auto) + min-height: 0 on the body. The 1fr track is always computed as the exact remaining space after the auto tracks — no content-size fallback loop. Attachments are reachable at any viewport size / zoom level.r2-commenter/archives/r2-site-feedback-1.9.4.zip. To revert, restore that archive and set version=1.9.4 in info.json; or, for a style-only rollback, flip the in-plugin r2fb_ui_version option to 'v1'.reply_count — so a client saw 💬 2 on their own card and could infer that someone had replied even though the thread was sealed. R2FB_REST::format_feedback() now zeros the count for non-admin viewers whenever r2fb_hide_client_conversation is on (default). The legacy [r2fb_portal] shortcode got the same guard. Admins still see the true count everywhere.flex: 1 1 auto on the scrollable body, which on some browser-zoom / short-viewport combinations never triggered overflow. Switched to flex: 1 1 0 + explicit height: 100% on the sidebar root so the body always sizes from available space and its custom scrollbar triggers every time.r2fb_own_feedback_only option (default ON). The widget browse panel and the standalone portal used to return all feedback submitted on the same page; now every client-facing REST path enforces ownership server-side (list / single-get / reply / attachments). Non-owners get a 404, not 403, so the existence of other clients' records isn't leaked. Identity comes from the logged-in WP user or the r2fb_client_* cookies. Admins are exempt.POST …/reply now returns 403 for non-admins when the new option is on. The client sees a short \"your feedback was received\" confirmation panel instead of the full conversation, so they can still verify the submission.r2fb_hide_client_conversation option; added to activation defaults so fresh installs start in the safer hidden-by-default posture..r2fb-editor-sidebar-body / .r2fb-editor-sidebar-footer structural classes — applied to both the current stylesheet and the dormant v2 bundle.position: sticky), so it stays reachable on any desktop viewport or zoom level. Previously it could fall below the visible area, forcing users to tab to it.r2fb_notify_client_enabled gates both on_admin_reply() and on_status_resolved() in the notifications class.r2fb_ui_version) — no visual change ships in 1.9.1./rise2-feedback endpoint to any custom path without editing code