Throws an notice as reported in this issue on wp.org for the filter_input_array() as the 3rd arg is PHP 5.4+ only.

When using WPML to translate the CPT slug, the according language is not reflected in the permalink when inserting an archive menu entry.

hi, this works perfectly when permalinks are not on, but when i have permalinks set to post name it mixes up my post types. the menu links show the wrong post type, rendering the plugin un-usable, any help would be appreciated, thanks

Currently - in my latest pull request - the loading GIF animation isn't used properly. Afaik it should only appear when the post types get added to the menu and disappear afterwards.

Would be great if you guys could submit the plugin to https://packagist.org/
It's pretty much straightforward, just go to https://packagist.org/packages/submit and add the link to the Github repository.

Hi,

The appeareance seems of on the new WordPress.
Do you use the same classes and markup as WP?

Just a quick note.

It would be really great to add Post Type Archives to the options in "or link to existing content" in the "Insert/Edit Link" modal dialogue.

Following the update to 1.3, the menu items are not getting added on a version of the site on WP Engine (including all plugins disabled + Twenty Twelve) but it still works in my local environment. The plugin works without the error in v1.2. I think this is a PHP version issue.

On WP Engine, I get this error in place of the menu item:

Warning: filter_input_array() expects at most 2 parameters, 3 given in /path/to/site/wp-content/plugins/post-type-archive-links/post-type-archive-links.php on line 363

That line is this:

$post_types = filter_input_array(
    INPUT_POST,
    array(
        'post_types' => array(
            'filter' => FILTER_SANITIZE_STRING,
            'flags' => FILTER_REQUIRE_ARRAY
        )
    ),
    true
);

According to the PHP Manual page for filter_input_array(), that third parameter, $add_empty, was only added in PHP 5.4.

This is terrific, does just what I need. But it looks like you've gone silent. Is this plugin still actively maintained? I'm a little nervous using an unmaintained plugin for a client site. Thanks.

In last 2 days I worked on the code of this plugin. My work covered 3 aspects:

1. code approach (better explained below)
2. new features
3. business logic
4. readmes update

I ended up to create a candidate V1.3, but before sending a PR, I want to discuss what I've done.

Code approach

Regarding first point main modification is on plugin boot up: instead of using a static init method, the class instantiation happen inside the add_action call: add_action( 'plugins_loaded', array( new Post_Type_Archive_Links, 'init' ) ); so init method is not static but dynamic. After that, all the hooks are moved from constructor to a method enable. This method pairs with another one disable that roll back it: remove hooks and text domain. To call disable we need the class instance, that can be retrieved using a filter hook: "post_type_archive_links".
All this changes are in comit 792c959.

The other are minor changes:

• avoid accessing $_POST directly and in 2 different place, but in one single place and using filter_input_array
• constant values (metabox id, mebabox list id, nonce) are handled via class constants instead of object properties, however the magic __get method is used for backward compatibility, to map removed variables to constants
• the method setup_admin_hooksis removed because redundant: it was a wrapper for metabox_scripts already called on 'admin_enqueue_scripts' hook

New features

• Added Italian translation
• When no CPTs available, plugin shows "No items." (using core text domain) like core does when no items are available for a specific menu items type.
• Composer support

Business logic

Currently the CPTs to be shown in the metabox are retrieved using '_builtin' => false and 'has_archive' => false, however when a CPT is registered with true 'has_archive' but false 'publicly_queryable' it is shown in the metabox, but I think they should not be added. Moreover, I think CPTs registered with 'show_in_nav_menus' set to false (even if core refers to single items), should also be removed from metabox. My code reflects these thoughts, and add a filter "show_{$cpt_slug}_archive_in_nav_menus" to force a CPT being added even if 'publicly_queryable' and/or 'show_in_nav_menus' are set to false (but not if 'has_archive' is false). My code also moves the CPTs retrieval from metabox method to a separate get_cpts method that runs just before metabox (same hook higher priority): this allow to easily show "No items." and avoid js addition if there are no CPTs.

Readmes update

I've updated:

• Changelog
• FAQ (to explain the why "No items." is shown according to new behavior)
• Contributors list adding myself
• "Manually" edit markdown readme to use repo-relative images urls for screenshots, because the wp.org urls added via grunt-wp-readme-to-markdown are not shown (they bring to a 404, I don't know why)

Compare

Code explain better than thousands of words (I hope), the full release compare is here

Hi,

I think esc_attr( 'Add to Menu' ) should hook into the WP translations by using __() function. It remains english on my installation.

(also, maybe the title can hook into the core by using __('Post') __('Type') __('Archives'), not sure though how future proof that is.)

I've just taken a look at how core adds the Nav menu items: Click on some meta box, add an item and inspect the XHR request + result in the Chrome Dev Tools console.

Here's what I've found

XHR finished loading: "http://local.dev/wp-admin/admin-ajax.php". jquery.js:2
send jquery.js:2
v.extend.ajax jquery.js:2
v.(anonymous function) jquery.js:2
wpNavMenu.addItemToMenu nav-menu.js:572
(anonymous function) nav-menu.js:146
v.extend.each jquery.js:2
v.fn.v.each jquery.js:2
$.fn.extend.addSelectedToMenu nav-menu.js:121
(anonymous function) nav-menu.js:658
v.event.dispatch jquery.js:2
o.handle.u

The interesting part is wpNavMenu.addItemToMenu. When you look at the core object wpNavMenu, then you'll see the addItemToMenu function extending it. Later core loops through something and then extends the addSelectedToMenu function. This seems to be the preferred way to do it and we should go the same route.

Inspection of nav-menu.js on line 572 and 121 needed.

Hi,

We have a site that has a menu-item that has an post-type archive link.
But, a single post of this archive (which has children) is also in the menu.

When I click on the single, the archive assumes it also the current menu item.
Something in the deduction wether it's an ancestor or not and wether it's current goes wrong.

One pointer: don't use the current-menu-item class unless it's an archive and not a single. You do this check, but you check on post_type_archive and singular (!)
The checks need to be more thorough like:

if ( is_post_type_archive( $post_type) && ! is_single() )
$classes[] = 'current-menu-item'

Not sure how to help out, I have fair bit of understanding on archives & nav.
If I have the time, I will submit a pull-request.

For now, may you have a quick fix?

It looks like you have an unclosed php statement at the end of the file.
I am no php expert (not even close), and I don't know if this is a real issue. However I get the classig "blank page after save" error in my WP admin when I activate the plugin, and after I edited the code to include the closing statement, all was fine.

Good work so far,

can you please integrate the minified versions of your javascript files to your repo.

https://github.com/stephenharris/WordPress-Post-Type-Archive-Links/blob/master/post-type-archive-links.php#L213

Using "git submodule" in production will run into problems with SCRIPT_DEBUG set to false. Unfortunately not everyone can use a task runner on server.

Best regards

I see that the plugin queries public not-built-in post types. However, in my current project, I'm using a private post type that will have an archive. (I don't think it's too hard to think of relevant use-cases for this: Anything where individual posts don't warrant a webpage but listing them all together does. Using 'public' => false prevents the "View Post" links which is my primary motivation for setting that.)

I see a lot of possible solutions but I'm not sure which is best:

1. Query for 'has_archive' => true. Since the default is false, this might be sufficient.
2. Allow a developer to filter the $post_types the plugin uses.
3. Allow a developer to filter the get_post_type()

I would lean toward option 3 (and maybe pass the $args as a parameter so both 2 and 3 are possible with that filter) but I'd love to hear other thoughts. It seems like a straight-forward way to make the plugin more flexible without changing too much for the out-of-the-box users.

I'm getting the following warning being shown in WP Dash > Appearance > Menus. Looks like the script is looking for a MIN version of the JS file and one is not provided.

 Warning: filemtime() [<a href='function.filemtime'>function.filemtime</a>]: stat failed for
F:\...\plugins\posttype-menu-links/metabox.min.js in
F:\...\plugins\posttype-menu-links\post-type-archive-links.php on line 219

Since WP changed the menu UI a bit, something seems to have changed and the metabox is disabled or something.

EDIT:

My mistake. No menu had been created yet, so all boxes were disabled. Although the "disabled" text in the image could be addressed I guess. Sorry for the inconvenience.