New to the community? Start here

How can I use it for custom post types?

0

Can you please tell me what to modify so I can use it for custom post types too?

And would you consider adding this as an option?

Thanks

Wed, 30 May 2012 8:49:38
  • Rone
    • Site Builder, Child of Zeus

    Hi Maniu,

    This has been working great, except for one custom post type I use that’s a part of iThemes builder.

    I have already contacted a lead iThemes dev about Lock Posts not working with their “Widget Content” custom post type. Below you will find our exchange in the iThemes forums.

    Hopefully it makes sense and is something that can be addressed in the Lock Posts plugin as far as custom posts are concerned.

    Thanks and have a great weekend.

    My OP in the iThemes Forums:

    Hello,

    I was wondering if there was way to setup Builder’s “Widget Content” as more of a traditional WordPress custom post type?

    Right now, plugins like “Accordion” can be tapped into by other WordPress plugins (like Lock Posts) that integrate any custom post types the WordPress installation might be using; but “Widget Content” items don’t seem to be integrated that way at the moment.

    It’d be great if they could be to extend their modularity and use when implementing WP as a more of a CMS solution.

    …

    Thanks

    Response from an iThemes Lead Developer:

    Widget Content is no less a custom post type than any other. The problems with integration with other plugins typically stems from the plugin ignoring custom post types that have the public argument set to false.

    I managed to get access to the Lock Posts plugin to look through it’s code, and I found the following is the reason that the integration does not work with Widget Content:

    $this->post_types = get_post_types(array('show_ui' => true, 'public' => true));

    In other words, both show_ui and public must be true in order for Lock Posts to integrate with the custom post type. The additional requirement of public being true is unnecessary as all the code is trying to understand is whether or not the post type shows up in the admin Dashboard, which is what the show_ui argument handles. I should note that the show_ui argument is set to true for Widget Content which is what provides the admin interface. Widget Content needs public to be false so that it doesn’t show up in front-end search results, have a front-facing page like post or page post types, have the ability to be added to navigation menus, etc.

    I would recommend talking to the devs over at WPMU Dev to see if they can remove that public being true part of their post type queries as that will fix the integration issue.

    I see the same issue with Accordion where it is requiring both show_ui and public to be true. I’ll notify the developer of Accordion about this issue so that it can be corrected.

    As for the other plugins, I recommend asking their support about being able to integrate with custom post types that have show_ui set to true while having public set to false.

  • Maniu
    • Developer

    Hello @Rone

    I was wondering if adding it just for public custom post type would be good enough….

    I will think about solution for this problem. My goal was to not create unnecessary visual elements for custom post types that dont need it but it seems that sometimes it is simply needed everywhere:slight_smile:

    For now i would suggest changing:

    $this->post_types = get_post_types(array('show_ui' => true, 'public' => true));

    to:

    $this->post_types = get_post_types(array('show_ui' => true, 'public' => false));

    Thanks,

    Maniu

  • Rone
    • Site Builder, Child of Zeus

    Yep, that did the trick. I definitely look forward to a solution that won’t require changing that line of code for with each plugin update, but for now, its more than doable.

    Thanks for the great support!

  • Rone
    • Site Builder, Child of Zeus

    Hi Maniu,

    More feedback from the iThemes dev regarding your temporary solution:

    Your recommended change is just as incorrect as the original code. The original code excludes post types that have public set to false. Your modification excludes post types that have public set to true.

    The correct solution is to simply not include public in the query. This way, the only criterion is whether or not show_ui is true, which is the only concern for this specific post type query.

    In other words, it should be:

    $this->post_types = get_post_types(array('show_ui' => true));

    I went ahead and used his code and it also seems to work across all post-types just fine.

    I’m not sure if its more of the long-term solution you were looking for applying “Lock Posts” to custom post types, so I thought I’d share just in case it was or helps lead us to that more permanent solution…or actually has drawbacks that he is unaware of.

    Cheers.