Support » Plugin: Pods - Custom Content Types and Fields » Futureproofing

  • Resolved wpfan1000



    I am trying to understand how the possible future cancellation of the Classic Editor plugin may affect custom fields.

    I tried Pods and if I add a few fields to the Post content type, and then add a new Post, the editor shows the Title, then a Block section where I can add multiple blocks, and then the Pods fields below it.

    My understanding is that in order to have only custom fields, ie no Blocks, I need to install the Classic Editor or similar plugin, and disable Content in the Post content type. Then I have only the Title and custom fields in a Post content type.

    Is my understanding correct?

    If I create a new CPT in Pods, and add fields to it, and then add a new entry of this CPT, I see the Title, the classic editor and the fields.

    So it looks like Pods has decided to use the classic editor with new CPT types.

    I can then remove the Content of this CPT to remove the Classic editor.

    My concern here is that if create a WP site now, that needs a CPT with only custom fields (no Blocks or classic editor), and in future WP decides to remove support for the classic editor, then my site will not be usable in the future, because a CPT will always have a undesired Block section in the editor.

    Is my understanding/concern correct?

    If it is, how do I future-proof my site to avoid this problem?

    Thanks ahead of time…..

Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Author Jory Hogeveen


    Hello @wpfan1000

    This would be a question for WordPress core.
    In any case custom fields will (should) keep working with WordPress’s block editor.

    Cheers, Jory



    Bedankt for your reply, and I can certainly bring my concern to the attention of WP core, but surely Pods has an opinion on this?

    Plugin Author Scott Kingsley Clark


    Pods (along with other custom field plugins) will continue to support meta box implementations that work in both Classic and Block editors. You don’t need the Classic Editor plugin to use Pods.

    The Classic Editor plugin will likely get long term support from WordPress contributors, but it won’t see much/any interface updates going forward.

    But if you get past the Block editor’s interface and focus on the fact that the blocks are your content, and Pods adds all of the custom fields in the section below, you’ll be able to shift into the Block paradigm much more easily.

    To enable the Block editor for a post type, you’ll want to be sure to enable REST API for those post types. We have REST API off by default because it’s not always needed but this will be changing in an upcoming Pods release.



    Hi Scott,

    Thanks very much for your reply.

    I actually don’t mind Blocks. It is not that I would like to not use them because I don’t like Blocks.

    I would like to not use Blocks and only custom fields/meta boxes so that a user who creates a new entry does not have the ability to add their own blocks.

    My understanding is that currently, if I use meta-boxes with a CPT that uses Blocks, there will always be an empty block area at the top of the entry in which a user can add as many blocks as they wish, and then enter data into the meta-boxes below. So a user could enter say 10 blocks before the meta-boxes. I don’t want this to ensure that entries all follow the same format.

    To enable the Block editor for a post type, you’ll want to be sure to enable REST API for those post types.

    I am sorry if I don’t quite understand what you are suggesting about disabling the REST API. If I add custom fields to the Post default CPT, the Block area is already enabled. I don’t need to enable the REST API I believe, since the Block area is already there.

    Do you mean then if I don’t want a Block area nor a Classic editor in a CPT, I should disable REST API for that CPT?

    Or do you mean that if I create a CPT with Pods, and I want to use Blocks, then I need to disable REST API?

    I started to look into disabling the REST API, and I don’t see how it relates to Blocks, and I don’t see a way to disable it for a specific CPT.

    To be clear, I don’t want the Classic editor nor Blocks in a CPT.

Viewing 4 replies - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.