Wp-calypso: CPTs: enable Settings for turning on custom content types (was Settings > Writing in wp-admin)

[lancewillett]

This is enabled and working well for Jetpack sites, but for WP.com sites it doesn't show up in https://wordpress.com/settings/writing/example.wordpress.com

Jetpack example, settings screen:

WordPress.com example:

Previously in wp-admin, under Settings > Writing:

[lancewillett]

As a related note: do we expose anywhere in Calypso the "number of posts per page" for Testimonials and Portfolios?

That'll need to be built into Calypso somewhere — either in Settings or directly in the CPT list UI like pages #13569 .

[kathrynwp]

This is enabled and working well for Jetpack sites, but for WP.com sites it doesn't show up

The Portfolios Calypso dashboard menu item should automatically appear for any theme that declares support for that CPT – for example, a portfolio-driven theme or one that has testimonials built into the design.

Tested and confirmed with these steps:

1. Created a test site and selected Button 2.
2. Checked the Calypso dashboard - no Portfolios item.
3. Switched to a theme that declares portfolio support, _Illustratr_

Result: Calypso dashboard displayed Portfolios item, as expected:

This reflects how Portfolio functionality works in WP Admin - the item only appears in the menu if the theme declares support for it – otherwise you need to activate it manually. It's this manual switch that's missing in Calyspo on WordPress.com.

As a related note: do we expose anywhere in Calypso the "number of posts per page" for Testimonials and Portfolios?

I don't believe so, and this is definitely another gap that should be filled.

Any item with the WP Admin note on this page still has a gap:

https://en.support.wordpress.com/portfolios/

[lancewillett]

See also #13569 for the UI work to set number of blog posts — should use the same UI for toggles and number input.

[tyxla]

It appears we're talking about a different "Portfolio" here.

For Jetpack sites: The Custom Content Types settings enable the Custom Content Types Jetpack module, and the Testimonials and Portfolio are a couple of the custom content types (post types) that are supported by the Jetpack module itself. Other post types that are supported are Menu Items (supported by the Nova theme), or Comics for supported themes. Turning these on or off is essentially a module setting, and reflects the support for that post type in the theme.

WordPress.com sites on the other hand will allow managing any public and publicly queryable post type that is registered by the theme. These can be Portfolio or Testimonials, but can be any other custom post types that the theme registers. The current integration of post types in Calypso will allow any post types that are registered as public and "shown in the UI" to be managed, making them accessible from the sidebar. That said, I'm not seeing why one would want to disable any of them for their site. And even if they did, we currently don't support that in WordPress.com out of the box. You will notice that some themes have a "Show Portfolio Section" setting (for example Argent), but this is a theme feature and controls whether a portfolio section to be shown on the front page, and not whether to globally disable or enable the Portfolio post type.

Considering the above facts, why would we need to enable/disable post types for WordPress.com sites? Perhaps I'm missing something?

[kathrynwp]

That said, I'm not seeing why one would want to disable any of them for their site.

It's less that one would want to disable a CPT on WordPress.com -- it's that a user might want to enable a CPT in a theme that does not declare support for it. Without turning on the CPT setting, the Portfolios/Testimonials item will not appear their dashboard, and they will not be able to add a portfolio or testimonial _in a theme that does not specifically declare support._

These can be Portfolio or Testimonials, but can be any other custom post types that the theme registers.

As far as I'm aware, only the Portfolio and Testimonial CPTs can be used in any WordPress.com theme. Other CPTs like Comics or Food Menus cannot are theme-specific, and cannot be used outside of a certain set of themes.

[tyxla]

Thanks for clarifying @kathrynwp. But still, why would a user want to enable a CPT in a theme that does not declare a support for it? This should not be allowed IMO. If the theme does not support a custom post type, then that post type shouldn't be available for it, right?

[kathrynwp]

Ah, because we have portfolio and testimonial shortcodes that allow those specific CPTs to be used in any theme. Users love them! It gives them a ton of flexibility. :)

[tyxla]

That make sense, thanks for bearing with me on this one.

[tyxla]

We can easily adapt the current content types card to work for WordPress.com sites, but there's an oddity with the post types endpoint that I've noticed. We'll have to fix that one before we implement this card for WordPress.com sites.

A post type will always be returned by the endpoint if it's supported by the theme, even if we disable the jetpack_portfolio option. The opposite case (if a post type is not supported by the theme, and we enable the option) works as expected, returning the post type properly.

/cc @aduth @nylen as they appear to have worked on that endpoint

[aduth]

This may be a regression of #11096? Previously we'd always show the inputs, with the following message for themes which define support:

Your theme supports Testimonials

https://github.com/Automattic/wp-calypso/pull/11096/files#diff-43c263c2a487e27b501d84f2488024f9L139

A post type will always be returned by the endpoint if it's supported by the theme, even if we disable the jetpack_portfolio option.

If I recall correctly, when a theme declares support for the post type, there is no effect in trying to disable the site option. It seems to be intentionally an "or" behavior: either the theme defines support, _or_ the site option is enabled:

https://github.com/Automattic/jetpack/blob/fac8bcb/modules/custom-post-types/portfolios.php#L154

Therefore we'd previously _show_ the inputs, but disable them, since changing them would have no effect and mislead the user.

https://github.com/Automattic/wp-calypso/pull/11096/files#diff-43c263c2a487e27b501d84f2488024f9L87

[tyxla]

Thanks for clarifying @aduth, that makes complete sense!

@rickybanister can you please chime in and provide a mockup of how we should handle that case (when the theme provides support for a post type so it can't really be disabled)? Should we display a "Your theme supports %postType%" somewhere? Should we disable the post type toggle when that post type is supported by the theme? Currently we don't account for theme post type support in that card.

[rickybanister]

@tyxla I think we can perhaps continue to show toggles for .com sites—bare with me.

If a theme supports a custom content type, but you don't want to use it we can still provide the toggle. The toggle would hide the 'Portfolios' item from the sidebar and hide that content type from the editor, no?

Or is the issue when someone already has created a custom post we don't want to allow them to disable the feature at that point?

I'd prefer us to either show the toggle like I mentioned above, or just remove the toggle and swap it for the green checkmark like we've done for stats (since they are always on). Does that work?

[lancewillett]

While we're working on this — I just want to note we should also bring in "posts per page" count for CPTs, something you can only change in wp-admin right now.

So both toggle on/off (or visual indication that theme supports it with checkmark — love that idea) — and number of posts to display on index view. Both for parity with wp-admin and to make sure it's super clear to people using these features how to get the most out of it.

[rickybanister]

Makes sense @lancewillett—does that apply to all CPTs? Should we pop in an inline posts per page interface like this:

Or did you mean something else? Or did you only mean for custom-custom post types, not the jetpack ones?

[lancewillett]

That looks right! This is specifically for Jetpack CPTs "Testimonials" and "Portfolios" to start with (can expand later, or allow plugins/themes to add their own settings as needed).

[rickybanister]

Great! @tyxla does that work for you?

Hacking the inspector is my best friend :)

[tyxla]

The toggle would hide the 'Portfolios' item from the sidebar and hide that content type from the editor, no?

Nope, it will not. If post type support is enabled for a theme, that post type will be shown in the sidebar, regardless of whether that post type toggle is enabled or not.

I'd prefer us to either show the toggle like I mentioned above, or just remove the toggle and swap it for the green checkmark like we've done for stats (since they are always on). Does that work?

Yes, this will work :+1: We can do that if the theme declares support for a post type, because in that case the toggle will do nothing.

Also, thanks for the mockup with the number of posts. Will play with that as soon as I can.

[lancewillett]

Thanks for working on this @tyxla and @rickybanister — and for your broader work to improve all the settings screens (a massive project in itself).

If these CPT settings end up in Settings > Writing — it might be logical to implement the posts-per-page here in the same way, same UI components. See: https://github.com/Automattic/wp-calypso/issues/13868

That way end users don't have to hunt around to find the various settings, something that @kathrynwp has brought up as a confusing aspect of how it works in wp-admin now.

See also https://github.com/Automattic/wp-calypso/issues/3900 for previous discussion. Because we're not porting Settings > Reading over as-is from wp-admin, the various settings will be implemented in different places.

After we get settings in — let's loop in with Happiness Engineers also — both so they can update documentation and screenshots, and to validate that everything makes sense to them based on user feedback.

[rickybanister]

Ah, so perhaps we show the 'Custom Content Types' card/settings block to all users (WordPress.com and Jetpack sites) and remove the 'Custom' bit from the header. If we then add in 'Blog Posts' we can display the posts-per-page setting right there.

We don't need to include the checkmark, we can just outdent any content type that is 'on-by-default' and does not require a toggle.

Something like this:

That solution will mitigate the need entirely for #13868 and #13718

[kathrynwp]

This looks great, @rickybanister! Love the idea of keeping them all together, and I like the references to the shortcode for each item.

Let's add a number field for Testimonials & Portfolios too. That's another piece that's currently only in WP Admin that needs to be migrated to Calypso.

[rickybanister]

@kathrynwp yes, that was already covered in my comment above there—the updated design was simply to mitigate the need for that other issue/PR. All the active or always-on post types will have a per-page setting.

I'm a little confused why anyone would want a different setting for different post type, but I suppose it's worth being 1:1 with core.

[kathrynwp]

@rickybanister

the updated design was simply to mitigate the need for that other issue/PR.

Great, sorry for my confusion on that.

I'm a little confused why anyone would want a different setting for different post type, but I suppose it's worth being 1:1 with core.

I've seen many very good reasons why users want to control the settings for each post type separately and I agree we should keep that ability in Calypso. For example, a user's site has a portfolio grid design that looks best with rows of three, so they want the portfolio page set to 6 portfolio posts per page, but they have 10 testimonials and want those all displayed on one page, without pagination.

[tyxla]

I've addressed #13868 in #13916.

Those two issues contradict each other in terms of where the "posts per page" for blog posts are displayed, so it would be nice to decide which way to go. I'm basically fine with both, although I'd expect the "Custom content types" to be separate from the blog posts settings (even if we rename the heading).

[rickybanister]

@kathrynwp that makes sense.

[rickybanister]

@tyxla Yes, as per our discussion this morning, we will merge #13916 as soon as we can and afterward implement the solution I suggested in this issue so that all posts-per-page settings are consolidated together under a 'content types' block.

[tyxla]

I've started #14572, which enables the Custom Content Types for WordPress.com sites.

[tyxla]

Also, I've started #14574, which hides the post type toggles for post types that are already supported by the active theme.

[tyxla]

Even when the above 2 PRs land, there will be an issue where the user activates/deactivates a post type that's not supported by the active theme, but that change not be immediately reflected in the sites sidebar. I've opened #14576 to tackle this issue and complete the circle.

[tyxla]

I've opened #14718, which implements fields for controlling posts per page for Testimonials and Portfolio:

[kathrynwp]

Thanks @tyxla! Could we remove the parentheses so we don't have two sets of brackets and possibly confuse users who may copy-paste out both?

So just [testimonials] and [portfolios} would be my suggestion.

[tyxla]

@kathrynwp sure thing, but we're already altering the copy there, see #14574.

[kathrynwp]

@tyxla Lovely, I see the parentheses were already removed. 👍

[rickybanister]

Looks great @tyxla

[tyxla]

I've closed #14574 as it'll need an alternative solution, and I've opened a couple of new issues so we don't lose track of anything that's discussed in this giga-issue 😉

• CPTs: Move Posts Per Page field to Custom Content Types #14910
• CPTs: Disable a post type's toggle if it's supported by the theme #14912

[tyxla]

Closing this one in favor of the recently opened issues. Feel free to open new issues in the Calypso Settings: Bugs and Tweaks (m1) milestone if you feel we're missing anything. Thanks everyone for the discussion! 🙇

[tyxla]

16281 suggests moving the Posts Per Page field to the Custom Content Types card.