Drag-and-Drop Ordering for Posts adds a drag handle to your post-list tables so you can reorder posts visually. The new order is saved as menu_order and applied automatically to front-end queries, no theme changes required.

What this feature does

WordPress lets you sort posts by date, title, or author out of the box, but it has no built-in interface for arbitrary manual ordering. AdminEase fills the gap with a small drag handle on each row. Reorder rows by dragging, and AdminEase saves the new sequence to each post’s menu_order field via AJAX.

Once an ordering exists, AdminEase hooks pre_get_posts to apply orderby=menu_order to front-end queries that don’t already specify an order, so your reordering shows up on archive pages and shortcodes without theme changes.

Free vs Pro coverage

The free version applies the drag-and-drop ordering to every registered public post type. Pro adds a Post types picker so you can scope it to just the post types you want (e.g. only your custom portfolio CPT).

How to enable it

  1. Open AdminEase › Posts. Click AdminEase in the WordPress admin menu, then switch to the Posts tab.
  2. Toggle Order Posts using Drag and Drop on. On Pro, the post-types picker appears as a child field. Pick the post types you want to enable ordering for.
  3. Save settings. AdminEase adds a new Order column with drag handles to the affected admin list tables.
  4. Reorder. Open the post list (e.g. Posts › All Posts) and drag rows by the handle. The new position saves automatically and reflects in front-end queries.

Settings reference

Setting What it does Default
Order Posts using Drag and Drop Master switch. While on, drag handles appear on all (free) or selected (Pro) post-list tables and the front-end ordering is applied. Off
Post types Pro Multi-select of post types to enable ordering for. Empty means “all post types,” matching free behaviour. All

How sorting works on the front-end

AdminEase hooks pre_get_posts for the post types you enabled. When a query asks for posts of a covered post type and hasn’t explicitly set its own orderby, AdminEase sets orderby=menu_order ascending.

Practical implications:

  • Your custom theme’s archive pages will show posts in the order you dragged them.
  • Shortcodes that don’t override orderby (e.g. some [recent_posts] shortcodes) follow the same order.
  • Queries that explicitly set orderby=date or any other value continue to honour that explicit choice; AdminEase doesn’t override existing intent.
First-time activation has no effect

The first time you enable the feature, every post starts with menu_order = 0 because nothing has been ordered yet. Drag the rows once to assign positions; from then on, the order is preserved.

What happens behind the scenes

Database, AJAX, and CSS

Each drag fires the adminease_update_post_order AJAX action, which updates the menu_order column on each affected row in wp_posts. No new database tables are created.

Front-end ordering uses the standard WordPress pre_get_posts hook, set conditionally based on the post type. The drag handle is rendered as an extra column added via the manage_{post_type}_posts_columns filter, with a small CSS rule injected to display the grip icon.

Troubleshooting

I dragged a row but the order didn’t persist

Check the browser console for an AJAX error. The most common cause is a security plugin blocking the adminease_update_post_order action. Whitelist the action or temporarily disable the offending plugin.

The front-end isn’t honouring my order

Either the query you’re inspecting explicitly sets orderby (in which case AdminEase respects that), or the post type isn’t in your Pro selection. Check the relevant template or shortcode for an explicit orderby argument.

I have a third-party plugin doing similar reordering

Two plugins both setting menu_order won’t conflict (last write wins), but two plugins both hooking pre_get_posts with different sort orders will fight. Disable the redundant plugin or scope each to different post types.

The drag handle column doesn’t appear

Confirm the master switch is on. On Pro, confirm the post type is in the Post types picker (or that the picker is empty, which means “all”). If the column is still missing, another plugin may be filtering the columns array; disable plugins one by one to identify the conflict.