search

justintadlock / content-type-standards

WordPress community-curated standards for common post types, taxonomies, and metadata.
302 stars 26 forks source link

Standards Tracking #13

Open justintadlock opened 10 years ago

justintadlock commented 10 years ago

This ticket is for tracking the various standards and whether they are completed. If you want to propose new content types, do so on Issue #1.

michaelbeil commented 10 years ago

Thanks for making this list @justintadlock!

dlature commented 8 years ago

Seems "Person" is the obvious choice for Staff/Team Member/Bios as Persons is the Parent and "Staff or Team" are taxonomy types for "Role" , and "Bios" is another taxonomy/type , as is "author" , which should be "book-author", "blog-author" to avoid conflict with WP. I'm sold on "Persons". I prefer it to the Book plugins understandable preference for "Authors" label (with term "xxxAuthor" named after thier plugin, like "mbtauthor" for books in "MyBookTable" plugin. ) I got to thinking about all this after starting to work on the best way to provide a "Book Reviews" app in wordpress. (so "Reviews" might also be broken down into book-review, video-review, event-review, book-series-review, article-review, etc. and each is tied to a "Person" with a role of "author/writer" of a Book-review) This gets "taxing" (pun intended) to think about. This makes it far less redundant to create new roles, so you dont have to re-create data that is repeated, like the basic personal info of people already in your database, and so certain roles have their own collection of taxonomies appropriate and useful to those roles.

AlchemyUnited commented 8 years ago

@justintadlock @dlature - Pardon me for having lost track a bit (read: maybe this was covered previously) but where does the arc of this effort stand on inheritance? That is, where does a parent end (e.g., person) and child begin (e.g., book author.)

Furthermore - note: this just jumped into my head so perhaps it's premature to share - but what of the idea what a person can be multiple child types. That is, for example, a person can be a book author AND a team member. Maybe I'm over-thinking it? Sorry?

dlature commented 8 years ago

@justintadlock @AlchemyUnited Yes, a person can indeed be a book author AND a team member and lots of other things, which are "roles", which can and should be tied to the data of those other things like Products/books and Event/Team members. The goal is to be able to use a "Person" to list as a "team-member" OR a "book-author" or a "blog-author" or "speaker" , and on and on, without having to recreate entries for each one.

dlature commented 8 years ago

@justintadlock @AlchemyUnited For example, a section for Books is going to want to pull from "persons" of the role "book-authors" and also "review-authors" and perhaps even "book-contributors" (for work as a writer of Preface or Forward, which would be a taxonomy to pull in , each of which would look for Persons of role "book-author" or "book-contributor" ( which has its own types like "Forward", "Preface", "illustrator", "editor")

AlchemyUnited commented 8 years ago

Maybe let's not talk about implementation (e.g., taxonomy) just yet?

I would think that each role has unique / special properties. That is, if a property is not part of the parent person then it must be something specific to that role. If, say, a flag property (e.g., ->author = true) is not present then that person can be presumed to not be an author.

I'm thinking about this in the abstract / object sense. And then, once the theory is firm we can, I would think, discuss some use cases and how those might work out in real life.

dlature commented 8 years ago

@justintadlock @AlchemyUnited the more use cases we can imagine suggests the kind of taxonomy that would be most data-effective (avoid as much redundancy as possible. To say "True or False" to author would require that yes or no choice to be included with every person, which is not what we want. Its more data-effective to join the person to a Product-type which is joined to a specific set of "Contributor-types" from which to choose for that person. It's a many-to-many that exists.

AlchemyUnited commented 8 years ago

re: "To say "True or False" to author would require that yes or no choice to be included with every person"

Not at all :) the flag would only be true, else no value. That is, to go to the DB you'd look for user_meta "book_author_flag" is true.

There's a person class. That class gets extended for each role. That child class, I would imagine, would / could also be an interface (?) to the DB. That is, it's the bottleneck where the actual implement happens, and at the same time it's a black box to the dev. I need authors. So I use the class to get them. Maybe? :)

Ultimately, for me, this is first a discussion about objects, properties, and inheritance. Once that's firm then I think implementation is the next discussion. That is, ultimately, this is not a WP issue. Sure, that's where it will end up, the rules, etc. should be - at least in theory - independent of the tool.

dlature commented 8 years ago

@justintadlock @AlchemyUnited What I am trying to get at is the way to get such a structure onto my Wordpress site using plugins or other resources that have already been tried and tested. I got part of the way to my Book Reviews functionality by having a Reviews Custom Post Type, and it is joined to my mbtbook CPT (created by MyBook Table plugin) , and that "join" is done via a plugin called CPT-onomy, which allows CPTs to be treated by other CPTs in a taxonomy relationship. I can now assign a review to a cbtbook and allow the book to "see" any review attached to it, so a link to Review(s) can be supplied for any book that has a review. But the process of doing this has caused me to want a more data friendly and effective way to do that for EVERYTHING, so that I am pulling into Products of "book" type, links to related reviews (which may well end up being a subset of particular types of "article".
But I am not talking extension to the WPdb at all. I am talking USING it and the tools provided (Custom Post Types and taxonomy relationships (including "category") to build a site rich with many-to-many relationships. No "black boxes". All WP functionality, aided by some plugins and their settings.