Hi Jeff,
I did some investigating and just so you know this is all for testing purposes. I have no live project depending on this.
I am not sure if you are familiar with Toolset Types and Views. When you set up a CPT with Toolset you get a vast a rray of settings. As you suggested, if you disable the editor, yes Gutenberg doesn’t detect the post type as it is not conforming to what Gutenberg expects. The other requirement is that show_in_rest must be set (checked) to true. Regardless of what combination I configure, my custom post types are not listed in the Disable for Post Types list.
I think this is specific to CPTs made with Toolset. Initially I was seeing three post types: Posts, Pages and Projects. The Projects type is from the Divi theme.
I am also seeing a fourth which is a special intermediary post type that Toolset now creates if you set up a many-to-many relationship between two post types. The intermediary type is not backed by a post that you view but is used to bridge between the two parent types and in some instance has fields that can be either of the parent types.
I made such a relationship on my test site in the last day. So, its strange that this intermediary type can be seen on not the general Toolset CPTs.
The work around for the moment is to uncheck for your user role and check for the post types you can see and for Toolset types either don’t use the editor or disable show_in_rest. Not ideal if you want to use the editor or want to use any RESTful feature.
But, it is an option and with the Gutenberg project shifting goalpost and not getting anywhere fast, no panic.
It would be nice if we could ultimately switch on/off Gutenberg from the administrator level on a CPT by CPT basis and by user role to match up various use cases where each editor has its merits but I am not sure Matt and the Gutenberagedon team really know why they are doing all this.
The one aspect that they seem to be overlooking is structuring blocks to reflect the structure of layouts built in a section/row/column/module manner. With such a basic mechanism Gutenberg would have an api that would allow page builders to sit on top of. This would take away the concerns and criticisms of builders that make changing themes a pain point (the detritus of Divi shortcodes etc.).
As it is the Gutenberg team are falling between stools, saying this is not a page builder it’s for managing content, when really what they are trying to do is push everyone out of the way with a single minded approach. Just make is a page builder, albeit a rudimentary one that basic themes can use and new users will be comfortable with till they are ready to move onto more sophisticated builders.
Anyway I will leave it with you to investigate further.
