Hi there,

It seems that it doesn't work in a multisite environment, whereby i could select the page under permalinks before I had a multisite but now I can't.

Do you have thoughts on getting this working with a multisite?

ThanksmTom

Step To reproduce

1. Create a custom post type and create some samples posts
2. install this 'page-for-post-type' plugin
3. Chose a page to use as archive in setup > reading
4. Go to selected page URL :

The bug is here :
Chosen page correctly appear but seam to use 'page.php' template (and not 'index.php' or 'archive.php' template). my custom posts are not listed on my page. Why ?

Hi! This is an amazing plugin which we use almost in every site, thanks!

There are a few things that are bugging me, related to compatibility with Polylang:

• CPT archive page slugs need to be translated in Polylang "Strings translations" tool to exactly same as the translated archive page slug is. I'd like to find a robust solution for this, or at least give the user a reminder about this
• menus do not get current-menu-item etc classes for translated archive pages, I have a small workaround for that to be put in filter_wp_nav_menu_objects function after $page_ids is set

if ( function_exists( 'pll_current_language' ) ) {
      if ( pll_current_language() !== pll_default_language() ) {
        foreach ( $page_ids as $tmp_page_id_key => $tmp_page_id ) {
          $page_ids[ $tmp_page_id_key ] = pll_get_post( $tmp_page_id );
        }
      }
    }

I'm wondering, do you accept PR's for this kind of compatibility issues or should I create a plugin for Polylang compatibility?

I'd like to just include this code in my starter theme files, but I can't seem to get it working. Any tips on how to make this work?

In #9, @fabienlege writes that he expected the loop to automatically run on the page.
@codepuncher responds:

This is just to let users choose a page to act as the relating archive to the post type. This means you can put anything on this page.

Strange thing is: On two test projects of mine the archive.php template is used, displaying the post loop. This is the opposite of what @codepuncher und @roborourke claim. Am I right that the page should display it's content? If yes, why does it display the custom post type archive for me?

Note that I need to manually flush rewrite rules by clicking "Save changes" on "Settings" -> "Permalinks" to make this happen.

My setup:
PHP v7.1.12
WordPress v4.9.6 (based on Bedrock)
Theme: Twenty Seventeen
No other plugins active (execpt self coded plugin to register custom post type)

Any suggestions how to fix this is highly appreciated! Thanks!

The LICENSE file has the content for GPL v2, but the composer.json has a "license": "GPL-3.0".

Should the latter be a value of GPL-2.0+?

After activating the plugin, it just adds an empty section into the Settings > Reading.

The site has 5 custom post types registered in functions.php.

WordPress: 4.9.4
Page for post type: Downloaded on 13 Feb 2018 from Master

Great plugin!

If none of the custom post types has archive enabled the plugin will only output the heading Pages for post type archives (see #12):

I expect to get a notice like None of your post types has archives enabled.
What do you think? Thanks!

Amazing simple plugin, and it's now an essential part of my WP stack.

Would it be possible for you to add a composer.json and register the package on Packagist, so that the plugin can be called in with Composer?

I would also recommend you include wordpress-plugin in the type field.

If you'd prefer, I could give you a pull request for the composer.json file but someone at Human Made should be the one to add it to Packagist so you can control it on that end.

Option dropdown seems to use post types slug as a default slug. Before using it, there's need to check if custom slug is set in rewrite argument.

Hi, I'm running into some issues which appear to be related to the plugin somehow.
When I enable a page to be the archive for a post type, sometimes the single view for that post type starts responding with 404.

What's puzzling is that this does not happen consistently for all post types, and it isn't consistent either from local to server installs.

Have you seen a similar behaviour before? Any workaround?