ere is a thing that trips up almost everyone the first time, and it is not really their fault, because the tutorials set them up for it.

You install a reorder plugin, or you enable drag-and-drop ordering. You go to the Posts screen, grab a row by its handle, drop it into a new position. The list reorders. It saves instantly, no Save button. The admin table looks exactly the way you wanted.

Then you open the live site and the posts are in the same order they always were.

No error. No warning. Just a quiet, complete lack of change. Let me explain why, because once you see it you will never be confused by it again.

What a drag-drop reorder actually does

When you drop that row, WordPress does exactly one thing. It writes a number to the menu_order column of that post's row in wp_posts.

UPDATE wp_posts SET menu_order = 3 WHERE ID = 421;

That is the entire operation. It is real, it is saved, and it is durable. But it is just a number sitting in a column.

Why the front end does not care

Your blog page, your archives, your category pages all run the WordPress main query, and the main query has a default sort:

// WP_Query defaults
'orderby' => 'date',
'order'   => 'DESC',

menu_order is not date. So the front end keeps serving posts newest-first and never looks at the column you just updated. This is the core of it: reordering in the admin and reordering on the site are two different jobs. The drag handle does the first. Nothing you dragged does the second.

Doing the second job

To make your hand-built order show on the front end, some query has to sort on menu_order. On a stock theme, that is one hook on the main query:

add_action('pre_get_posts', function ($q) {
    if (is_admin() || ! $q->is_main_query()) {
        return;
    }
    if ($q->is_home() || $q->is_post_type_archive() || $q->is_category()) {
        $q->set('orderby', 'menu_order');
        $q->set('order', 'ASC');
    }
});

Reference: pre_get_posts and WP_Query orderby parameters.

Gotcha one: posts do not even have an order field

Before you can drag anything, note that posts have no order field by default. Only pages ship with the Order attribute. The Posts list has no menu_order UI until something adds it:

add_post_type_support('post', 'page-attributes');

Reference: add_post_type_support(). This is why so many how-to posts open with a functions.php snippet before you can see a single drag handle. A reorder plugin adds this support for you, which is half of why people reach for one.

Gotcha two: the fix that works on a stock theme fails silently on a builder

pre_get_posts only reaches queries that respect filters. Two very common cases do not:

• A theme or plugin that runs new WP_Query([... 'suppress_filters' => true]). That flag tells WordPress to skip the filter chain, so your hook never runs on that query.
• A Gutenberg Query Loop block, which has its own Order and Order By controls in the block sidebar. It sorts by whatever the block says, not by your hook.

So the exact same code works perfectly on Twenty Twenty-Four and does absolutely nothing on a page builder page, and there is no error to point you at the cause. When you are on a builder, set the order in the block's own controls, or on the specific WP_Query you control.

The settings-panel version

I did this run with WP Adminify's Productivity module, which handles the drag-drop half across more than just posts. 30 second demo below.

What manual reorder gets you, and what it does not:

• Drag-and-drop across Posts, Pages, custom post types, the Media library and taxonomy terms, saved on drop
• The order field support added for you, so the handle is just there
• What it does NOT do on its own: change the front end. That is still a query concern, orderby menu_order, and you own that part
• On a builder, the Query Loop or the builder's own sort wins, so wire it there

What changed after enabling Post Types Order in Adminify → Productivity:

• Posts, media and taxonomies all became sortable from the normal list screens, no snippet to add the handle
• Nothing to re-paste after a migration, and it survives core updates
• It sits alongside the rest of the same module, the dashboard widget cleanup and the admin notice hiding, so the admin you are ordering is also the admin you cleaned
• Pair it with the admin menu layout options if what you actually wanted was to reorder the admin menu, which is a different feature people confuse with this one

The caveat I will not skip: manual order is a maintenance promise. Every new post arrives at menu_order 0 and lands at the top or the bottom, so someone has to place it. This is a great fit for small, stable sets, a portfolio, a services list, featured items, a staff page. It is a bad fit for a daily blog with hundreds of posts, where the order is stale before you finish arranging it. Match the tool to the set.

Short demo: [embed Post Type Sortable.mp4]

Step-by-step doc: Reorder posts by type in WordPress

More admin control in the same direction: remove unwanted dashboard widgets, hide admin notices, collapse and resize the admin menu, and hide Screen Options and the Help tab.

So: do you wire the front end query yourself after dragging, or do you reach for a plugin that does both halves, or do you keep posts on date order and control the display some other way?

adminify