Just out of curiosity, is there reason why you couldn’t translate them when creating/editing the CPT/taxonomy? The translated version gets retained with the settings.
Otherwise, 1.0.x has these two filters available right before the registration.
$args = apply_filters( 'cptui_pre_register_post_type', $args, $post_type['name'] );
$args = apply_filters( 'cptui_pre_register_taxonomy', $args, $taxonomy['name'] );
I think there might be a misunderstanding, I do not want to create translated pairs/copies of the custom post types, or manipulate/intervene in the registration. That is why I asked for a hook and not a filter.
I want to retain a single set of post types to prevent insanity in the back end (and besides, there is no good way to translate that), but when users are exposed to the custom post types’ label (ie. in the search form filter), they should get the matching string in their language. For example, let’s take the post type ‘Photo’, which contains photographs in English and their translations; when you go to the search form, where there is a list of checkboxes for each post type, a german user should see ‘Foto’ and and english user should see ‘Photo’ while the checkbox returns the slug irrespective of the label.
What I outlined above works, it’s just unneccessary to register strings everytime somebody visits the admin menu, so I was wondering if there was a hook like save post for registering post types and/or taxonomies.
I know of registered_post_type inside register_post_type(), but it’s going to fire on every page load because post types are registered on every page load. However, you could save yourself constant writing by checking for the existence of the setting(s) your using for these extra parts before saving.
do_action( 'registered_post_type', $post_type, $args ); from wp-includes/post.php
Do you mean to check to see if post_type has been registered before? That wouldn’t fire if/when somebody edits the label of an already existing post type unless I store the label in the database, or fire it before and after registering post type, which is more intensive than just writing it in anyhow. I don’t mean to sound ungrateful for the plugin or anything, it’s great so don’t get me wrong 🙂
It might be helpful to drop in a hook on saving values in the CPT UI though for theme and plugin developers to interact with. Similar to the plugin Types (it offers a bunch of hooks, but it is a pretty complicated plugin)
No, post types/taxonomies aren’t registered once and then never again, they’re registered on every page load. What I was suggestion was to check for the existence of the settings you’re wanting to save, and only save them if they don’t already exist or aren’t altered, that way you’re not constantly updating the settings with the same data on every page load. Trying to make sure you’re not doing extra things that add to server load 🙂
That said, with the more details you’ve provided, I do have the following in the update settings function that we have:
/**
* Fires before a post_type is updated to our saved options.
*
* @since 1.0.0
*
* @param array $data Array of post_type data we are updating.
*/
do_action( 'cptui_before_update_post_type', $data );
...
/**
* Fires after a post type is updated to our saved options.
*
* @since 1.0.0
*
* @param array $data Array of post type data that was updated.
*/
do_action( 'cptui_after_update_post_type', $data );
Same hooks available for taxonomies, but just replace “post_type” with “taxonomy” Both are located in the respective inc/post-types.php and inc/taxonomies.php files towards the bottom.
Hello michael, so I can I use these like regular hooks via add_action right? Aslo, just to clarify, does ‘cptui_after_update_post_type’ fire after saving a post type initially, or just updating a previously registered one?
yes, just like any other action hooks.
They’ll all fire every time you click the “Edit Post Type” or “Edit Taxonomy” button to save the settings for either. The “before” ones will pass in the arguments for the settings to be saved, but it hasn’t been saved yet. The “after” ones will fire with the same settings parameters, but after the settings have been saved/updated.
I meant to ask, does it fire when you click ‘add post type’ / ‘add taxonomy’ also, or just on ‘edits’?
I’ll post my functions snippet over at polylang so that others can use the two plugins together, I know some were resorting to other custom type registry UIs that had the support built in.
Cheers!
Any time the post type/tax settings are being saved, these will run. Thus initial adding or edits after the first save. Sorry for not being as clear as I could be there. 🙂
I did try it but it ended up removing all the strings from that string domain, is it possible that get_post_type_object() is not available at the time of cptui_after_post_type?
It probably isn’t, at least not with the newest values that are being saved. Both hooks are going to run before the registration with the new settings.
