post-type-relationships with custom-post-types

You just need to add a relationship table to manage the relations, much how the term relationships table is used for taxonomies. Speaking of which, are you sure you really need so many custom post types? Could a taxonomy work instead? Several taxonomies?

And about 1-n relations, post types can be hierarchical, so there may not be a need for so many post types. Taxonomies can be hierarchical as well, so you should seriously consider taxonomies before committing to multiple post types.

Of course, I don’t know what you’re up to so I may be totally wrong. Just do your research and consider your data schema carefully. Better to get it right now than have to convert a bunch of data when you find you made the wrong choice down the line.

I think i may need both, taxonomies and custom post types.
What i want is to create lists of soccer-teams with their players and contests they’re competing in.

So i think for the relationship between Teams,Players and Contest i would nee custom post types because i need to add data to each like what position has the team in the league or how many goals did tha player score, or where was the player before he was with this team.

But i think there is other data where i could use taxonomy like the country a player or team belong to.

You can add post meta data to any post, so you don’t necessarily need separate post types for each type. You could distinguish teams from players simply by custom field, as one example. But if separate post types help you maintain organization, then by all means use them. Just don’t go crazy with post types, like a different one for every team ??

Give a lot of thought about what kind of queries you might run. The WP_Query class used to query posts is very powerful, yet it still has limitations. You can always run custom SQL queries directly through $wpdb methods, but most devs prefer to use WP_Query when possible.

I sort of made light of a custom relationship table. It can indeed be a powerful tool, but if you can find a way to avoid it you should. If you do need it, you’ll need to build your own interface to use it. WP_Query will not be of any use with a relationship table, all your queries will be SQL. Since taxonomies already use a relationship table, see if you can work with taxonomies to establish relationships.

Sports can be very heavy with various statistics. If you need to do a lot of queries using certain statistics, post meta may not be very efficient. It could make sense to offload heavily queried statistics to a custom table. But then again, this means a related user interface and raw SQL queries.

This sounds like a nice project, but it requires careful planning before you dive in with the coding and data collection. Have fun!

Since i’m new to WP i actually tried creating custom tables first because i thought that this would be the right way.

A couple days ago i read about custom post types, now i think this may be the better solution. However i have to learn about several things concerning post types.

For example on this page i read about the register_post_type method https://developer.www.ads-software.com/reference/functions/register_post_type/
Here are some things i’m not yet completely familiar with, like the attribute “public”. public=true describes visitors who are not logged in.
However there is no way to describe that the user has to be logged in and also to have one specific role.

Good thing i installed a plugin for this…

However what i don’t know is: How do i configure what page is shown if a user clicks a team in a search-result, or if posts from this types should be found at all?

The post type registration arguments are difficult to fully grasp. Very few people truly understand all of them, I’m certainly not one of them, but I’ll do my best ??

The ‘public’ argument doesn’t have to do with logged in users. It’s more of a shortcut argument for several other arguments ($publicly_queryable, $show_ui, etc.). If you set those individually, I don’t think ‘public’ does much by itself. If you do not set them individually, they inherit the ‘public’ value. Those other arguments control the visibility of post-like features to everyone, even admins.

If you want your CPT to behave like posts, set ‘public’ to true. Otherwise, it’s only used in the background by your code. There will not be any user interface or anything.

To control who can do things with the CPT – read, edit, delete, etc., use the ‘capability_type’ and ‘capabilities’ arguments. ‘capability_type’ is often the CPT slug. ‘capabilities’ is available to fine tune capabilities if the default constructs from ‘capability_type’ are not acceptable.

So if your ‘capability_type’ is ‘foo’, you’ll need to add read_foo, edit_foo, delete_foo, etc. to appropriate roles or users for anyone to be able to do anything with the CPT. If you do not supply any argument, the ‘post’ capabilities are inherited. If, say ‘read_foo’ is an undesirable capability, you can use ‘capabilities’ to map the CPT equivalent of ‘read_post’ (e.g. ‘read_foo’) to something else.

If registered with ‘exclude_from_search’ as false, you CPT should show up in search results, though in some cases some folks have had to explicitly add their CPT to the ‘post_type’ query var in ‘pre_get_posts’. It may be they didn’t register correctly. To exclude from search, just register with ‘exclude_from_search’ as true.

Search result links are configured by your theme’s search.php template. The links are typically to the post’s single page permalink. Thus your CPT search results will be the same.

Probably the best thing to do is register a test post type and play around with the various arguments and see how it behaves on your site when you alter one argument or another.