Support translations

[bartkleinreesink]

I like the package, but it lacks one very important feature for me to start using it: translation support.

I am not a native English speaker and my clients mostly aren't, either. So when I create a website, I want to make it at least bilingual.

Of course, I could extend the classes and move my way around the current limitations, but that is very cumbersome if it needs to be done for every project.

The biggest problem is that there is no check if the init hook has been fired already. My suggestion would be to call did_action('init'). If true, call the methods directly, otherwise, register them to the init hook.

This is a problem because I'm not able to choose when the post type is registered in the hook chain. So when I have translated strings in the declaration of the post type, they are not available at the time when the post type gets registered, because they are loaded too early. I want to decorate the class after the init hook has been fired.

[jjgrainger]

Thanks @bartkleinreesink

Translations should be supported after the changes made in 2.0.

Can you provide more details on how you are registering your PostTypes and translations?

The register method handles all the hooks needed to register post types, taxonomies, columns to WordPress so any of the PostType code should not be wrapped in any actions/filters otherwise this could lead to unexpected results. For example:

// This would lead to the `register` method not working correctly and any init actions would be registered too late.
add_action( 'init', function() {
    $books = new PostType( [
        'name'     => 'book',
        'singular' => __( 'Book', 'YOUR_TEXTDOMAIN' ),
        'plural'   => __( 'Books', 'YOUR_TEXTDOMAIN' ),
        'slug'     => 'books',
    ] );

    $books->register();
});

I'm wary of adding a did_action check as, although it may solve this use case, it may have other side effects.

Thanks

[kristjankoppel]

I support @bartkleinreesink issue.

I get "Do it wrong" error with message "Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the liven domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. (This message was added in version 6.7.0.)"

And i register my post types like following.

I have a bootstrap.php file with code something like this: class Theme extends Site { public function __construct() { $this->initializeComponents(); } private function initializeComponents(): void { $this->appPostTypeTaxonomy(); } }

And then i have file where the Postypes code is:

`namespace Propxls\App; use PostTypes\PostType; use PostTypes\Taxonomy; class PostTypeTaxonomy {

public function __construct() {
    $this->registerPostTypes();
}

public function registerPostTypes() {
    /**
     * Register Custom Post Type: Gallery
     */
    $gallery_names = [
        'name'     => 'liven_gallery',
        'singular' => _x( 'Gallery', 'admin label', 'liven' ),
        'plural'   => _x( 'Galleries', 'admin label', 'liven' ),
        'slug'     => _x( 'galerii', 'CPT slug', 'liven' ),
    ];
    
    $gallery_options = [
        'supports'     => array( 'title', 'page-attributes', 'thumbnail', 'revisions' ),
        'hierarchical' => true,
    ];
    
    $gallery_labels = [
        'add_new'               => _x( 'Add new', 'admin label', 'liven' ),
        'add_new_item'          => _x( 'Add new item', 'admin label', 'liven' ),
        'not_found'             => _x( 'Items not found', 'admin label', 'liven' ),
        'featured_image'        => _x( 'Cover image', 'admin label', 'liven' ),
        'set_featured_image'    => _x( 'Set Cover Image', 'admin label', 'liven' ),
        'remove_featured_image' => _x( 'Remove Cover Image', 'admin label', 'liven' ),
        'use_featured_image'    => _x( 'Use as Cover Image', 'admin label', 'liven' ),
    ];
    
    $gallery = new PostType( $gallery_names, $gallery_options, $gallery_labels );
    
    $gallery->register();
}

}`

And this results in that "Doing it wrong" error. I'm using Timber in my themes and that's why i do this class stuff in the first file. Also i use _x() because i want to add context to my strings so client knows where those strings are used.

[jjgrainger]

Thanks @bartkleinreesink @kristjankoppel

Taking a closer look I've been able to recreate the issue and understand it better.

Currently, it's recommended not to wrap any PostType code in a hook to avoid unexpected results, however, this creates an issue when using translations.

For example, if a PostType is created and registered in a themes fuctions.php file, in the recommended way, the localization functions are called too early before the translations are available.

// functions.php

$books = new PostType( [
    'name'     => 'book',
    'singular' => __( 'Book', 'YOUR_TEXTDOMAIN' ),  // <-- called too early.
    'plural'   => __( 'Books', 'YOUR_TEXTDOMAIN' ), // <-- called too early.
    'slug'     => 'books',
] );

$books->register();

So really, the above code should be wrapped inside a hook that runs once the translations are loaded. This can be the init hook, however this should use a priority of 9 or lower, so all other hooks are registered correctly. For example:

// functions.php

function my_theme_register_post_types() {
    $books = new PostType( [
        'name'     => 'book',
        'singular' => __( 'Book', 'YOUR_TEXTDOMAIN' ),  // <-- called after translations are loaded.
        'plural'   => __( 'Books', 'YOUR_TEXTDOMAIN' ), // <-- called after translations are loaded.
        'slug'     => 'books',
    ] );

    $books->register();
}

// PostTypes uses init hooks with a priority of 10, using 9 makes sure those are registered correctly.
add_action( 'init', 'my_theme_register_post_types', 9 );

From what I can see, there isn't a code change that can be made to the package that would fix this. Instead, it's more of a documentation change to correct the assumption that PostType code should not be placed inside of WordPress hooks.

If either of you could confirm my understanding here is correct, and you're able to resolve the issue by calling your PostType code via a hook, that would be greatly appreciated.

Thanks!

[kristjankoppel]

Thanks @bartkleinreesink @kristjankoppel

Taking a closer look I've been able to recreate the issue and understand it better.

Currently, it's recommended not to wrap any PostType code in a hook to avoid unexpected results, however, this creates an issue when using translations.

For example, if a PostType is created and registered in a themes fuctions.php file, in the recommended way, the localization functions are called too early before the translations are available.

// functions.php

$books = new PostType( [ 'name' => 'book', 'singular' => __( 'Book', 'YOUR_TEXTDOMAIN' ), // <-- called too early. 'plural' => __( 'Books', 'YOUR_TEXTDOMAIN' ), // <-- called too early. 'slug' => 'books', ] );

$books->register(); So really, the above code should be wrapped inside a hook that runs once the translations are loaded. This can be the init hook, however this should use a priority of 9 or lower, so all other hooks are registered correctly. For example:

// functions.php

function my_theme_register_post_types() { $books = new PostType( [ 'name' => 'book', 'singular' => __( 'Book', 'YOUR_TEXTDOMAIN' ), // <-- called after translations are loaded. 'plural' => __( 'Books', 'YOUR_TEXTDOMAIN' ), // <-- called after translations are loaded. 'slug' => 'books', ] );

$books->register();

}

// PostTypes uses init hooks with a priority of 10, using 9 makes sure those are registered correctly. add_action( 'init', 'my_theme_register_post_types', 9 ); From what I can see, there isn't a code change that can be made to the package that would fix this. Instead, it's more of a documentation change to correct the assumption that PostType code should not be placed inside of WordPress hooks.

If either of you could confirm my understanding here is correct, and you're able to resolve the issue by calling your PostType code via a hook, that would be greatly appreciated.

Thanks!

Thanks for quick answer! Sorry i did not respond sooner - was away on a vacation. The solution you offered worked for me and now i don't get any warnings.

Yes - improving documentation would help and this way users can avoid putting PostTypes in separate classes or hooks etc. Info about priority 9 was also very informative!

[kristjankoppel]

@jjgrainger I wanted to add that priority 9 is also too late. I wanted to add custom taxonomy to Woocommerce products and it did not appear. I looked at register_taxonomy documentation and they use add_action( 'init', 'wpdocs_register_private_taxonomy', 0 );. That worked for me also and now custom taxonomy shows up in Woocommerce.