Add a 'View Archive' link to admin bar for post types.

[paulwilde]

The admin bar currently supports viewing posts, so why not archives? This patch adds a 'View Archive' link on the admin bar inside the admin should the post type support archives. This link will display when on the list view.

It also introduces a plural version of the view_item label (view_items) which custom post types can customise.

This would be a nice addition alongside #16075 to give a little bit of TLC to archives.

[atomicjack]

I agree with implementing this - would certainly be useful for quickly viewing the archives during development.

[paulwilde]

Added a screenshot.

Had to install WooCommerce and setup a custom label of "View Products" (Would be "View Posts" if not set).

Neither post type (Post/Page) in core has a public archive, so have to rely on third party plugins to include a screenshot...

[swissspidy]

Neither post type (Post/Page) in core has a public archive, so have to rely on third party plugins to include a screenshot...

This should be a feature core benefits from as well, so it should definitely work for posts.

"View Products" in this screenshot sounds confusing. I'm already looking at a list of products, so what does this button do?

[paulwilde]

Replying to swissspidy:

Neither post type (Post/Page) in core has a public archive, so have to rely on third party plugins to include a screenshot...

This should be a feature core benefits from as well, so it should definitely work for posts.

Posts do not currently have archives enabled. Surely enabling 'has_archive' would have some backwards compatibility concerns as websites would suddenly have archives of all their posts enabled without the majority of them being aware of that fact?

It's now possible to easily enable core post_types to support archives due to the filter introduced in #17447. So I think it's best to leave enabling archives for core posts/pages as a more 'opt-in' feature.

"View Products" in this screenshot sounds confusing. I'm already looking at a list of products, so what does this button do?

The same as what clicking "View Product" would do when you are editing a product in the admin, except in this instance it would view all the Products on the front-end instead of a single product.

Previously in order to get to the archive view from the admin you would have to manually type in the URL.

[knutsp]

This is a good idea. I have made such archive links in my (private) plugins when registering custom post types.

[swissspidy]

get_post_type_archive_link() works for posts as well since #19902.

[johnbillion]

#36155 was marked as a duplicate.

[swissspidy]

Moving to 4.7 for consideration.

[akibjorklund]

34113-unit-tests.diff​ adds a unit test.

[swissspidy]

In 34113.3.diff​:

• Make it work for built-int post post type.
• Change admin bar node ID to archive, as view is used for single post view nodes already.
• Adds tests to demonstrate both scenarios: archives link visible vs. not visible.

[akibjorklund]

@swissspidy: What is the purpose of setting the current screen to front before the assertions? Since $wp_admin_bar->get_node() will clone the node, there should not be any effect on the content of the node.

Oh and renaming $node_view variables to $node_archive to match the change in node ID would make sense.

[swissspidy]

Replying to akibjorklund:

@swissspidy: What is the purpose of setting the current screen to front before the assertions? Since $wp_admin_bar->get_node() will clone the node, there should not be any effect on the content of the node.

That is being done for cleanup purposes. The screen is changed at the beginning of the method, and needs to changed back afterwards. It's before the assertion because otherwise the cleanup doesn't happen when the assertion fails.
Without a cleanup, this self-contained test will potentially have an impact on other tests, which is far from ideal.

Oh and renaming $node_view variables to $node_archive to match the change in node ID would make sense.

Good catch. Simply $node is preferable in this case.

[swissspidy]

s/node_view/node

[johnbillion]

Will need a dev note for the view_items post type label.

[swissspidy]

Also needs a @since entry for the get_post_type_labels() function in addition to the dev note.

[swissspidy]

In 38634:

Toolbar: Add a 'View Posts' link to the toolbar when on the post listing screen.

This adds a new link to visit the post type archive if the post type supports it. Also introduces a new view_items label to get_post_type_labels().

Props paulwilde, akibjorklund, swissspidy.
Fixes #34113.

[afercia]

While I agree this can be useful for custom post types, for built-in posts and if the front page is set to "Your latest posts" i get the same link already used in the site name and "Visit Site" links, unless I'm missing something. We're now at 3 links pointing to the same resource. On multi site is different of course, but I'd consider to avoid too many redundant links.

[knutsp]

For post_type post only show this link if a a static page is the front page and "Posts Page" is selected. When the "post posts archive" is the front, then this link is redundant. Always show it for custom post types.

[swissspidy]

Makes sense. Will add a new patch with tests.

[swissspidy]

Happy testing with 34113.5.diff​!

[swissspidy]

In 38708:

Toolbar: Be more strict about adding a 'View Posts' link to the toolbar.

After [38634], this adjusts the behaviour to remove redundancy by not displaying the link if the latest posts are shown on the front page. In that scenario, the 'Visit Site' link already points to the latest posts.

Fixes #34113.

[desrosj]

Linking the dev note that was published here for reference: ​https://make.wordpress.org/core/2016/11/03/new-post-type-labels-in-4-7/