Altering Registered Post Type Args

Today I was working on a project where I needed to change how a post type had been registered. The post type in question was setting public to false, so the post type was not a public post type. However I was utilising the post type somewhere else and needed to change this. Here is how I went about it.

Obviously when doing this I did not want to change any core or plugin code. The plugin creating the post type was the excellent whistles plugin from Justin Tadlock. This is a plugin that enables you to add snippets of content here and there including adding stuff in accordions and tabs etc.

I wanted to to use the post type as a featured content slider with the Soliloquy slider plugin. However the problem was that the post type did not exist in the drop down to select when creating a new slider. Having looked at the way in which the Whistles plugin registered its post type, it was clear that the reason it wasn’t showing as a post type to choose in the slider was because the post types ‘public’ arg was set to false. Therefore I set about finding a way to change this without chaining the plugin itself.

The first thing I did was to find in the plugin files where the post type was registered, hoping for a hook or filter which I could use in order to change the args when registering the post type. However in inspection it became clear nothing was present. This left me looking in core.

I found the file containing the function register_post_type() and noticed at the bottom of this function is a cal to do action named registered_post_type. Passed to this action is the post type name and the args for registering that post type. This meant that I could use this action in order to change any of the registered post type args.

Below is the code I used in order to change the public arg from false to true.

[wpmark_gist id=”86a965d71a6a7333ddd9″]

You can change any of the args that are registered. A dump of the ‘args’ from that function shows the following:

[wpmark_gist id=”292d91a50c6c9bafa009″]

Therefore any of these can be changed in a similar way.

My First WordPress.org Plugin!

Yesterday I decided it was about time that I tried getting one of my plugins on the WordPress.org plugin directory. Having wondered which the best plugin to submit would be, I made a decision and then submitted it. The good news was that it was accepted by the plugin review team and is now live!

The WP Admin Display Hooks plugin displays the WordPress admin hooks names, that display content to the WordPress admin. It helps developers choose which WordPress admin hook to choose if they want to output content to the WordPress admin pages.

Many thanks to the 50 people that have already downloaded the plugin and I hope it has helped you out in some way!

Download WP Admin Display Hooks from WordPress.org

The Lack of Consistency in WordPress Admin Display Hooks

Recently I have been working extensively on projects that involve working with customising the WordPress admin area to enable a better user experience. Perhaps the most notable example is working on the Edupress project with Rachel McCollin. During the course of working with amending the WordPress admin it has become apparent to me that there are a distinct lack of consistency in the admin hooks. Let me explain.

customized-edupress-admin

With the advent of theme frameworks a good few years ago now, developers have become very familiar with hooks, as well of course as those that exist in core that enable us to build on top of WordPress in the form of plugins. However a lot of the work developers do tends to be with the front end of WordPress in the form of themes. It was not until I started working extensively to convert the backend of WordPress that it became apparent there was a distinct lack of hooks and filters to work with, in terms of adding and removing content from the screen.

You can see from the screenshot above just what can be done in terms of customising the WordPress admin.

After working on the admin screens for Edupress I went ahead and created the Show Admin Display Hooks plugin, going through all the admin files in the wp-admin folder and looking for the available hooks. I was only concerned with the display hooks i.e. the ones that allow you to output content to the screen rather than the ones that enable you to add scripts and styles or functions etc.

The plugin outputs all the names of the hooks to the admin screens in the place where they are run, therefore you can see which hooks are available to work with.

It became apparent that there is a lack of consistency for developers in the hooks that they work with. Lets take a look at an example of what I mean. Below you can see two screenshots:

post-edit-admin-hooks

post-listing-admin-hooks

As you can see there are more hooks to play in the post editor screen. The problem here for me, is that all the admin screens have a page title in a h2 tag. Adding content below the title on the post edit screen can be done with the edit_form_top hook but there is no hook to do the same thing below the title on the post listing screen. Therefore a bit of consistency I believe would be helpful in this case. Therefore I would propose that a after_page_title hook is introduced on all admin screen after the page title is outputted. It seems that a before_page_title is not needed as the admin_notices and all_admin_notices hooks appear on every page.

Another hook that I would like to see added is a hook that fires directly after the “Add New” button on the post listing and post edit screen. This is a great place to add additional action buttons and would benefit from a hook. This could be something like add_new_h2 which is the name of the class given to the buttons in that area.

There is a need in the WordPress admin for plugin authors to be able to display a custom post type and associated taxonomies for that post type whilst only adding one menu item. If they add their post type under a sub menu that already exists such as Appearance, then taxonomies have to go in separately as you cannot have a third level menu. With an add_new_h2 hook, plugin authors could have links to the post types taxonomies in that place instead of an extra menu link.  This problem is outlined by Justin Tadlock with his Whistles plugin here, although Justin is suggesting a tabbed approach to solve the problem.

It is clear then that the WordPress admin does provide a number of action hooks for developer to output their own content in various places, however I think with a little more consistency on the hooks available as well as the addition of one or two additional hooks it would be much easier for developers.

View/Download Show Admin Display Hooks from Github