Custom Post Type with non-public visibility cannot render preview in Breakdance

[Nicscott01]

What version of Breakdance are you using? 1.4.1-rc.2

Reproduction Steps

Create a Custom Post Type with

'public' => false,

and then try to make a template part (global block) for the single display (excerpt) of it. Breakdance won't load any posts (since they're not public).

My use case is a CPT without single pages (in this case, it's a testimonials CPT, and they get called from within pages). I don't want Yoast SEO to output these posts in the Sitemap.

Yes, I can tell Yoast to not output them and make them 'public' => true, but thought that BD should have a way to see these. Maybe there's a different argument for the CPT registration?

[thekendog]

Just ran into this issue. Can confirm it doesn't render the post in the global block builder. Really need this fixed.

[louisreingold]

tl;dr: This is intended behavior of Breakdance. I'm open to changing it. I need more information to make a decision.

My current understanding of non-public post types (public => false in register_post_type) is as follows:

Non-public post types are not supposed to be viewable by the public. They are not supposed to be viewable on the frontend of the site. They are used internally by WordPress for things like revisions, etc.

If you want the post type to be viewable on the frontend, it should be public.

Making them non-public as a way to trick your SEO plugin sounds like a misuse.

I am happy to re-open this issue and change my position above if there's real precedent for it.

Here's what I'd like to know:

Are there numerous mainstream WordPress plugins that disagree with my assessment above? i.e. do they use non-public-post types for stuff that is viewable by the public on the frontend? I don't mean things like a nav menu, I mean actual content.

Or is there another argument for why non-public post types should actually be viewable on the frontend? Can you provide some examples?

[louisreingold]

What are some legitimate use cases for making a post type non-public when you want it to be visible on the frontend?

(I don't find the "tricking my SEO plugin" a legitimate use case.)

Again, I am open to addressing this, but it needs to be addressed in an architecturally sound way, and in a way that make sense as part of the larger WP ecosystem.

[louisreingold]

@Hakira-Shymuy

[Hakira-Shymuy]

@louisreingold Actually from a frontend point of view, i do agree with you, i mean, there is no exact point in having a post type public false if we want it to show on the frontend, even if we are doing a internal frontend dashboard or page to someone we can just turn off the indexation for that sort of pages/posts

i found this situation as well but my use case is completely different, i was actually trying to create a custom post type to design Wordpress (dashboard widget) with breakdance, which i understood rapidly that does not work

public needs to be true and breakdance does not render the stuff in wp admin area (at least i did not research more about it)

from the plugins that i tried already, did not found any situation regarding the visibility of post type acf cpt UI metabox woo memberpress buddyboss edd fluentforms

[Nicscott01]

What if you have a post type for something like “staff”. They are output as part of a page “about.” You don’t want a slug /staff/Jon-doe to be public and render. And you don’t want to write a redirect. In that case I’d want it public => false because it’s really not public. It’s a way to keep things organized on the backend vs using repeater acf  fields. It’s also more flexible later on to use the post type.  -NicOn Aug 19, 2023, at 3:59 PM, Hakira-Shymuy @.***> wrote: @louisreingold Actually from a frontend point of view, i do agree with you, i mean, there is no exact point in having a post type public false if we want it to show on the frontend, even if we are doing a internal frontend dashboard or page to someone we can just turn off the indexation for that sort of pages/posts i found this situation as well but my use case is completely different, i was actually trying to create a custom post type to design Wordpress (dashboard widget) with breakdance, which i understood rapidly that does not work public needs to be true and breakdance does not render the stuff in wp admin area (at least i did not research more about it) from the plugins that i tried already, did not found any situation regarding the visibility of post type acf cpt UI metabox woo memberpress buddyboss edd fluentforms

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[thekendog]

@louisreingold I have a post type for team members. I don't want them to have links, but I do want to display them in a loop. I set public to true and public_queryable to false. I want them to show in the builder.

[Hakira-Shymuy]

@louisreingold I have a post type for team members. I don't want them to have links, but I do want to display them in a loop. I set public to true and public_queryable to false. I want them to show in the builder.

but you can tell to SEO plugin to don't index this stuff, so i really don't get the point of public true or false or you could actually use a repeater in the page itself, unless you may need to use those site wide, which you can set an options page anyway a post type is not a bad idea for flexibility, and i do understand that public true can facilitate, but the right way to go is to not index those you can even put archive to false if I'm not mistaken, will try and let you know

[Nicscott01]

@louisreingold I have a post type for team members. I don't want them to have links, but I do want to display them in a loop. I set public to true and public_queryable to false. I want them to show in the builder.

I recall fiddling with that setting and wanting them to show up in Breakdance but not on the front end. Maybe that's the argument BD should look at for the editor.

[thekendog]

Personally, I think BD should look at the public setting, not the publicly_queryable one. My initial response to this issue was not quite the same as @Nicscott01. For clarification, I have public set to true, but publicly_queryable to false.

[flowww-dev]

Sometimes we need hidden CPTs (like Global Blocks). But these hidden CPTs should also use Breakdance.

[louisreingold]

@thekendog Breakdance does look at the public setting right now. That's how it works.

[louisreingold]

I've revisited this and investigated pretty thoroughly.

Here's some background:

Breakdance renders data in a particular post by making HTTP requests to the URL of the post. This is, for many reasons, the best architecture and ensures the most accurate preview - i.e. what you see in the builder is what you get on the frontend.

For example:

• if there are shortcodes on the page that behave differently depending on where they are used (for example, a shortcode that displays the post date), the shortcode will render accurately when the render is triggered by an HTTP request to the same URL as the post on the frontend
• if there is dynamic data on the page (for example post type or post custom field), that data is pulled by calling the_title() or get_post_meta(...with the global $post) or similar. Those functions/globals work based on the URL of the request - i.e. if the request is for post A, it'll get the title and fields from post A... if it's from post B it'll return the values from post B. This is simply how WordPress works. It's not Breakdance specific.
• if there are code blocks on the page that call functions that depend on what post is being viewed, they won't work as expected - i.e. if we run that code in a request to the homepage but you're trying to edit a "team member" block... obviously the code won't behave the same as it would if you were viewing the team member block.

To see this in action, open up your Chrome Dev Tools and watch what happens when Breakdance renders dynamic data. Look at the URL used.

Trying to use hidden post types to store data sounds great in theory but we can't actually let you use Breakdance to edit them and preview the data... because without a URL... how do we preview the data?

Ultimately, if a post type isn't public... there is no URL... so we can't render it.

Potential hack: we could make the post type public while you are editing and then not public once you close the editor? That sounds like a really weird approach though... so it's best to let users do that manually.

Any other ideas?

Happen to re-open this if we can come up with a proper solution.

[louisreingold]

"I am trying to build a global block which will be used in a post loop. I’m not sure why Breakdance would need to make HTTP requests to the URL of the post to do this."

Well, how would you preview the data in the global block? When the global block is open... you'd have to hit some URL to preview the data.

There is certainly a valid use case for a post type that is only viewable in an archive (I needed that just a few days ago on breakdance.com) but not as a single.

We might be able to solve that use case with inline editing of global blocks.

[Nicscott01]

Hey @louisreingold : I think you hit the nail on the head with the particular use case many of us would want:

Show a "private" CPT on an archive page only. I do this for showing the members of a team, where the client doesn't want each one to click out to their own page.

Thank you for the perspective of how Breakdance does its thing; I think you guys have made the correct decision generally. However, this type of use case is common enough for me, at least. I like using CPT since it's separate rows in the database vs. a repeater field tied to an option or custom field of a post.

I wonder, could we add our own key => value to the registration of the CPT and have Breakdance look at that for an override (not sure if WP sanitizes the arguments list)? Or maybe use add_post_type_supports?