3

Assuming you write a plugin and hook into activation / deactivation to register_post_type is that good enough? Or do you need to do it every init?

I'm looking for perf boosts and I want to reduce unnecessary calls.

GenerateWP uses add_action( 'init', 'custom_post_type', 0 ); so that might be as early as I might want to register it.

FINDINGS

  • @s-ha-dum:

    register_post_type needs to be called on every page load

    The post data itself is kept in the database, but the registration tells the PHP what to do with it.

  • @pieter-goosen:

    Build in types are actually registered twice on every page load (due to localization that is only available on init)

2 Answers 2

3

register_post_type needs to be called on every page load-- init seems to be fine and is the hook used in the Codex sample. The post data itself is kept in the database, but the registration tells the PHP what to do with it. Most of the post type information-- the $labels, the $args-- are not kept in the database to my knowledge (though I would agree that there might be an argument for doing so), so without that registration code Core doesn't really know about the post type.

You can pretty easily test this yourself by registering the type and then commenting the code.

3
  • Thanks. I didn't know if I was missing something.
    – jgraup
    Dec 18, 2015 at 21:24
  • Think of it like instantiating a Class and it will bother you less ;) For the record, though, I am not sure that storing in the DB would offer any performance improvement and I'd actually bet against it.
    – s_ha_dum
    Dec 18, 2015 at 21:24
  • It seems more like encapsulation than instantiating
    – jgraup
    Dec 18, 2015 at 21:27
3

All post types and taxonomies are registered on every page load, regardless being build in or not. There is really nothing you can do about that.

Build in types are actually registered twice on every page load (due to localization that is only available on init) , so trying to optimize custom types are quite useless.

As post types and taxonomies data are not stored in db, you are already saving on db calls, although you are dirtying global space with their data. I'm not really sure which is better here, adding extra db calls to an already insane amount of db calls per page load or adding even more junk to global space.

Wordpress was actually never meant to go mainstream when they started of, so many features was never well thought of. Some of the mess made in earlier version cannot be undone without breaking thousands of sites due to their backwards compatibilty policy.

If you really need to optimize your site, start with obvious stuff like queries, minimilizing scripts and styles, caching large amounts of data, etc etc. As for core functions, all you can really do is to submit proposals to improve performance of specific functionalities and hope that your proposals gets approved and included in future releases

3
  • That localization part is good to know.
    – jgraup
    Dec 18, 2015 at 21:46
  • 1
    So is the part that Wordpress registers build in types twice. It is like eating the same piece of meat twice ;-) Njammie. That is called good recycling Dec 18, 2015 at 22:01
  • Right, registering twice because of localization, and that localization needs to happen after init. So would registering it before init still call on init for localization? Or assuming you remove localization from labels -- what internally gets localized?
    – jgraup
    Dec 18, 2015 at 22:10

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.