I am running multiple contests (one of which in a really large scale, all-year long) on my e-shop. They all have different rules, different structure so I've created a custom post type 'contest' for that. It suits me well, I've added some custom fields, that are common for all contests (images, date intervals etc.).
My question is, some of those contests might need their own 'subpages' in the future (e.g. full terms, tossing rounds, winners, etc.).
What is the best approach for this? Can I create a new page, add the content and somehow assign it to a specific entity of a custom post type?
I started thinking about this when I realized I want the SEO sitelinks to appear like this (search results):
The contest name | Mysite
• Terms • Winners
• Tossing rounds
The simple way would be to just create the pages, add "nofollow" to them, but that way only the main contest page would get indexed, which is not what I'm trying to achieve.
I am running multiple contests (one of which in a really large scale, all-year long) on my e-shop. They all have different rules, different structure so I've created a custom post type 'contest' for that. It suits me well, I've added some custom fields, that are common for all contests (images, date intervals etc.).
My question is, some of those contests might need their own 'subpages' in the future (e.g. full terms, tossing rounds, winners, etc.).
What is the best approach for this? Can I create a new page, add the content and somehow assign it to a specific entity of a custom post type?
I started thinking about this when I realized I want the SEO sitelinks to appear like this (search results):
The contest name | Mysite
• Terms • Winners
• Tossing rounds
The simple way would be to just create the pages, add "nofollow" to them, but that way only the main contest page would get indexed, which is not what I'm trying to achieve.
When you register post type with register_post_type
, you can set hierarchical
argument.
hierarchical -
(boolean) (optional)
Whether the post type is hierarchical (e.g. page).Allows Parent to be specified. The 'supports' parameter should contain 'page-attributes' to show the parent select box on the editor page.
Default:
false
Note: this parameter was intended for Pages. Be careful when choosing it for your custom post type - if you are planning to have very many entries (say - over 2-3 thousand), you will run into load time issues. With this parameter set to true WordPress will fetch all IDs of that particular post type on each administration page load for your post type. Servers with limited memory resources may also be challenged by this parameter being set to true.
As you can see, its default value is false, so the CPT is not hierarchical. Set it to true, and your CPT will be hierarchical.