You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When creating a custom post type with show_in_rest => true and exclude_from_search => true, the search suggestion feature when looking up links, such as the anchor button in the toolbar or the core/button's block link input shows those custom post types.
show_in_rest => false should not be used as a means of filtering suggestions as its reach is far broader. For example my CPT's are using custom blocks and need this option be true.
Why does this matter?
These are links that will be public facing, and as such should not be an option for editors. If so, they will culminate in 404 pages.
Suggestions will return Title's of CPT's and as such many folks will use identical or similar titles in their custom post types, causing confusion on which suggestion is the right one.
To reproduce
Create a CPT called Testimonials with show_in_rest => true and exclude_from_search => true
Add an entry into the CPT with title "Demo Testimonial"
Go to a page, add a paragraph block
Create an anchor on the paragraph block using the toolbar and search for word Testimonial - you will see "Demo Testimonial" in the suggestions
Expected behavior
You should not see Demo Testimonial in any search suggestions if exclude_from_search is set to false.
Additional context
Gutenberg 6.5
Additional idea
Another idea is to show the CPT name and then the title in the suggested results. For example "Page - Testimonials" and "Testimonial - Testimonial Demo" would help prevent such issues.
The text was updated successfully, but these errors were encountered:
shaiherman
changed the title
Suggestions do not honor exclude_from_search set to false
Suggestions do not honor exclude_from_search set to true
Sep 26, 2019
exclude_from_search is for excluding post types on the site's search form on the frontend, it is not meant to exclude post types from the link suggestions in the editor.
I suppose you may want to link to a CPT on the front-end and not have it be searchable; this seems like a rare case as long as the link suggestion tool is used for public facing links.
I'm unaware of a better post type argument. show_in_rest is far worse for this need.
I can see three solutions:
A new post type argument - something like exclude_from_suggestions
Better labeling to avoid confusion (see "Additional Idea" in the original issue)
Provide a means of filtering the suggestions on the component level
These solutions should not be viewed as mutually exclusive.
exclude_from_search is for excluding post types on the site's search form on the frontend, it is not meant to exclude post types from the link suggestions in the editor.
Is there any way to exclude post types from the link suggestions in the editor?
Describe the bug
When creating a custom post type with show_in_rest => true and exclude_from_search => true, the search suggestion feature when looking up links, such as the anchor button in the toolbar or the core/button's block link input shows those custom post types.
show_in_rest => false should not be used as a means of filtering suggestions as its reach is far broader. For example my CPT's are using custom blocks and need this option be true.
Why does this matter?
These are links that will be public facing, and as such should not be an option for editors. If so, they will culminate in 404 pages.
Suggestions will return Title's of CPT's and as such many folks will use identical or similar titles in their custom post types, causing confusion on which suggestion is the right one.
To reproduce
Expected behavior
You should not see Demo Testimonial in any search suggestions if exclude_from_search is set to false.
Additional context
Gutenberg 6.5
Additional idea
Another idea is to show the CPT name and then the title in the suggested results. For example "Page - Testimonials" and "Testimonial - Testimonial Demo" would help prevent such issues.
The text was updated successfully, but these errors were encountered: