Is it possible to leverage the Admin Pointers code (core, non published API) to create pointers on a custom post type? I was trying to use a plugin called Easy Admin Pointers, but it does not support pointers on a custom post type and I can't find any examples on the web that will work with a custom post type. Any ideas or tips? Thanks!

  • 1
    Please link to the plugin mentioned. Also what precisely do you mean by "on" custom post type?
    – Rarst
    Mar 30 '14 at 21:33
  • Added link above. And I mean on a custom post type, as opposed to the built in pages or posts. Custom post types are using a different naming convention than built in and I can't find a way to target the pointers to them.
    – Stephen
    Mar 30 '14 at 21:40
  • 1
    The "new post" (editor) was part I was trying to get out of you. :)
    – Rarst
    Mar 30 '14 at 21:45
  • 1
    I think part of the confusion is that you're talking about attaching it to a post type, which to us is meaningless and confusing, e.g. "I would like to send a letter to liberty" is meaningless in the same way because liberty is a concept, or "I would like to eat a meter squared". A pointer needs to point/be attached to something in the DOM/current page, not a data type.
    – Tom J Nowell
    Mar 30 '14 at 22:15
  • 1
    So your question is actually "How to restrict code to the edit/new post screens for different CPTs in the admin UI"? Right? If so, take a look at get_current_screen().
    – kaiser
    Mar 31 '14 at 2:32

Ok, I found a solution, and part of it is thanks to user kaiser above. Using a combo of that function (to find the info on each of my pages), I was then able to use code found here:


to pull it together and fill out the pointers appropriately.

Here was my whole process:

FIRST: I edited /wp-admin/post-new.php to add the following code just after the "//Show post form." comment:

    $thisscreen = get_current_screen();

That gave me the info I needed on my post new page for each custom post type.

SECOND: Then, using those values (namely "id" and "screen"), I plugged them into that github code and voila. Now I can get admin pointers that are restricted to my custom post pages!

Thanks again to kaiser above, and hope this helps others that are having similar problems. Perhaps there is an easier way to get the ids and other info from the pages in question without modifying the code and doing a dump of variables, I will be looking into it.

UPDATE: UGH, this is much simpler than I previously believed. You don't need to add the code above to get that info (although it is interesting), you only actually need the "screen", and that can be easily deduced by the url of the custom post type ie:


where "dispatches" is your screen name. I am still trying to work out how to limit the pointers to just the edit or new screen, but I can live with this...

2ND UPDATE: Able to limit to new screen by using target like so:

'target'   => '.post-new-php #insert-media-button',

3RD UPDATE (5/25/14): After working with this code for a while, and finally building a plugin based partially on it (https://wordpress.org/plugins/better-admin-pointers/), I realized that there was an error in the gist code that was preventing multiple pointers from being dismissed correctly. Instead of getting the correct item, the code would just dismiss the first pointer it found on the page if there was more than one. To correct this, I changed this:

close: function() 
                $.post( ajaxurl, 
                    pointer: pointer.pointer_id,
                    action: 'dismiss-wp-pointer'

to this:

close: $.proxy(function () {
$.post(ajaxurl, this);
}, {
pointer: pointer.pointer_id,
action: 'dismiss-wp-pointer'

And now it works as expected when there are multiple pointers on a page.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.