Skip to content
This repository has been archived by the owner on Dec 16, 2022. It is now read-only.

Allow pages to be re-ordered by drag-and-drop on page Customizer sections #32

Open
westonruter opened this issue Mar 2, 2016 · 5 comments

Comments

@westonruter
Copy link
Contributor

This could also be how page hierarchy is managed.

Careful we don't want to duplicate existing logic for nav menu management.

@westonruter
Copy link
Contributor Author

westonruter commented May 11, 2016

I think that this drag-and-drop UI should only apply if a page is not hierarchical. So a post type should be able to indicate whether it can be sorted manually but is not hierarchical. I don't believe there is currently a post type support for this. There is a page-attributes support feature that includes the page template (page-template)), page parent (parent), and sort order (ordering). These should be split out into separate features.

@westonruter
Copy link
Contributor Author

I suggest x-ordering as the initial post type support name we can use for the ability to drag-and-drop a flat list of post types.

@westonruter
Copy link
Contributor Author

We'll likely want to only modify the menu_order of the one post being re-sorted, to avoid having to modify all of the weights of the other posts (unless necessary). To do this, we'll need to create new posts with sparse orderings, perhaps an increment of 100 (or count(posts)) between each post.

@celloexpressions
Copy link

I think the experience would be a lot better if we can set menu order and hierarchy based on usage in menus. The biggest challenge there is deciding which menu to use, and that may require a user option. But with both posts and menus in the customizer, there's an opportunity to integrate the functionality more closely.

@westonruter
Copy link
Contributor Author

@celloexpressions I agree. Ideally the menu_order and post_parent (#65) would be linked to however the post is used in a menu. The difficulty here, of course, is when a page is used in a nav sub menu where the parent nav menu item does not correspond to a page at all. Normally in such cases I think a page would just not have a parent at all. But if we linked post parents to nav menu items… what if instead of the Parent dropdown being a list of all posts of that given type, if instead we listed all nav menu items for all menus? Difficulty then would be what to do with a page that appears in multiple menus. I guess the Post Parent selection would largely become irrelevant and should perhaps be hidden entirely if management of the relationship is done via menus instead. The menu order field could also be removed in favor of directing the user to use nav menu items instead. But… I can also see where there would be a need to manage post ordering outside the context of a nav menu. The example which comes to mind is a “employee” custom post type, where the CEO would have menu_order of 1.

kienstra pushed a commit that referenced this issue Aug 17, 2016
WP_Customize_Posts may not be instantiated if a filter removes 'posts'.
So the class WP_Customize_Postmeta_Setting may not exist.
In this case, it would cause a fatal error, when accessing its property.
So begin the conditional with class_exists().
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants