[Resolved] General advice on building a college course catalog

[Author]

Posts

[Jackie]

Hi there,

I'm seeking general advice about implementing a website for a client of mine. I've been tasked with building a course catalog for the continuing education arm of a school. The catalog is going to have three main templates in the following hierarchical order:

+ a catalog front page listing several departments
+ a departmental page listing several courses
+ a course detail page with information related to a given course

The catalog is published four times a year (fall, winter, spring, summer), and much of the content is recycled each season.

Can you recommend the best approach to structure my content? I've used Toolset Types once before on another website and am fairly familiar with it.

Thank you for your time!

Saul

[Nigel]

Hi Saul

Your description effectively describes what you need in terms of post relationships.

You create a catalog custom post type, a department post type, and a course post type.

You then create several post relationships:

- a many-to-many relationship between catalogs and departments (one catalog can describe several departments, and the departments can be added to multiple catalogs)
- a relationship between departments and courses. If courses can only belong to a specific department then it would be a one-to-many relationship (with department as parent, course as child), otherwise this would also be a many-to-many relationship

You can read about setting up post relationships here: https://toolset.com/documentation/post-relationships/

Once you create the relationships and some data, you can

- create a template to display catalog posts with all the required fields, description of that catalog etc.
- add a View to that template which displays links to department posts that are related to the catalog displayed with the template
- create a template for department posts
- add a View to link to courses that are associated with that department
- create a template for the individual courses

That should be largely covered by the above documentation link, but if you are missing anything, let me know.

[Jackie]

Nigel,

Thanks so much for your thoughtful response. It's extremely helpful. The only other post type that I need to create, which I omitted from my original message, is a Faculty post type. I already created this post type and a many-to-many relationship between it and the Course Detail post type (a faculty member can teach multiple courses, and a course can be taught by multiple faculty members).

It's clear your proposed configuration leans heavily on post relationships. My initial thought was to bypass post relationships and instead use custom categories (one for year, one for season, and one for department). Then I'd tag the departments and courses accordingly. Do you think this offers any distinct advantages or disadvantages over post relationships?

I also have some more specific questions about this proposed configuration. It's often the case that multiple catalogs are published concurrently. To be less hypothetical, let's say we're talking about a catalog for Spring 2019 and another catalog for Summer 2019.

+ If there are 8 courses in the Painting department in the Spring catalog but 4 courses in the Painting department in the Summer catalog, how do I configure the department to only show the correct set of courses for a given catalog? (This assumes each catalog page cannot point to the same Painting department page.)

+ It may be the case that in the Spring catalog and in the Summer catalog the same course is being offered but at a different time and location and start date and end date (and perhaps faculty). What do you propose I do to address this scenario, short of duplicating the course?

Thank you!

Saul

[Nigel]

OK, the rigid structure of catalog > department > courses doesn't make sense if, depending on the season, the courses provided by the department can vary, plus your final point about the same courses having different faculty etc. in different time frames.

You should remove the department from the relationships and connect courses to catalogs directly. (You might make departments a taxonomy, and each course is categorised by department.)

Your catalog - course relationship would be a many-to-many relationship, and you will add custom fields to that relationship (which involves using an intermediate post type which stores the custom fields).

Those custom fields can store content such as start date and end date and faculty.

So you can connect the "watercolour painting" course to both the spring 2019 and summer 2019 catalogs, and the connection to the spring catalog stores the relevant dates in the spring term, the connection to the summer catalog stores the relevant dates for the summer term etc.

The connection between catalog and course is the key which all the unique information for that instance then hangs off.

You will run into implementation specifics when it comes to displaying your content etc., but I think that is the fundamental requirement of how to structure your data.

[Jackie]

Nigel,

Thank you for articulating this revised proposal for the structure of our catalog. I think it will give us the flexibility that we need.

Regarding doing away with the department page, how do I then create and modify these pages? If we convert them to a taxonomy (let's say category rather than tag), can I add custom content such as a background image and textual description? If so, how?

Regarding the custom fields in the catalog-course relationship, I understand how to create custom fields for "regular" field types, but how do I create a connection to a faculty member (a custom post type)? (The Post Reference field wasn't available when I was creating the catalog-course relationship.)

Saul

[Nigel]

Hi Saul

I see the same limitation with the post reference field, which I wasn't expecting.

I checked with the developers and the intermediate post types created to store the relationship fields of a M2M relationship are not treated as normal post types, and are not permitted to be used for any other kind of relationship.

That's unfortunate for your use case, as we really wanted the intermediate posts between courses and catalogs to act as a kind of hub for the other content related to courses which can vary from catalog to catalog.

To answer your first question about the departments, yes, you can create custom archives for a department taxonomy.

Toolset only controls the content area of the page. If you make a custom archive at Toolset > WordPress Archives you have the loop section where you design the content of the posts shown at the archive, but before the wpv-loop tags after the wpv-layout-start shortcode you can insert fields of the taxonomy (you can add custom fields to taxonomies much like you can with posts).

There is a slight issue here in that the context for the Views shortcodes for outputting such fields is a taxonomy View (i.e. a View to show taxonomy terms, not posts), which can easily be resolved by using this custom shortcode instead:

/**
 * Register shortcode to output current taxonomy
 * for use on taxonomy archive page outside or inside loop
 * att['output'] string taxonomy | name (default) | slug | term_id | description | count | field (requres att['field'])
 * att['field'] string key
 */
add_shortcode('taxonomy', function ($atts = [], $content = null) {
 
    // provide defaults
    $atts = shortcode_atts(
        array(
            'output' => 'name',
            'field' => '',
        ),
        $atts
    );
    extract($atts);
 
    $return = '';
 
    global $wp_query;
    $obj = $wp_query->get_queried_object();
 
    if ($output != 'field') {
 
        $return = $obj->$output;
    } else {
        if (isset($field)) {
            $return = get_term_meta($obj->term_id, $field, true);
        }
    }
 
    return $return;
});

// EXAMPLES OF USE
[taxonomy output='taxonomy'] -- outputs the taxonomy slug
[taxonomy] -- outputs the term name (default)
[taxonomy output='count'] -- outputs the count of results
[taxonomy output='field' field='wpcf-colour'] -- outputs a 'colour' taxonomy custom field

Would it be possible to use faculty in a similar way?

[Jackie]

Nigel,

Thanks for your response and providing the PHP for the custom shortcode. I didn't understand everything you wrote and may have questions for you about it in the future.

Regarding connecting faculty to courses per your revised proposal, does your most recent response mean that I can't accomplish that task through Toolset Types? I'm just asking to confirm whether that's the case.

Now, a new complication has arisen. After further reflection, I realized that the information hierarchy that I originally provided to you had a large omission: what we call sections. A section is an instance of a course. For example, a course named Graphic Design 1 might be taught by Professor Smith on Monday nights (section 1 with 15 students) and it might be taught by Professor Jones on Wednesday nights (section 2 with 12 completely different students). The sections cover the same course material. Does this make sense?

The revised information hierarchy looks like this:

catalog > department > course > section > faculty

You can see an example of this on the web here:

hidden link

Observe two sections of a course named "Intro to Creative Fashion." It's offered on Monday night or Thursday night and taught by two different faculty.

Here is a description of the types of relationships between the objects in the information hierarchy:

+ many-to-many relationship between catalog and department. A catalog can have multiple departments, and a department can be associated with multiple catalogs.
+ many-to-many relationship between department and course. A department can have multiple courses, and a course can belong to multiple departments. (Some of the "departments" aren't actual academic departments but pseudo-departments like "popular classes.")
+ many-to-many relationship between course and faculty. A course can be taught by multiple faculty, and a faculty member can teach multiple courses. (Note: sections sort of change this, since courses aren't directly connected to faculty anymore. Perhaps this is a 1-to-many relationship between sections and faculty?)
+ one-to-many relationship between courses and sections. A course can have multiple sections, but a section can be associated with only one course.

And of course, we can't forget that the same course can be taught by different people in different catalogs, which are published simultaneously.

Based on this updated information, do you have any recommendations for how I should structure my content in WordPress? What custom post types do I need to make, what taxonomies should I create, and what post relationships need to be forged? (Do I need to think about creating my own database tables at this point to manage the relationships?)

Thanks for your thoughts, Nigel.

Saul

[Nigel]

OK, hopefully this would be the last iteration.

There needs to be one post which refers to the instance of a course being offered in a catalog.

In my last update I suggested you make a many-to-many relationship between courses and catalogs, with an intermediate post type under-the-hood used to store relationship fields for a particular connection, such as the faculty for the course which might be different in the spring catalog than in the summer catalog.

The problem is that the way Toolset relationships work you cannot add relationship fields to that intermediate post type, so you are restricted to using taxonomies, meaning you would need to use a taxonomy for faculty, a taxonomy for department etc., which doesn't really suit what you are aiming to do, because post types would be more suitable for them.

So, why not make this hub/anchor a post type in its own right, rather than an intermediate post type, which means that it can be freely used in Toolset relationships.

It is effectively an instance of a course in a catalog.

Maybe it even makes sense, then to use what you describe as series as this "anchor", because it seems like that is what your explanation of a series really describes.

So everything has a relationship with the series (or an "anchor" post if you prefer).

Instead of a lateral hierarchy, think of it as a circle with spokes and the series/anchor at the centre.

Each series/anchor pertains to some course, is taught by some faculty member, is available in one particular catalog etc.

It requires a certain amount of thought as to how to traverse these relationships. I suspect that you will need to use some of the API filters so that you can group and order the results as required, but we should be able to help you with that when the time comes, and in any case if this set-up doesn't suit you, then I think you are looking at a custom solution, yes.

[Jackie]

That all makes sense to me. Thanks for all of your guidance, Nigel! Time to get to work...

Saul

[Nigel]

Let me mark this as I think it is resolved.

If anything crops up in the next few days you can ask here, otherwise you can close this, and then when you have specific questions later on you can post new topics. (You are welcome to assign them to me.)

[Jackie]

Just doing due diligence to close this thread. Thank you!