1

I have a question about this documentation.

Why would I register a Custom Post Type in the init function as the docs suggest? Is this only if I am not using a plugin?

As I understand it, init runs every-time WordPress runs/is-loaded by the user. Doesn't this mean the site is needlessly re-registering a new post type on every visit? Why not (if building a plugin) register the post type in require_once plugin_dir_path( __FILE__ ) just when the plugin activates?

Wouldn't that also speed up the site? Or am I interpreting init() wrong? Surely the custom post type persists in the database somewhere so doesn't have to be called on every init()?

Here is the Custom Post Type example from the docs, using init():

function create_post_type() {
  register_post_type( 'acme_product',
    array(
      'labels' => array(
        'name' => __( 'Products' ),
        'singular_name' => __( 'Product' )
      ),
      'public' => true,
      'has_archive' => true,
    )
  );
}
add_action( 'init', 'create_post_type' );
0

register_post_type function should be executed every time a WP request is made. Default post types don't have this requirement. You can use your code as is, in MU plugin. Just create a .PHP file with this code, and place it in mu-plugins sub-folder of wp-content. You don't need to provide any standard plugin headers.

  • But... why? Why do I need to re-register on every request? Will it disappear if I don't call it? Isn't this the sort of thing that should persist... – Summer Developer Jul 18 '18 at 21:55
  • Only the content, and the name of CPT are stored in database. Registration of CPT is needed to build admin menu items for that CPT ( labels, and other menu related things ). If you don't register a CPT, then you will not have access to it. – Frank P. Walentynowicz Jul 18 '18 at 22:01
  • If the CPT is going to be private and not on the admin menu anyway is it viable to prepopulate it using the plugin activation hook and then query it later? – Summer Developer Jul 18 '18 at 22:03
  • It does not matter. WP knows everything about default post types, but knows nothing about CPT, until is been registered. This how it's been designed. I agree with your concept, but for now, this is how it's done. – Frank P. Walentynowicz Jul 18 '18 at 22:06
  • Hmm... okay, just making sure I wasn't completely wrong. :) – Summer Developer Jul 18 '18 at 22:10
3

Surely the custom post type persists in the database somewhere so doesn't have to be called on every init()?

No, it's not. Why would it need to be? A custom post type is a handful of variables that WordPress will use to set up the UI for data saved with that post type in the database.

If the data were going to change frequently, and the changes needed to be persistent, then storing in the database would be necessary, but post types do not change after development.

Considering that, saving the settings for the post type in the database would only hurt performance, as WordPress would need to query the database just to get the settings for registered post types on every page load, which is slower than just executing the registration code each time (which remember is just a handful of variables).

The most expensive part of registering a post type is generating its rewrite rules, which is why those are stored in the database, and the rewrite rules should be flushed on the activation and deactivation hooks.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.