Filter added to 'page_attributes_dropdown_pages_args' isn't applied in Gutenberg, causing page parent relationships to change

[miscs]

Describe the bug By using the filters function my_show_all_parents( $args ) { $args['post_status'] = array( 'publish', 'pending', 'draft', 'private' ); return $args; } add_filter( 'page_attributes_dropdown_pages_args', 'my_show_all_parents' ); add_filter( 'quick_edit_dropdown_pages_args', 'my_show_all_parents' );

it is possible with Quick-Edit or Classic Editor to edit parent relations also for draft pages. This is important for some workflows because it may be necessary to create the whole structure before publishing. Unfortunately using the Gutenberg Preview functions deletes parent-relations for Draft-Pages.

1. Activate filters described above
2. Go to Pages, Create Page Root (Draft), Create Page Child (Draft)
3. Quick-Edit Page Child (Draft) and Set Root (Draft) as parent
4. Edit Page Child (Draft) with Gutenberg. Click Preview Button ==> Parent relation to Root (Draft) will be deleted

Expected behavior Parent relation will not be deleted by Preview

Desktop (please complete the following information):

• OS: OS/X
• Browser Chrome
• Version Version 68.0.3440.84 (Official Build) (64-bit)

Another question: Is it somehow possible to enable Gutenberg as well to edit parent relations for Draft pages as above filters are not working for Gutenberg?

[danielbachhuber]

Hi @miscs,

Thanks for the report. Neither then page_attributes_dropdown_pages_args nor the quick_edit_dropdown_pages_args filters are applied in Gutenberg currently, so it's not possible to easily replicate the behavior you're describing.

Requests to the REST API don't know their display context, so this would be hacky to replicate in PHP. However, we could offer some JavaScript filtering to the query used when generating the dropdown list.

In the interim, I've documented this in my Gutenberg migration guide: https://github.com/danielbachhuber/gutenberg-migration-guide/blob/master/filter-dropdown-pages-args.md

[miscs]

Hi danielbachhuber,

thanks for your answer.

I think providing Javascript filterings in Gutenberg to archive the described behaviour would be great. I understand it is certainly not the highest priority at the moment.

Nevertheless I think fixing the Preview-issue I described would be beneficial. I think a lot people will help themselves at the beginning using a mixture between gutenberg and other editing options like quick-edit. This is because you can use all "old" hooks with quick-edit but then it´s a bit disappointing when Gutenbergs deletes stuff you did in quickedit (like deleting the parent-relation I created using quick-edit).

Thanks!

[youknowriad]

I wonder if this is the same bug we fixed with ausaves recently @aduth @danielbachhuber Should we close?

[danielbachhuber]

@youknowriad No, it's not. The problem is that the page_attributes_dropdown_pages_args doesn't exist in Gutenberg context.

[youknowriad]

I guess this should be a documentation issue.

[jorgefilipecosta]

Hi @youknowriad, I don't think it is just a matter of documentation. The previous filter page_attributes_dropdown_pages_args allowed very complex customizations e.g: allowed to change the "no parent" label, allowed to display parents of a different post_type and any other type of customization to the query etc.... We don't offer a way for developers to customize any of this options right now, so we can not document a solution. What I had in mind was to compute the list of pages to display on the server, as part of the information we pass to the client and call the PHP filers so the old filter would still work. The alternative is to implement new specific js filters on the client. I thought about passing the filtered query from the server to the client but execute the request normally on the client, but that solution is not possible because there is no mapping between the names of the fields used on the server and the fields in the rest API and even no functionality match sort_column allows multiple fields and orderby doesn't.

I'm not sure about what path should be followed I would love to hear some thoughts on this.

[danielbachhuber]

@jorgefilipecosta Correct: we'll need to solve this with a JavaScript filter because, while it's possible to modify the REST API response, it would be imprecise to do so.

[youknowriad]

Developers can remove the panel and register a custom sidebar, This is a workaround.

[mheiduk]

Any updates if there will be an official filter for this? Beside that, I don't understand why drafts and private posts are not shown in the first place.

Thanks!

EDIT: After trying to implement the workaround, the CustomPageAttributesPlugin gets registered and the plugin in the document sidebar gets removed, but there are still no private posts or drafts for selection. The JS code is exactly the same which is in the doc.

I am using WordPress 5.1 with these dependencies in wp_enqueue_script: 'wp-data', 'wp-plugins', 'wp-element', 'wp-editor', 'wp-edit-post', 'wp-components'

[ybc37]

(@mheiduk About why drafts and private posts are not shown in the first place: there's this 10 years old ticket about it ;) https://core.trac.wordpress.org/ticket/8592)

[katsar0v]

Any update on this?

[lkraav]

Is anyone able to test a combination of Gutenberg level patches and https://github.com/lkraav/inclusive-parents to solve this?

[jorgefilipecosta]

We have a PR in progress that documents a way to have drafts in the page_attributes_dropdown_pages_args it follows the logic proposed by @youknowriad (remove the panel and register a custom sidebar) https://github.com/WordPress/gutenberg/pull/12395.

[ktyfuller604]

In the scenario I came across, the site needs to have private pages for their invited contributors only, and the theme in use builds out the parent page based on child pages. Because the parent page is private, they are unable to select the parent page.

I see that this issue covers the root cause for both drafts and parent pages, so I'm including the need for private pages to be able to be selected as parent pages here.

2751515-t

[cr0ybot]

Why can't we just add a JS filter hook equivalent to how the PHP filter works? Seems like we should be able to filter the query for pages before or on this line: https://github.com/WordPress/gutenberg/blob/4857ad58c1241b3d63d21a6880c989b85746c3dc/packages/editor/src/components/page-attributes/parent.js#L74

Why go out of the way to document how to totally replace a core piece of functionality when what we're asking for is a way to filter the query for what pages show up in this dropdown?

Edit: I've submitted a pull request for my filter hook proposal: #25221

[ryanwelcher]

This seems to be an issue that requires work to be done - removing the docs label for now. Feel free to re-add it once the issue has been addressed

[cr0ybot]

Oof, I had to refamiliarize myself with this issue and my (very outdated) PR. I would be willing to update it and/or do a new PR if there is any interest.

[MisterPrada]

My way

add_filter( 'rest_YOUR_CPT_query', 'filter_function', 10, 2); function filter_function( $args, $request ) { $args['post_type'] = array( 'YOUR_CPT', 'page' );

return $args; }

[crstauf]

👍