Power Editor Workflow with AdminEase Pro: Drag-Drop, Bulk Delete, Metadata

1. What Pro adds and when it pays for itself

AdminEase Pro is not a "more security toggles" pack. It is specifically the features that change how editors and administrators interact with content already in the database. If your site has a handful of pages and a couple of blog posts, the free version is plenty. The Pro features pay for themselves when the site has:

• A real custom post type with manual ordering, where editors care which item appears first on a portfolio or services page. Without drag-and-drop, ordering is done by setting numeric values in a "menu order" field, which is slow and error-prone.
• A taxonomy with more than ten terms, where the same display-order problem applies to categories or tags. WordPress's term ordering is alphabetical or by ID by default; drag-and-drop adds a manual order.
• Bulk content lifecycle operations: archiving old draft revisions, deleting test posts after a content migration, removing all posts from a deprecated post type. The default "select 20 and click delete" UI does not scale past a few hundred items.
• Complex custom fields stored as post, user, or term meta, where you need to see what is actually stored without dropping into the database. ACF and similar plugins show their own configured fields, but they hide everything written by other plugins, themes, or one-off scripts. The metadata boxes show all of it.

The Pro features live across three tabs: Posts, Taxonomies, and Users. Each section names the exact path.

2. Reorder posts by drag and drop

By default, WordPress orders posts by published date in descending order on archive pages and post lists. For a blog, that is what you want. For a portfolio, a team-bios page, a "featured projects" section, or any custom post type where editorial order matters, it is not. WordPress includes a "menu order" field for this purpose, but the UI for setting it is awful: open each post, change a number, save, repeat.

Drag-and-drop replaces that with what it sounds like. In the post-type list view, editors grab a handle on each row and drag it up or down. The order persists as menu_order values in the database, so themes and queries that already use orderby=menu_order work unchanged.

The feature filters its allowed post types through adminease_drag_and_drop_ordering_posts_post_types, which lets a developer further restrict or extend the list from a mu-plugin if needed. The capability required to use the drag-handle UI is edit_posts, so contributors and authors can reorder without admin access.

3. Reorder taxonomy terms by drag and drop

The same problem applies to taxonomy terms. WordPress sorts categories and tags alphabetically or by ID in admin lists and on the front-end. For taxonomies where there is a natural editorial order (skill levels, product tiers, project stages, course modules), neither default works. Drag-and-drop adds a manual order persisted as term meta.

Allowed taxonomies are filterable through adminease_drag_and_drop_ordering_taxonomies_taxonomies. Capability required to reorder: edit_posts.

4. Bulk delete posts (read this carefully)

This is the feature most likely to cause damage if used carelessly, and the one that pays back the most when used carefully. Bulk Delete Posts gives you a settings panel with filters: post type, post status, date range, deletion method (move to trash or permanently delete), and batch size. You configure the filters, click submit, and the plugin processes the deletion in chunks via AJAX so a large operation does not time out.

The "post types" field filters by which post types are eligible. The "post status" field filters by publish status (published, draft, pending, private, scheduled, trash, plus any custom public statuses your site registers). The date range narrows the deletion window. The deletion method offers two paths: Move to trash (recoverable for the duration set by your EMPTY_TRASH_DAYS from the previous tutorial), or Permanently delete (irrecoverable, including all post meta and attached comments).

Batch size controls how many posts are processed per AJAX call. The default is sane; smaller batches make the operation slower but safer (each batch is its own atomic step, easy to abort). For very large operations on a heavily-loaded server, smaller batches also reduce the risk of hitting max_execution_time or memory limits mid-batch. The set of post types and statuses available to choose from is filterable via adminease_bulk_delete_post_types_options and adminease_bulk_delete_post_statuses_options, so a developer can extend or restrict them per project.

5. Inspect and edit post metadata

WordPress stores a vast amount of per-post data in the wp_postmeta table that you cannot normally see from the admin. ACF fields are there. Yoast SEO data is there. SeoPress, RankMath, Elementor's per-page settings, page builder configuration, custom plugin data, one-off scripts that wrote a few values years ago and forgot about them. Most of it is invisible unless you query the database directly.

The Posts Metadata Box adds a panel to the post editor that lists every meta key and value attached to the current post, lets you edit each value, and lets you add or delete keys. It is the WordPress admin equivalent of "open a database client and run SELECT * FROM wp_postmeta WHERE post_id = X" without leaving the editor.

Allowed post types are exposed through the adminease_posts_metadata_box_allowed_post_types filter. Capability required to view and edit: edit_posts.

6. Inspect and edit taxonomy and term metadata

Two related features cover the taxonomy side. The first lets you add a metadata box to the taxonomy archive editing screens (the page you reach via Posts › Categories or Posts › Tags in a typical site). The second adds a metadata box to individual term editing screens (when you click a specific category to edit it).

The taxonomy meta box covers hierarchical taxonomies only (categories and similar). The term metadata box covers all taxonomies, both hierarchical and flat (tags-style). Both expose their allowed lists through filters (adminease_taxonomy_meta_box_taxonomies and adminease_term_metadata_box_allowed_taxonomies).

The use case for term metadata is heavier than it sounds. Many plugins (especially commerce, learning management, and event plugins) store significant data as term meta, including pricing, dates, image associations, and access rules. Without a visibility tool, that data is invisible unless you go through the plugin's UI, which often shows you a subset and hides the rest.

7. Inspect and edit user metadata

The User Metadata Box does for users what the Posts Metadata Box does for posts. WordPress's wp_usermeta table holds capability data, session tokens, last-login timestamps, plugin-specific settings, custom profile fields, and anything any plugin has chosen to write per-user. The default user-edit screen shows only a small subset (name, email, role, biography, the bare minimum). Everything else is hidden.

Three AJAX endpoints back the UI: adminease_get_user_metadata, adminease_update_user_metadata, and adminease_delete_user_metadata. Each is nonce-protected and requires the edit_users capability, which by default is granted only to administrators. The get endpoint returns the full user meta via get_user_meta($user_id); the update endpoint writes via update_user_meta(); the delete endpoint removes a single key via delete_user_meta().