Chronocrow Bulk Date Updates is a WordPress admin plugin for changing publish and modified dates across many posts in one operation.
It exists to handle date corrections and timeline shifts without editing posts one by one. The implemented workflow is deliberately admin-only, limited to published content, and biased toward previewing before writing.
The plugin adds a screen at Tools -> Bulk Date Updates and lets an administrator:
- select one or more public post types from the admin UI, excluding attachments
- target only published posts
- optionally narrow the selection by:
- published date range
- latest or oldest N posts
- categories and/or tags
- choose which fields to affect:
post_datepost_modified
- run one of the implemented date update methods:
add_dayssubtract_daysmatch_modified_to_published
- preview the first 10 affected rows in test mode before writing changes
- execute the update through WordPress AJAX from the admin screen
- see a temporary "Recent Activity" table for the current page session
This codebase solves a narrow operational problem: bulk date maintenance for WordPress content while staying inside wp-admin.
The implementation is optimized for large date-only updates. Instead of calling wp_update_post() per post, it batches work and writes date columns directly to wp_posts for speed.
- Open
wp-admin/tools.php?page=chronocrow-bulk-date-updates. - Choose post types, filters, date fields, and an update method.
- Leave
Test Modeenabled. - Submit the form.
- Review the preview table. Only the first 10 matching posts are shown, even when more will be affected.
- Start from the same form.
- Uncheck
Test Mode. - Submit the form.
- The plugin updates matching rows in
wp_posts. - The page shows a success or failure message and fills the temporary activity table.
This method is special:
- the UI locks the date-field checkboxes
- the backend updates
post_modifiedfrompost_date modified_date_offsetis applied in minutes- published date is shown in preview for context, but it is not rewritten by this method unless another method changes it
Implemented now:
- admin page under
Tools - AJAX-based execution through
admin-ajax.php - publish-date and modified-date updates
- dry-run preview
- batch processing and direct SQL writes
Present in the UI but not implemented in backend logic:
specific_daterandom_range
Not present in this repository:
- REST API
- WP-CLI command
- scheduled/background worker
- persistent audit log table
- custom settings screen
- plugin-specific environment variables
- build step with Composer, npm, or bundling
- PHP WordPress plugin
- WordPress admin APIs
WP_Queryfor candidate selection$wpdbfor direct updates towp_posts- jQuery-based admin JavaScript
- plain CSS for the admin page
The repository does not declare a plugin-specific PHP or WordPress minimum version in code.
- Put the plugin directory in
wp-content/plugins/chronocrow-bulk-date-updates. - Activate
Chronocrow Bulk Date Updatesin WordPress. - Open
Tools -> Bulk Date Updates.
Activation currently adds one option:
bduk_version
No database table is created by the active code path.
Admin screen:
wp-admin/tools.php?page=chronocrow-bulk-date-updates
AJAX endpoint:
POST wp-admin/admin-ajax.phpaction=bduk_bulk_date_updates_action
Request requirements enforced by the plugin:
- authenticated WordPress admin session
- capability
manage_options - nonce for
bduk_bulk_date_updates_nonce
chronocrow-bulk-date-updates/
├── chronocrow-bulk-date-updates.php
├── uninstall.php
├── includes/
│ ├── class-bduk-plugin.php
│ ├── class-bduk-date-resolver.php
│ └── admin/
│ └── admin-page.php
├── js/
│ └── admin.js
├── css/
│ └── admin.css
└── languages/
└── chronocrow-bulk-date-updates.pot
What each file does:
chronocrow-bulk-date-updates.php: plugin bootstrap, constants, dependency loading, and startupuninstall.php: guarded uninstall cleanup for plugin-owned optionsincludes/class-bduk-plugin.php: main orchestration class for admin hooks, AJAX handling, validation, preview generation, batched writes, and lifecycle helpersincludes/class-bduk-date-resolver.php: shared date calculation for preview and live updatesincludes/admin/admin-page.php: form markup and inline UI behavior for conditional fieldsjs/admin.js: AJAX form submission, status messages, preview rendering, activity table renderingcss/admin.css: admin layout and presentationlanguages/chronocrow-bulk-date-updates.pot: generated translation template for WordPress.org packaging
- only published posts are targeted
- maximum
limit_postsaccepted by the backend is10000 count_limitfilter accepts1..1000- preview mode shows at most 10 rows, even when more posts match
- category/tag filtering is only useful for post types that actually use those taxonomies
- the modified-date offset is sanitized as a non-negative integer in the current implementation
Usually means one of these:
- your post-type selection has no published posts
- the date range excludes everything
- the latest/oldest filter is narrower than expected
- you chose category/tag filtering for content that does not use those taxonomies
For non-dry-run operations over 1000 posts, the plugin rejects the request unless PHP memory_limit is at least 512M.
If you chose Set Specific Date (TBA) or Random Date Range (TBA), that is expected in the current codebase. Those methods are exposed in the form but are not implemented in the write logic.
That table is not persisted. It is populated from the AJAX response of the current operation only.
The UI only has built-in taxonomy selectors for standard post categories and tags. Pages show a message that they do not use those taxonomies by default.
This plugin does not target them. The backend hardcodes post status to publish.
- Start with
Test Modeenabled. The plugin defaults to preview for a reason. - For larger runs, execute during a low-traffic window because the plugin flushes object cache after completion.
- If your site depends on other code reacting to normal post-save hooks, review
ARCHITECTURE.mdbefore using this on very large production sites.