Prajesh Content Grid

Description

Prajesh Content Grid helps editors make considered changes to existing WordPress records. Stage individual cells or selected-row changes, compare previous and proposed values, then explicitly apply the reviewed batch.

• Posts, Pages and eligible editorial custom post types.
• Title, excerpt where supported, and explicitly registered single-value scalar metadata exposed to the WordPress REST API.
• Search source titles/content, filter status and choose personal columns for each content type.
• 50 records per page with a horizontally scrollable grid and sticky record labels.
• Stage set, append or prepend operations; remove supported metadata with restoration of its prior existence during undo.
• Before/after review, per-record results, resumable groups and private change history.
• Permission checks, active editor lock checks and signed snapshots that detect changed records before apply and undo.
• Administration built with the WordPress-provided element and components packages.

All included functionality is free. No account, external service or telemetry is required. There is no public-facing output.

Important scope

This is an editor for existing editorial records. It does not import, create, delete, publish, schedule or change record status. It does not edit full post content, blocks, taxonomies, media, products, orders or arbitrary unregistered metaboxes. Array/object fields, repeaters, protected or non-single metadata, restricted fields and values over 8 KB are not editable. ACF fields are eligible only if explicitly registered as supported scalar REST metadata; this is not a general ACF adapter.

Review up to 100 records and 500 proposed cells in one batch. Proposals are limited to 256 KB and normalized review data to 512 KB. Apply/undo requests process up to ten records each; the interface continues automatically and can pause between groups. These bounds protect server resources; there is no total usage quota.

Storage and privacy

Staged edits remain in the current browser tab until a review is prepared. Preparing a review stores the proposed and previous values in private, non-autoloaded WordPress options. Each editor can retain up to ten recent batches for seven days. Pending previews expire for apply after 15 minutes. Applied batches remain eligible for conflict-checked undo during retention. Daily scheduled cleanup removes expired journals in bounded groups; WordPress cron depends on site traffic. Access after retention expires is denied even before cleanup runs.

Column preferences and batch references are stored in user metadata. No information is sent to an external service. Uninstall deletes these plugin settings and journals while preserving posts and custom fields. Deactivation stops cleanup but preserves data for reactivation.

Save and undo behaviour

Safe writes require InnoDB posts, postmeta and options tables. Each record and its journal entry use one transaction; batches can contain a mixture of saved and skipped records. Repeated requests do not reapply completed rows. Later changes, permission changes and active locks can cause a row to be skipped. Reload and prepare a fresh review to resolve conflicts.

Undo restores reviewed fields only if the record still matches its post-apply snapshot. It does not override subsequent edits. History is a short-lived recovery aid, not a backup or full versioning system. Keep regular backups. Third-party save hooks may trigger external actions or modify other tables/caches outside these transactions; those effects cannot be undone by this plugin. Test integrations on staging.

Single-site WordPress only. Users need edit_posts to access the tool, plus normal content and metadata permissions for each record. No user gains access to another editor’s batches.