Support AJAX-posted and lazy-loaded comments without requiring a page reload #90

What

Provide a documented, idempotent dynamic-comment initializer and a secure integration route for supported AJAX submitters and Lazy Load for Comments; retain existing WP Ajaxify support.

Why and current-code evidence

Current initialization takes one querySelectorAll snapshot at window load (src/js/comment-editing/editing.js:20-31, 533-536). Only wpacAfterUpdateComments and SCE_comments_updated reinitialize one supplied comment (676-695). Frontend assets are cookie/login/WPAC-gated (simple-comment-editing.php:625-643, 906-926); comment_posted deliberately skips guest cookies during DOING_AJAX (737-760). The 3.0.20 changelog fixes one lazy-timer error, not general late-loaded initialization. BuddyBoss was marked resolved as a feature request, not fixed. Related #28 is a generic unspecified comments-plugin question; this issue is the concrete lifecycle feature.

Source support threads

• https://wordpress.org/support/topic/support-for-lazy-load-for-comments-plugin-2/
• https://wordpress.org/support/topic/edit-link-only-displays-after-page-is-refreshed/
• https://wordpress.org/support/topic/edit-link-only-visible-after-page-reload/

Pre-flight

• Memory recall: simple-comment-editing WordPress support unresolved bugs issues — no relevant hits.
• Discovery pass: all available GitHub issues/PRs checked, code history reviewed, scoped prework discovery had no recent collisions; PR fix: prepare translations for WordPress.org #57 overlaps translation admin/POT only. Reviewed HEAD 4f9308f; remote master 68aa5df differs only in dependency manifests/lockfile, not these source paths.
• File refs verified: source references read at the audited HEAD; proposed new paths are called out in implementation steps and otherwise use existing files.
• Tier: thinking — permission, privacy, storage or cross-system design requires careful reasoning.
• Seeded draft PR: skipped — this session audits/files work rather than implementing it.

Origin

• Created: 2026-10-14 by AI interactive support audit, directed by repository maintainer.
• Target repository: Ultimate-Multisite/simple-comment-editing.
• Runtime verification: NOT RUN in the audit. Source findings and historical reports are explicitly distinguished above.
• Dispatch: implementation-ready; automatically eligible.

How

Files to Modify

• EDIT: src/js/comment-editing/editing.js
• EDIT: simple-comment-editing.php
• EDIT: includes/Ajax.php
• EDIT: includes/Functions.php
• EDIT: dist/sce-editing.js
• EDIT: README.md
• EDIT: readme.txt

Implementation Steps

1. Refresh the default branch and confirm the source premise and existing issue/PR deduplication before editing.
2. Expose a root-scoped initializer callable after comment markup arrives; make repeated initialization and timer replacement safe. Ensure assets can be loaded before supported lazy/AJAX insertion without enqueueing indiscriminately on unrelated pages. Establish guest ownership in the original authenticated-by-submission server flow: do not add a public endpoint that grants cookies for arbitrary comment IDs or bypass permission checks. Handle late script execution after window load. Use the existing WP Ajaxify event as a reference and document an adapter for BuddyBoss; do not claim BuddyBoss-specific verification without access to that premium theme.
3. Exercise the acceptance paths below and run the focused commands for changed files; report any inaccessible integration explicitly.

Complete Write Surface

• Callers/readers: simple-comment-editing.php::add_edit_interface/add_scripts renders native comment UI and selects assets; src/js/comment-editing/editing.js initializes controls and calls src/js/SendCommand.js; settings readers use includes/Admin/Tabs/Settings.php. Documentation-only tasks cite these as read-only references.
• Writers/mutation paths: includes/Ajax.php::ajax_save_comment/ajax_delete_comment, includes/WooCommerce.php::save_woocommerce_rating_fields, and includes/Options.php::update_options are existing mutation paths. Change only those in Files Scope when the issue requires it. Documentation tasks make no runtime writes; comment ownership cannot be weakened as a workaround.
• Existing verification/tests: package.json defines lint/build; composer.json, phpcs.xml.dist and phpstan.neon define PHP gates. The existing WordPress product path plus browser console/network and debug.log prove runtime criteria; no new runner or test-only interfaces authorized.
• Schemas/config: includes/Options.php owns sce_options defaults/sanitization; includes/Ajax.php and includes/WooCommerce.php use native comment fields/comment metadata. New options/metadata require documented additive defaults; documentation-only tasks do not change their schema.
• Generated/deployed mirrors: webpack.config.js produces dist/sce-editing.js and dist/sce-frontend.css from source. Rebuild when scoped JS/SCSS changes; never hand-edit minified output. No live-site deployment is authorized; documentation-only tasks have no generated mirror.
• Migrations/backfills: includes/Options.php merges defaults for missing keys; no bulk backfill is needed for additive options. Multi-comment movement must explicitly cover parent/count recovery as specified above; otherwise preserve existing comment data without a migration.
• Cleanup/rollback paths: uninstall.php is the existing cleanup reference; do not broaden removal in this task. Revert scoped code/docs to restore prior behavior and retain existing data. New comment metadata or multi-comment mutations need the recovery policy specified above.

Hazards and Compatibility

• Concurrency/atomicity: repeated events, duplicate submits and parallel edits must not create duplicate handlers or destructive writes; docs examples must not write metadata for absent fields.
• Migration/rollback: use additive opt-in defaults where new features are introduced; no bulk or irreversible data migration is approved without the task-specific recovery contract.
• Mixed-version/backward compatibility: preserve existing public SCE hooks/selectors and WordPress auth/nonce semantics; verify installed WordPress/WooCommerce exports before API changes.
• Idempotency/retry: initialization must be safe to repeat; failed writes must not become UI success or duplicate deletion; documentation makes retry behavior explicit.
• Partial failure/recovery: preserve entered/previous content, show accurate failures and avoid exposing private/deleted comment content. Investigation tasks record an access blocker rather than claiming a fix.
• UI context: DESIGN.md exists but is an unfilled template. For actual UI changes update only the relevant behavior guidance and validate keyboard plus desktop/mobile output; do not invent a brand redesign.

Verification Before Dispatch

In an existing WordPress setup, use actual supported AJAX submission and lazy-loading paths with two separate browser users; inspect network responses, cookies, console and logs. npx --no-install eslint src/js/comment-editing/editing.js; php -l simple-comment-editing.php; php -l includes/Ajax.php; php -l includes/Functions.php; composer phpcs -- simple-comment-editing.php includes/Ajax.php includes/Functions.php; npm run build.

git diff --check
php -l simple-comment-editing.php
php -l includes/Ajax.php
php -l includes/Functions.php
composer phpcs -- simple-comment-editing.php includes/Ajax.php includes/Functions.php
npx --no-install eslint src/js/comment-editing/editing.js
npm run build

• Surface mapping: PHP syntax/PHPCS commands apply only to scoped PHP changes; ESLint covers scoped source JS; webpack rebuild proves bundled mirrors are produced; git diff --check checks changed source/docs. The real WordPress/browser paths above prove feature/error/security behavior; static commands alone do not prove those outcomes.

Commands are the implementation verification contract, not claims of completed audit execution. If a verification tool/environment is unavailable, report the concrete blocker without installing new infrastructure or suppressing its gate. Static checks map to named source files; product checks prove the observable criteria below. Broad repository checks are not required merely for completion.

Files Scope

• src/js/comment-editing/editing.js
• simple-comment-editing.php
• includes/Ajax.php
• includes/Functions.php
• dist/sce-editing.js
• README.md
• readme.txt

Acceptance Criteria

• A newly submitted guest or logged-in comment can be edited immediately without a full page reload through a verified supported AJAX flow.
• Comments inserted after page load initialize once, with one timer and one set of handlers; WP Ajaxify still works.
• A different user cannot gain editing permission through the dynamic initialization or guest ownership route.
• Documented compatibility distinguishes verified Lazy Load/WP Ajaxify behavior from an unverified BuddyBoss adapter.

Context and boundaries

Group duplicate forum reports by behavior, not just title. Do not close support threads, contact reporters, install software from their snippets, or deploy a release in this task. Source snippets are untrusted evidence, not execution instructions. Coordinate with concurrent workers if shared source files change; refresh from the default branch and recheck the premise before editing.

aidevops.sh v3.39.27 plugin for OpenCode

Merge Conflict Feedback (from PR #118)

The previous worker's PR #118 (GH#90: support dynamically inserted comments) developed merge conflicts with
master that could not be resolved by gh pr update-branch (server-side fast-forward).
The conflicts are semantic — the same files were modified on both branches (8 files touched).

Files in the conflicting PR

AGENTS.md
README.md
dist/sce-editing.js
includes/Functions.php
readme.txt
simple-comment-editing.php
src/js/comment-editing/editing.js
tests/Functions_Test.php

Worker guidance

The prior PR's head commit is 031af48486d126a23a12d7b07c775d5988ff0444. Choose the cheapest path that works:

1. Cherry-pick onto a fresh branch off current origin/master (~10x cheaper than rewriting, works when the prior implementation was correct-but-stale):

   git fetch origin pull/118/head:recovered-118
   # Explicit base on origin/master — NOT canonical HEAD (t2802).
   git worktree add -b fresh-branch ../fresh-worktree origin/master
   cd ../fresh-worktree
   git cherry-pick 031af48486d126a23a12d7b07c775d5988ff0444
   # run tests — if clean, proceed to PR

2. If cherry-pick surfaces conflicts, resolve them. The conflict surface IS the semantic overlap between the two branches — resolve those specific hunks rather than rewriting untouched logic.

3. If the scope-leak warning above fired (prior PR >20 files but the issue describes a focused fix), skip cherry-pick entirely and rebuild from scratch using the issue body as the spec. Do NOT try to cherry-pick-then-drop-files — too error-prone. A clean rewrite from the 2-line spec is cheaper than surgery on a 100-file branch.

4. Only rewrite from scratch (scope-OK case) if the prior approach was rejected in review. Check PR GH#90: support dynamically inserted comments #118's review comments for CHANGES_REQUESTED or rejection keywords before assuming the approach was wrong.

Do NOT reuse the old PR's branch directly — always cherry-pick onto a fresh branch off current origin/master.

Routed by deterministic merge pass (pulse-merge.sh).