Support » Plugins » Post Type Switcher Bug With Advanced Custom Fields

  • I’m running into a bug when I have Post Type Switcher and Advanced Custom Fields enabled at the same time.

    What’s happening is that when I make updates to my custom fields with the ACF plugin, the post_type field in the database mistakenly gets set to “post” when it should be “acf”.

    This makes the custom fields effectively disappear. They don’t show up in the ACF menus. If I go into the database and change the post_type back to “acf” all is good.

    If I disable Post Type Switcher, I don’t have this problem.

    Anybody else running into this?

Viewing 13 replies - 1 through 13 (of 13 total)
  • Klaasman

    (@reinaris)

    Yes I had the same problem and I solved it by editing the post-type-switcher plugin. But the author of the plugin should fix this because ACF is a very popular plugin.

    open the file post-type-switcher.php from the plugin folder post-type-switcher.

    On line 40 you will see:
    $safe_filter = array( 'public' => true, 'show_ui' => true );

    Change it to:
    $safe_filter = array( 'show_ui' => true );

    ACF isn’t a public post type, so it won’t show up in the post type switcher dropdown. When you saved a ACF post it auto picked the first option of the dropdown because ACF wasn’t there (it picked post).

    You can now move back your ACF posts from posts by just setting back the post type to acf with the post type switcher.

    Good luck!!

    Exactly the same problem here, took time to narrow down this one. Will post a link to this in the ACF forum as well, just in case.

    Thanks for the fix!

    Thread Starter VFHwebdev

    (@vfhwebdev)

    I seem to be having a similar problem with revisions now. Revisions are getting set with a post type “post” instead of “revision”. This only seems to be happening on the blogs that have ACF and Post Type Switcher enabled.

    Thread Starter VFHwebdev

    (@vfhwebdev)

    I did some more testing. The issue with revisions having their post_type set to post appears to be a bug with Post Type Switcher itself.

    If doesn’t arise from a combination with ACF nor is it a result of the code modification suggested above.

    I’ll start a new thread.

    Thread Starter VFHwebdev

    (@vfhwebdev)

    If you update to Post Type Switcher 1.1 this problem will come back. The piece of code that you need to edit has changed.

    Take a look at line 58:
    $args = (array) apply_filters( ‘pts_post_type_filter’, array(
    ‘public’ => true,
    ‘show_ui’ => true
    ) );

    and change this to:
    $args = (array) apply_filters( ‘pts_post_type_filter’, array(
    ‘show_ui’ => true
    ) );

    That seems to work.

    That seems to work.

    It will get nooped on the next update the same as it did with the 1.1 release.

    The filter is there to allow you to change the boundaries of the array. If other plugins need different rules, you can manipulate them here with the filter instead of hacking the plugin.

    Note that removing ‘public’ will expose other post types to the drop down. It seems unlikely that there should be UI for a private post type.

    Thread Starter VFHwebdev

    (@vfhwebdev)

    “you can manipulate them here with the filter instead of hacking the plugin”.

    Can you help me understand what you mean? I’d love a solution that doesn’t involve hacking either Post Type Switcher or Advanced Custom Fields.

    Both plugins work as expected alone. But PTS seems to make ACF set the post_type of custom fields to ‘post’ rather than ‘acf’ as it supposed to.

    This doesn’t happen when a custom field is first created, but when the field is edited.

    If there’s a solution that doesn’t involve hacking Post Type Switcher please let us know. These are both very popular (and useful) plugins and it would be great if they could work together.

    VFHwebdev, You can use something like this to disable post type switcher from messing with the post type on the ACF admin / field group setting pages. I’m using Post Type Switcher v1.1 and ACF v3.2 and they both work fine alongside each other now.

    Just drop this into your function.php:

    add_filter( 'pts_post_type_filter', "pts_disable");
    function pts_disable( $args ) {
        $postType  = get_post_type();
        if( 'acf' === $postType ){
            $args = array(
              'name' => 'acf'
            );
        }
        return $args;
    }
    Thread Starter VFHwebdev

    (@vfhwebdev)

    Thanks marcosf that did the trick and it keeps me from having to edit the plugin files.

    The only drawback is remembering to add that the functions.php file for any themes used on sites that use both plugins.

    Many thanks!

    That’s great, VFHwebdev! Glad I could help.
    Cheers!

    Thanks marcosf!

    I dropped that in my child-theme functions.php and fixed the problem.

    Post Type Switcher needs to add your fix to his notes.

    I was glad I could go into MySQL and manually change the post type to ‘acf’ to recover my custom post types.

    Have you considered just leaving post type switcher off? I mean, why would do you have PTS always enabled?

    It’s actually not meant to be always enabled. Like the name says PTS is only meant to *convert* a custom post type from one post type to another. And I’m pretty sure you’ll only need to do this once in awhile.

    Thread Starter VFHwebdev

    (@vfhwebdev)

    No, I use it all the time. I’m running multi-site and I use a plugin to pull posts from across several of my sites into the main site. Once they’re pulled into my main site they need to be assigned to the appropriate custom post type (news, events, posts, etc.)

Viewing 13 replies - 1 through 13 (of 13 total)
  • The topic ‘Post Type Switcher Bug With Advanced Custom Fields’ is closed to new replies.