Support » Developing with WordPress » Sort pages in Category archive exactly as in Admin

  • Hello, I need help in successfully getting all pages under certain category to appear ordered on the frontend Category archive page exactly the way they are ordered in Admin Page admin backend. So far I tried using numerous plugins such as
    Simple Custom Post Order,
    Simple Page Ordering,
    Nested Pages,
    and of course manually, by nesting the pages via Edit Page menu, but none of that outputs this order on frontend.
    I also tried using

    
    function change_category_order( $query ) {
        if ( $query->is_category() && $query->is_main_query() ) {
            $query->set( 'order', 'asc' );
    	//$query->set( 'orderby', 'menu_order' );
        }
    }
    add_action( 'pre_get_posts', 'change_category_order' );
    

    in theme’s functions.php file, but without success. Please point me in the correct direction. I am using 2012 theme.

    • This topic was modified 1 week, 2 days ago by  528491.
Viewing 8 replies - 1 through 8 (of 8 total)
  • How are they not appearing in the same order? By default both the admin and front-end sort by post date.

    Thanks for replying so quickly.
    These are posts that have been switched back and forth being Posts then Pages, via Post Type Switcher plugin. In whichever way I re-order them by drag & drop, or by manually nesting them within each others, when I go to Category page they all have been tagged with, the order on front end does not mirror how they are ordered in admin end. I will post video screencast of this in next comment edit.

    I am posting here video screencast to show what is happening: link.

    You are correct, front end keeps sorting posts by date of creation. I need to override this by sorting it myself in Admin. I thought plugins such as Simple Page Ordering override the ‘by date’ sorting condition. What am I missing?

    Moderator bcworkz

    (@bcworkz)

    I cannot speak about the ordering plugin, I’m unfamiliar with it. Your action hook code should correctly order posts as specified, except the all important orderby query var set is commented out, so it has no effect. Remove the comment marks.

    Your code is specifying to order by menu_order. By default all posts have this set to 0 (zero). Unless your posts have been modified to use this value, it will have no effect. You can specify any valid orderby parameter here and it should be applied to any category posts query.

    However, if other code is also altering query vars using the same hook, it could be overriding your code. You can try to ensure your code has the final say by passing a large integer as the third parameter in the add_action() call. Anything larger than the default 10 should be enough.

    Some update after thorough testing/playing with it.

    The plugin I use is https://wordpress.org/plugins/wp-nested-pages/. It’s purpose is to display in frontend the order I drag&drop in backend. It also dynamically updates the navigation menu with this order.

    I just tested and this plugin assigns integers into Pages’ ‘order’ field, whenever drag&drop is being done.
    I can only force it to display this order in frontend by mandatory fullfilling 2 additional conditions:

    • Have the aforementioned hook code in functions.php (with both order ‘asc’, and orderby ‘menu_order’) enabled
    • Go manually to Appearance > Menu and save the menu after each drag &
      drop change

    It is only then that my ordering changes actually appear on frontend.

    If I exclude the hook code, the listing on frontend will fall to default, by date of post, and descending.
    If I enable the hook code, but do not manually save the the Menu, the order in frontend will be garbled with no particular logic.

    I guess I kinda found the workaround but it is far from using the plugin how it was intended. If you can shed more light on it I will be greatly thankful.

    • This reply was modified 1 week, 1 day ago by  528491. Reason: duplicate post
    Moderator bcworkz

    (@bcworkz)

    As I said, I’m unfamiliar with that plugin, but based on your observations, it’s clearly using its own ordering scheme that’s incompatible with any other ordering specification. When you save an arbitrarily ordered menu, it triggers a core WP routine that assigns order values to the menu item’s menu_order field. This is why menu_order is an essential orderby query var value. Only saving the menu triggers the reassignment. The plugin extends this concept to pages in general. Also key to understanding this is that menu items are merely a special type of posts, not much different than pages. The menu ordering should only be applied to menu item queries and those pages the plugin is managing, not other post queries, such as posts in a particular category. To maintain compatibility with menu ordering when altering post and page queries, do not alter queries if the post_type query var value is “nav_menu_item”, or “page” if you want to maintain plugin functionality. Hopefully this helps you makes sense of this.

    It’s still a good idea to add your pre_get_posts hook with a large priority number so that it can have the final say:
    add_action( 'pre_get_posts', 'change_category_order', 100 );
    Alternately, identify what hooks the plugin adds and remove them when its influence is unwanted. Care needs to be taken to be sure the removal script runs after the addition script. Obvious when written, but in practice it’s not always so obvious.

    Despite later hooks and hook removal, it’s possible the plugin is influencing queries in other ways. Just about the last hook to fire in a query is the “posts_request” filter. This filters the actual SQL request that is sent to the DB server. If you hook this filter late and ensure the query is the way it should be, it will take precedence over anything else done prior by other code to alter the query. Just remember these hooks fire for all post queries.

    Make every effort to ensure you are altering only queries that you intend to affect and not any others that happen pass through. Besides using conditionals within the callback to do this, you can also conditionally add your callback only when appropriate from within another callback that might itself be conditionally added. Or do some combination, there are all sorts of possibilities. It’s important then to have a good understanding of what hooks fire when. Tracing through source code can aid greatly in this understanding. The syntax highlighting used in the Code Reference source listing, combined with the Uses and Used By sections leading to related functions is very useful for this because the action and filter hook inline documentation stands out prominently with syntax highlighting of comments.

    Since you have a workaround, all of this may not matter much. But if you can gain a better understanding of what’s going on, it will point to what a proper solution might entail, or indicate that your workaround is as good as any other solution.

    528491

    (@528491-1)

    Thank you for detailed analysis, it will hugely help me in study of this case project.

Viewing 8 replies - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.