[wp-hackers] Advice regarding Custom Post Types and Taxonomies
lists at lobaugh.net
Fri Aug 10 00:20:25 UTC 2012
Creating a Person post type is pointless because it will be a one to one
relationship with the User. It is quite easy to extend user profiles to
add additional fields. I have done so many times on project. I can share
code with you if you would like.
A new post will be created each year for PlayerHistory (unless you need
to track per game) to contain all the stats. You _could_ put that as
user meta called _Stats20XX if you wanted, but it would be difficult to
implement in a quick smooth manner. Because it should be one(User) to
many (PlayerHistory) it is better to keep it as a CPT. It also allows
you to take advantage of the autogenerated interface in wp-admin and
using tools such as GravityForms on the frontend if users want to login
and manage it.
On 8/9/12 5:04 PM, Mike Schinkel wrote:
> Hi Ben,
> I understand now. Roster = Team-Year.
> As for Users being Players, you *might* consider syncing Users with a Person custom post type (although there might be the same problem as with taxonomy and post type, but I don't think so.) Users are not well suited for the types of things I expect you will want to do with a player, in our experience.
> PlayerHistory: Ideally that would be meta associated with your posts relationship but that's yet more infrastructure that's not implemented in WordPress. You could model it with a post type and that's probably the best thing.
> Hope this helps.
> On Aug 9, 2012, at 7:52 PM, Ben Lobaugh wrote:
>> Mike I am really leaning towards multiple CPTs. Otto can smack me over the head if I am wrong here, but this is what I envision
>> - Team - Contains the team info (Name, Logo, Description, Location, etc)
>> - Roster - Each team creates a new roster each year. Rosters can be managed by the user with admin access to the team (Coach?). A roster will contain the Team ID as it's parent ID. Each Roster can store the ids of its players as meta data
>> - PlayerHistory- Contains historical info on the player (stats, team, etc). Each player is a user, store that user's id as meta data here
>> Built in:
>> - Users: Coaches and Players should be users. Filling out the user's profile page will add data to them. Their current team can be pulled from the Roster CPT. Coach historical info could also be stored in Roster and PlayerHistory possibly
>> ---- Putting coaches and players in here also allows the system to expand in the future and allows coaches and players to manage their own info. A plugin like Members could be used to setup roles and permissions.
>> 3rd Party Plugins:
>> - Posts 2 Posts - Could be used to relate the CPTs if you do not want to do it pragmatically
>> - Members - Possibly used in the future if you wish to expand the site to allow players and coaches login access
>> This system could expand pretty well into a full platform for managing teams, players, and stats. That may be too complex for your situation though ;)
>> On 8/9/12 4:16 PM, Mike Walsh wrote:
>>> On Thu, Aug 9, 2012 at 5:30 PM, Otto <otto at ottodestruct.com> wrote:
>>>> On Thu, Aug 9, 2012 at 12:18 PM, Mike Walsh <mpwalsh8 at gmail.com> wrote:
>>>> [ snipped ]
>>>> I think the real question is why would a "team" be a post type? A team
>>>> is essentially a group of players, wouldn't it make more sense as a
>>>> If you need to define a post type for the team in order to have stuff
>>>> about that team in the posts-table (totally understandable), then I'd
>>>> associate the team-post to the team-taxonomy in an implicit manner,
>>>> perhaps by sharing the postname and the term-slug. Essentially, the
>>>> players and the team would both have the same terms in the
>>> This exact question is exactly what I am trying to ascertain. In our
>>> situation, which I suspect is pretty typical, a team is more than a group
>>> of players which is why in my current implementation I defined the roster
>>> (which is absolutely a group of players) as a taxonomy and a team, which
>>> has information (e.g. a coach, a manager, a treasurer, a mailing address, a
>>> contact email, etc.) as custom post type.
>>> Where I am struggling, and right now I am leaning toward Posts2Posts, to
>>> connect players to teams, is how to connect everything together.
>>> Right now I have my Roster as a custom taxonomy and have created two terms
>>> - "2011-2012" and "2012-2013". I can go through the players and assign
>>> them to the rosters they are part of. Everything works great until I add a
>>> second team and this is where I am stuck.
>>> Here is a scenario: Player 1 is a member of Team A for 2011-2012 and
>>> member of Team B for 2012-2013. Player 2 is a member of Team B for both
>>> 2011-2012 and 2012-2013 Player 3 is only a member of Team A for 2012-2013.
>>> Both Team A and Team B had rosters for 2011-2012 and 2012-2013.
>>> I am not sure how I could uniquely identify the roster for Team A for
>>> 2011-2012. I would need to connect a player to a specific team roster
>>> which is why I started thinking that a hierarchical CPT might be a solution.
>>> Why would I have more than one team? Imagine a scenario where a club
>>> fields multiple teams in an age group. They may choose to play in two
>>> different leagues with some overlap between rosters. A pool of players can
>>> be assembled into multiple rosters depending on the need.
>>> Does what I am trying to do make sense? Maybe I should draw a picture of
>>> the relationship i am trying to construct.
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
More information about the wp-hackers