Page attributes 'ORDER' does not saving data for post-type 'post'.

[tanvirul]

I used add_post_type_support() function to support 'page-attributes' for Menu Order at post-type 'post'.

<?php
function prefix_add_posts_order() {
        add_post_type_support( 'post', 'page-attributes' );
}
add_action( 'admin_init', 'prefix_add_posts_order' );

When I save the post after putting an integer value in the Order field then no value is saving on 'wp_posts' table 'menu_order' column and it does not also update on the editor page.

But when I switch to TinyMCE editor it's working fine.

[felipeelia]

Hi @tanvirul and welcome to WordPress trac :)

You shouldn't hook your function to admin_init, but to init. Anyway, I was able to reproduce the problem you reported.

That seems to happen because, for posts, pages, and attachments, the JSON Schema generated by WP_REST_Posts_Controller::get_item_schema() is restricted by the $fixed_schemas variable. That said, the menu_order field is never exposed to the Rest API.

I've uploaded a patch that uses $fixed_schemas for default attributes, but still checks if those post types support other attributes. Perhaps we should remove $fixed_schemas at all, and always check this dynamically, but I guess it was there for a reason, so let's wait for somebody else input here.

Also, for the Tests suite, I think we should probably move/copy test_update_page_menu_order_* functions from WP_Test_REST_Pages_Controller to use them for all post types (custom or not). But, again, someone more experienced may have better input for this.

[lordspace]

menu_order doesn't seem to retain its value in Gutenberg.
WP v5.2.2

[websupporter]

unit test added

[websupporter]

Hi,
I just stumbled upon the same problem. Thank you for reporting @tanvirul!

I think the general idea of the fixed schema is the following: If you would generate those keys (menu_order, excerpt, etc) only dynamically, a lot of clients might break, as they might just assume every post object has an excerpt. The fixed schema ensures some stability for the core features the content types have.

That said, it is still possible to extend the basic data concept (register_rest_field()), so the fixed schema does not mean its intended to serve only those data values.

So while remove_post_type_support() should not remove properties from the JSON output, I think add_post_type_support() should add properties to it.

I tried @felipeelia fix and it works as intended. Thank you for providing it. My last patch added a unit test for the intended behavior.

In the meantime, this workaround helped me:

<?php
add_action(
    'rest_api_init',
    function() {
        register_rest_field(
            'post',
            'menu_order',
            [
                'get_callback' => function(array $object) {
                    if (! isset($object['menu_order'])) {
                        return 0;
                    }
                    return (int) $object['menu_order'];
                },
                'schema' => [
                    'type' => 'integer',
                ]
            ]
        );
    }
);

[Mamaduka]

Here's a similar report from the Gutenberg repo: ​https://github.com/WordPress/gutenberg/issues/14725.

[rudwolf]

I just stumbled on this error today and the rest_api trick worked, but do we have any update on this? I see it was opened 4 years ago...

[floo214]

+1

[Krstarica]

Experiencing the same in WordPress 6.4.3.

[beris]

Same issue in WordPress 6.5.5