Hierarchy

NOTE: If you're looking for something more user-focused, take a look at OrganizeWP which is complete rethinking of Hierarchy! Custom Post Types (sometimes) need context, Hierarchy allows you to rework your content management workflow by essentially moving Custom Post Type admin menus into your Pages list. What this does is mimic the navigation you've set up on your site by placing Custom Post Type edit links amongst your Pages where they belong. » Check out the screenshots to see Hierarchy in action Hierarchy removes unnecessary entries from the Admin Menu and instead injects theme where appropriate amongst your Pages, grouping everything under a single 'Content' Admin Menu entry. Custom Post Types NEED context Custom Post Types are great, but the editing workflow can be improved. Adding a Custom Post Type likely results in another WordPress admin sidebar menu, abstracting the management of that content from the main organization of your site, Pages. Hierarchy intelligently extends your Pages menu by including your Custom Post Type admin links within the Page structure, allowing for a much more natural workflow when managing your content. 比如 Chances are you've customized your Front page displays setting to display a static page instead of your latest blog posts. Now you've got a sidebar link to manage your Posts and a WordPress Page called "Blog" that sites in your list of Pages doing absolutely nothing. Hierarchy remedies both problems by converting the "Blog" page link to be one that lists your Posts. It also hides the Posts sidebar entry (if you want it to). It's also likely that you're utilizing Custom Post Types to power sections of your website, but it's awkward to manage the content of an internal section of your website using the main WordPress admin sidebar links to your Custom Post Type. Hierarchy will allow you to hide those sidebar links and instead nest them amongst your Pages, providing contextual links to manage the content of your Custom Post Types. 更多信息 If you'd like a lot more information on the implementation and workflow changes, check out the screenshots and please see the introduction and the follow-up for 1.0.

1.0.5.1

• Fixes PHP Warning
• Tested up to WordPress 5.2.3

1.0.5

• Tested up to WordPress 4.9

1.0.4

• Taxonomies are no longer contingent public being true
• Updated WP_List_Table compat with WordPress 4.4
• Added pt-BR translation, props brenoalvs

1.0.3

• Replaced 'Add New Page' button with a 'Shortcuts' button allowing for rapid access to post types and taxonomies
• Capability checks before outputting links (clicking links without capabilities results in a permission denied screen)
• New filter hierarchy_settings_capability to control who can see the Hierarchy settings
• Improved l18n

1.0.2

• Fixed an issue where pagination wasn't displaying properly
• Fixed an issue where standalone (e.g. not 'child') CPT entries were not properly output

1.0.1

• Fixed a false positive that would incorrectly output post type entries
• Clean up .org repo (deploy script didn't remove legacy files)

1.0

• Complete refactor: reorganization, optimization, PHP Warning cleanup
• Bumped minimum WordPress version support to 3.8
• Use Dashicons where applicable
• Allow 'Prevent New' for post types (prevent adding new entries)
• New filters to customize Menu entry, Menu position, page title, and more

0.5

• Improved README, added banner image to help explain Hierarchy
• Tested with WordPress 3.7

0.4

• You can now implement pagination on the main 'Content' page
• Aded entry count when considering CPTs to better call attention to posts within
• Cleaned up a PHP Warning

0.3

• Added a fix for CPTs not being nested properly in WordPress 3.4+

0.2

• Added a contextual CPT management link to the admin sidebar that displays only when editing an entry of that CPT
• Added option to include CPT entries within the Hierarchy. Added option to omit a CPT from the Hierarchy entirely.
• CPT with a rewrite slug that matches an existing Page will respect that relationship and be inserted as a child of that Page
• Posts Page is now placed properly when a custom permalink front has been put in place

0.1

• Initial release