Feat/matchbox cpt

[unscripted]

Changes proposed in this pull request

This pull request adds Matchbox CPT, a must-use plugin for registering the custom post types.

Purpose

Reason for must-use plugin vs registering in the theme

According to WordPress documentation, It is considered better to register custom post types in a plugin rather than a theme for several reasons:

• Portability: If you register custom post types in a plugin, you can easily transfer them to a new theme if you decide to change the look of your website. This is because plugins are separate from the theme, so the custom post types will not be lost when you switch themes.
• Separation of concerns: Themes should be focused on presentation, while plugins should be focused on functionality. By registering custom post types in a plugin, you keep the functionality separate from the presentation, making it easier to maintain and update both.
• Reusability: If you create a custom post type in a plugin, you can reuse it on multiple websites without having to recreate it each time. This saves time and effort.
• Security: By registering custom post types in a plugin, you can ensure that only users with the appropriate permissions can access and modify them. This helps to prevent unauthorized access and data breaches.

Overall, registering custom post types in a plugin provides greater flexibility, portability, and security than registering them in a theme.

Autoloader

This code includes the file matchbox-cpt.php located in the mu-plugins directory. It is required because plugin directories inside the mu-plugin directory will not be loaded automatically by WordPress.

Matchbox CPT plugin

This code registers the plugin and its basic functionality.

Features:

• Registers custom post types by looping through PHP files located in the post-types directory of the plugin.
• Adds $exclude_post_types array variable to specify post types to exclude from registration.
• The code has been documented with PHPDoc comments for clarity and ease of understanding.

FAQs post type

This code registers a custom post type for Frequently Asked Questions (FAQs) along with a Categories taxonomy for the FAQs post type. The custom post type allows users to organize and manage FAQs.

Features:

• Set the labels for FAQs post type to define names, slug, and other terms related to the FAQs.
• Set the arguments for FAQs post type, which includes the post type labels, descriptions, supports, taxonomies, menu icon, and rewrite rules.
• Register the custom post type "matchbox_faq" using the register_post_type() function.
• Set the labels for FAQs taxonomy, which includes the taxonomy names, singular name, menu name, search name, and add new item name.
• Register the categories taxonomy for the FAQs post type using the register_taxonomy() function.
• The code has been documented with PHPDoc comments for clarity and ease of understanding.

Pre-submit checklist

As the author of this pull request, I verify that:

• I have set the target branch to master.
• I have detailed the purpose of this Pull Request in a non-technical way.
• I have detailed how to test the changes in the Pull Request.
• I have detailed the functional tests required for approval.
• I have self-reviewed my code to ensure it is DRY and follows the team's coding standards.
• I have commented on my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• I have verified that my code does not introduce a debug warning in my local environment.
• I have verified that the functional tests work in my local environment.
• I have verified that all automated tests pass or have provided a detailed comment about why I submit with a failed pipeline.
• I have verified that any dependent changes have been merged and published in downstream commits.
• I have added a link to this Pull Request in the Asana task.
• I have moved the Asana task to "Ready for Functional Review".
• I have left a comment in Asana and GitHub tagging a team member with a request for `review.

Testing

How to test the changes in this pull request

Follow the steps below to test the changes in this PR.

1. Deploy this branch to the dev environment.
2. Navigate to...

Functional tests

As the functional tester for this pull request, I verify that:

• It [does something]
• it does not...
• As an admin, I can...
• As a user, I can...

Once testing is complete, notify the author of failed tests and move the task to "Kick back" in Asana. If all tests pass, move the task to "Ready for Code Review" in Asana and tag a team member for code review.

Code review

As the code reviewer for this pull request, I verify that:

• All automated tests have passed.
• The code is written (or documented) in a way that is easy to understand.
• The code is free of obvious errors.
• The code is free of obvious duplication.
• The code follows our coding standards.
• The code is sanitized or escaped appropriately for any SQL or XSS injection possibilities.

Once testing is complete, notify the author of any failed tests and move the task to "Kick back" in Asana or continue with the "merging" steps below.

Merging

As the individual merging this pull request, I verify that:

• All automated tests have passed.
• All functional tests have passed.
• All code review tests have passed.
• I have moved the task to "Ready to Deploy" in Asana and notified the pull request author.