Hi Raja,
You say there is around 15-20 pages per custom post. How are you managing the data now?
Using ACF?
Good day!
It sounds to me like you should be using the hierarchical page structure to manage sections instead of custom post types. The default posts are not hierarchical, but the default pages are. If you don’t want to use page post types, create a single CPT for courses. Each course could be a top level post and all sections are children of this post. How these are displayed can be managed in theme templates. For example, any request for a top level course post will list a table of contents linking to each child section. Each child section would display just like any other single post.
Hopefully you don’t have too much data yet that needs to be restructured. If there is a lot, some custom one time scripts can be developed to alter the data schema.
There is also a catch here we need to give each course management to a particular coordinator so a custom user management with specific access to the course content should be give . with hierarchical page structure is it possible to achieve a better user management.
Yes, but it’s a bit outside the normal WP user management. By default, a CPT can require unique roles and capabilities in order to interact with it. But all users with such roles can interact with any particular post type. Individual posts are not tied to specific users by default, but that can be made to happen with some custom work.
The admin post list tables use the same WP_Query class to populate the tables as the front end uses to display posts. You can alter what posts the query returns through the “pre_get_posts” action. A specific user could be assigned to each post in post meta (custom fields). The admin queries can then be altered to require that the only posts returned have the current user listed in post meta.
That alone will achieve the usability you desire, but it’s not secure from clever nefarious users. Someone who has the basic edit role for the CPT could construct an URL that opens the edit screen for a post where they are not the designated manager of that post. They have bypassed the WP_Query criteria. Additional hooks are needed to protect from this sort of attack.
It may be that all users who can edit their CPT are trusted enough to not attempt editing others posts even if it’s possible. A properly constrained user interface is all that’s needed. If so, maybe additional security is not warranted. If desired, security could be added to prevent the wrong user from saving any edits by hooking into one of the save posts hooks that fire before the post is updated.
It’s more difficult to prevent the edit screen from even loading for the wrong person using a crafted URL, but it’s possible. An early save posts hook is much easier. I don’t feel bad for a nefarious user who crafts an edit screen URL, then makes a bunch of changes they shouldn’t, only to find they cannot save their changes 🙂
@bcworkz Thanks , we have conclude to use heirarchial pages for the CPT.
