Custom post types, custom taxonomies, and custom fields

[roundhill]

It would be extremely useful if Wordpress for Android supported custom post types, custom taxonomies, and custom fields. I would like to formally request that the functionality be added.

[dllh]

I'd like to second this!

[bummytime]

Closing issue and migrating to new repo.

[rachelmcr]

Reopening this issue since wordpress-mobile/WordPress-Editor-Android#114 is in a deprecated repo. Noting that the issue in the other repo had 4 upvotes (direct requests and via app reviews).

[BigActual]

I'm all for this. Having texted with the programmers who manage development, I can share what I learned, that development for managing CPTs in an Ap is no small feat. It's complicated. However, I can also add that almost every developer I know is using CPTs. There a basic, standard part of the ecosystem and users would benefit dramatically from a serious effort here.

For record keeping this is a copy of the conversation from the #mobile Slack Channel:

bigactual [5:42 AM]
I'm having trouble finding information about how to deal with CPTs in the mobile apps. I've been looking at

• Support for Custom Post Types #7216
• Custom Post Types, Custom Taxonomies, & Custom Fields WordPress-iOS#500

Is there further documentation or opinions amongst the group here on how this should be addressed?

bigactual [5:50 AM]
Our issue is that end users who load the WordPress apps do not see or have the ability to edit data in CPTs but the expected behaviour is that CPTs will present themselves in mobile for editing and publishing.
Do we need to code CPTs in a special way or does the app need an enhancement to make CPTs accessible/editable on mobile devices?

jkmassel [11:02 AM]
Hi Steve – the app doesn’t currently support CPTs, but this is something that’s on our radar!

Thomas Bishop [12:31 PM]
@BigActual Would you care to share a little more detail around what those custom post types are, how they’re used, and what you’d hope/expect CPTs in the mobile apps to look like? It might help to understand the use case(s) and give us insight into what kinds of solutions might be appropriate

tobifjellner [12:32 PM]
... and I guess not all CPT's are equal... Perhaps would need to mark whether specific CPT's can be edited by a normal editor.

Thomas Bishop [12:37 PM]
That’s kinda what I’m wondering – CPTs can take many forms, so I’m curious about the use cases
Gutenberg also changes a lot of things in that arena

jkmassel [12:41 PM]
Sort of, but not really – as a for-instance, consider an event calendar. :gutenberg: solves the issue of “how do I display a list of events, or a single event in my page”, but from a “manage my database of events”, doesn’t help – that’s what CPTs are for still
no user will want to go into a post or page and edit their list of events in the context of a GB block, when they could just have “events” in the sidebar, and manage it like they do posts (edited)

Thomas Bishop [1:12 PM]
Ahh, I see what you’re saying @jkmassel. Using that calendar/event example, Gutenberg will be helpful in choosing how to display the calendar/events in some manner, but not the actual creation of those events – I agree, although I think there is some value in being able to manage within that. This could turn into a can-o-worms 🙂 (edited)
I haven’t been building sites for the last couple years, so your insight into if/where we can leverage standards in terms of CPTs holds more weight than mine. I’m coming from the curious designer perspective, and I see a lot of things changing w/ Gutenberg – some of which in phase 2 and some beyond

jkmassel [1:48 PM]
IMHO phase 2 won’t address that either, in terms of the WP-as-a-database-of-arbitrary-things-that-can-be-pulled-out-and-displayed

bigactual [2:03 PM]
We are a web dev shop. Our use case is pretty specific and repetitive. I think it's normal. I suspect we implement 5 or more CPTs on every install
We implement CPTs to organize content and to standardize/streamline data entry for clients/end users. Different data types have different fields and so we break groups of posts out into CPTs to put information in buckets that are logical for our clients and every client is different. We reuse some, but there's always that one guy who needs that one thing:laughing:.
Within those CPTs, we tailor the dashboard view so that the fields make sense. Let's say a CPT may be Staff and that the Data required for a complete Staff entry is title, description, featured image, address, phone number and a map of the facility. So we add and take away fields to present them logically and we may restrict access to the CPT based on role. We pre-format a template for the Staff CPT and style the content for presentation on all device types. This allows our client to just enter the data and forget about making it pretty or putting it in the right place.
This isn't a Gutenberg conversation, from my perspective. Gutenberg is a layout editor, not a data entry system.
What we would make use of is for mobile users to be able to access these CPTs and enter data into the fields we've created. The theme will take care of the display logic.
Does this make sense?

jkmassel [2:08 PM]
this is exactly my experience with CPTs as well, and is a great explanation! 🙂

bigactual [2:13 PM]
Thanks. 😅
I suppose @tobifjellner summarized an important point, above. Not all CPTs are created equal. Is the variety of field types the roadblock to making a useful interface? Or, is there something we can do within our work to make our CPTs mobile accessible?
interface dashboard editor view for CPTs

jkmassel [2:17 PM]
Custom fields are definitely the hard part, because their content differs greatly. Right now there’s no way at all to add them to mobile. I suspect we’d look at an opt-in system to accommodate mobile support, because IMHO there’s no way to reliably parse the contents of existing custom field entries.
but that all remains to be decided, obviously 🙂

Thomas Bishop [2:22 PM]

This isn’t a Gutenberg conversation, from my perspective. Gutenberg is a layout editor, not a data entry system.
I certainly agree Gutenberg as it exists today isn’t data entry system in the ways described, but considering Gutenberg will eventually apply far more broadly across any given install, I think it’s important to note that it could surface new ways of content entry and management

jkmassel [2:26 PM]
while it’d be possible for a theme/plugin dev to build that all into a gutenblock, I’ll be very surprised if that’s the direction any meaningful number of folks end up going – there’s a ton of inertia behind CPTs, and if that was the way GB were going, I think it’d mean the deprecation of CPTs, which I personally find to be very unlikely :man-shrugging:

^ all IMHO

Thomas Bishop [2:28 PM]
Agreed with all of that
All I’m saying is Gutenberg is going to shape a lot of the future of WP, so it’s important to consider how it affects CPTs or can be utilized

koke [3:49 AM]
the hard part of CPTs is that, as @BigActual mentions, it’s often more data entry than a different kind of post (that’s still similar to a post). It’s not just exposing what CPTs are available to the apps and showing them in the menu, but as soon as a CPT diverges from title/content into custom fields, we need to figure out how to show a UI to edit that. In theory we could have a text field for each custom field, but that’d be kind of like editing the database directly and probably not a good UX in many cases
Looking at https://www.advancedcustomfields.com as an example, we’d have to know how to build specific field editors, like limiting text to a number, email, image or file pickers, single/multiple selection choices,…
which is something that we’re trying to solve currently with Gutenberg for a different thing, and why Gutenberg might be relevant for a possible future of cross-platform CPTs, but there’s nothing like that in the roadmap as far as I know

[stale]

This issue has been marked as stale because:

• It has been inactive for the past year.
• It isn't in a project or a milestone.
• It hasn’t been labeled [Pri] Blocker, [Pri] High, or good first issue.

Please comment with an update if you believe this issue is still valid or if it can be closed. This issue will also be reviewed for validity and priority (cc @designsimply).

[BigActual]

bump