Use tracks & tags on session templates & schedule.

[joedolson]

When prospective speakers submit a talk, the submission includes a track term for the talk level & a set of tags for the relevant topics.

We should make use of this data in some way.

For the track (level), we should be labeling the session in the main schedule & on the session page. That should always be a single term.

For the tags, we should show only tags that appear on more than one talk, so that we're creating groups of related talks & not getting carried away with a ton of tags, since some talks will have checked off a dozen or more relevant topics.

Notes for implementation:

The taxonomy for tracks is 'wpcs_track'. The taxonomy for topics is 'wpcs_session_tag'

The conference schedule is in this repository, but the templates are being replaced in the theme, so this will require edits in both environments.

[alishanvr]

Hi @joedolson,

Thank you for assigning the task.

Before starting, I just want to make sure I am very clear about the following:

1. What coding standards should I adhere to while working on the project? Are there any specific WordPress or PHP coding conventions we're following?
2. Are there any specific workflow rules I need to follow? For example, do we have a branching strategy for version control, and are there any pre-commit checks I should be aware of?
3. Could you guide me on the correct process for fetching the latest version of the repository? Should I be cloning, forking, or pulling directly, and is there a specific branching model (e.g., Git Flow or feature branching) we're using?
4. How does the team handle code reviews? Is there a process for submitting pull requests, and who should I assign for review?
5. Is there a preferred setup for the local development environment? Do we have a standard configuration or any docker containers that I should use?
6. May I have access to the necessary resources to start working effectively? This includes SFTP/FTP details. So, I can clone the staging website to my local environment and start the task.
7. Given the focus on accessibility, are there specific accessibility guidelines or tools that I should use to ensure that our work meets the necessary standards?

---

Kind Regards, Ali

[joedolson]

Thanks, @alishanvr!

• We're using the WordPress PHPCS 3 code standard for PHP & have JS linting, as well. No unit tests at the moment.
• Branch and make a pull request; I'll merge changes after review. No specific model; but the main branch is protected, so you won't be able to commit directly to it.
• No standard local environment.
• I can provide SFTP; will email that.
• Accessibility will be part of the review process. Everything must be at least up to WCAG 2.2 AA, so that should be your guideline reference. No specific tooling suggested.

[alishanvr]

Thank you for taking time to answering my questions, @joedolson!

Please provide me SFTP access when you get time.

[joedolson]

Additional tasks:

• [x] Styling for main schedule track label.
• [x] Remove topics from main schedule
• [x] Limit topics shown to no more than four or five
• [x] Add display of these elements to the single template (in theme.)
• [ ] Design display of elements in single template.

[joedolson]

Commit to theme adds these to the template, but without any significant design.