custom post types?

Hi @hube2,

The linked post is very old, and it’s no longer relevant.

Here are the updated requirements:
Manually:

1. The post type must support autodescription-meta.
2. The post type must have set labels.

Requirement 1 needs to be added through PHP.
Requirement 2 needs to be set on the creation of the post type.

If you wish to add post type support, simply use this call:

add_post_type_support( 'my_post_type', 'autodescription-meta' );

Automatically:

1. The post type object must have rewrite access.
2. The post type object must be public.
3. The post type must have set labels.
4. The post type object must have an admin title field.
5. The post type object must have an admin editor field.

Requirement 1 means that it can create front-end pages.
Requirement 2 means that it’s built to be publicly accessible on the front-end (e.g. User Orders in WooCommerce aren’t public, whereas Products are).

If you wish to exclude requirements 4 and 5, you should use this filter:

add_filter( 'the_seo_framework_custom_post_type_support', '__return_empty_array' );

I hope this helps!

• This reply was modified 9 years, 3 months ago by Sybre Waaijer. Reason: Missing requirement

Hi John,

I assume you use CPT UI in combination with ACF?
Then, you can simply add Custom “Supports” to apply manual integration, like so:

TL;DR version: Most importantly https://wordpress.org/about/philosophy/. Also everything else according to WordPress.org’s Philosophy.

The ability to control selected Post Type support is currently done by a “best guess”. Advanced additions, like through Custom Post Types, are mostly in the hands of developers and on how they control such interface. I can’t automatically bring anything to play without automatically determining whether it’s “good enough”, thus such limitations have been set. Steer into one direction, and although that might help some, it could just as well cause chaos at the other end.
Also, more options contribute to confusion for most users, especially when it comes to custom post types. This is where issue 20 also plays a role in, it’s an advanced and optional addition… through an extension.

Only once every half year I get a comment where users try to combine various plugins to achieve something that isn’t meant to be. Although the reasoning might be perfectly logical, this does steer me in a direction where I shouldn’t add custom support.
Note that those comments only come from other developers, those whom also tend to be more active in the forums.

In conclusion, we tend to then fall back to using filters. Extensions will eventually help many in this regard. But we’re just getting started on those 🙂

I understand that a more advanced ecosystem is wanted, but keep in mind that it’s very difficult to determine where to put the options if the registered archives do not have an admin interface, which is almost always the case.
For this, I’d like to welcome you to issue 20, which is still in discussion and testing:
https://github.com/sybrew/the-seo-framework/issues/20

Please keep in mind that in general, resources for building a free plugin are extremely limited. This is mainly because the authors must rely on donations.
It would be awesome if more developers contribute to awesome projects to fill in the missing gaps more rapidly, like the ones you’ve pointed out.

Hi @hube2,

Thank you so much for your compassion.

All suggestions are highly welcomed, especially when they come from users with developer’s competence.

If you wish to build an extension, then keep in mind that extensions are currently built with an extremely high standard (mainly with regards to security and countering otherwise non-semantics), so my advice would be to either steal another extensions’ code base as a template, or alternatively simply open issues for me to resolve until a public how-to API has been provided 🙂

Have a wonderful day John!