Contributing
First, thank you for taking the time to contribute to PostTypes, you're amazing! 🎉 👏 🙌
All contributions are welcome and appreciated. It is recommended that you read through this document before making your first contribution.
The following instructions are recommended as guidelines and not strict rules. However, following this guide will make it easier for both you and the maintainers when working on the project.
There are 3 ways you can contribute to PostTypes.
PostTypes mission is to create advanced WordPress custom post types easily.
Its focus is on the creation of custom post types, specifically around the admin interface, providing methods to create advanced post tables, columns, filters and more.
It also makes it easy to create taxonomies and assign them to post types.
Although its focus is on the admin interface, PostTypes is not for custom fields. There are plenty of solutions for creating custom fields in WordPress. PostTypes has no intention of being one.
Please keep this in mind when contributing to the project.
If you would like to report a bug, feature request, documentation improvement or question please create an issue. Before creating a new issue please check it has not already been raised by searching issues on GitHub.
When creating an issue it is best to provide as much information as possible in order to help the discussion move quickly and efficiently.
There are 4 types of issues:
Bug reports highlight an error or unexpected behaviour when using the code. In order to resolve the issue, enough detail must be provided in order to recreate the problem so it can be investigated and fixed.
Tips on creating bug reports:
Provide as much detail about the problem.
Give steps to help reproduce the problem.
Code examples and error messages are useful.
Version numbers (PHP, PostTypes, WordPress) are useful.
Feature requests suggest an idea for an improvement or additional functionality. Feature requests should be raised before submitting a pull request. This provides an opportunity for discussion and help prevent unnecessary work from being carried out.
Tips on creating feature requests:
Provide a description of the change you want to make.
Highlight the problem it attempts to solve.
Offer examples of how it would be used.
Provide links to WordPress documentation where relevant.
Documentation improvements suggest ways to enhance the documentation. This could be anything from fixing spelling errors to adding new sections.
Tips on creating documentation improvements:
Provide links to the pages you're referring to.
Offer an explanation on how this is an improvement.
For general questions and support. This is also a catch-all for anything that doesn't fit in the categories above.
Tips on creating support questions:
Please check the documentation first for your answer.
Provide code examples if necessary.
Keep questions relevant to PostTypes.
Labels are used to help organise different types of issues. Labels are prefixed with their group, which currently are type and status. Maintainers will apply the correct labels to an issue when they are reviewed.
Label | Description |
Type: Bug | Bug reports and issues with unexpected behaviour |
Type: Feature | Feature requests and ideas |
Type: Docs | Improvements and fixes around documentation |
Type: Support | General support and questions |
Status: Discussion | An issue that needs discussion before it can be worked on. |
Status: Ready | An issue that is ready to be picked up. |
Status: In Progress | An issue that is currently being worked. |
Status: Review | An issue that is finished and ready to be reviewed and merged. |
Status: Complete | An issue that is finished and merged into master. |
This is not an exhaustive list. Labels may be changed and new ones created over time. For a complete list, see the GitHub repo.
Before submitting a Pull Request it is recommended you create an issue first. This provides an opportunity to open up a discussion before any work takes place.
Create a Fork of the main jjgrainger/PostTypes repository.
Clone your fork locally to your machine.
Create a branch with one of the relevant branch prefixes.
Commit work to your branch.
Push your branch to your fork on GitHub.
Create a pull request comparing your forks branch against the main repository's
master.
Tips on creating pull requests:
Reference issue numbers in your commits where applicable.
Commit little and often, smaller commits make it easier to review code.
Do not include issue numbers in the title of your pull request.
Please provide a description with your pull request with details about the change you are trying to make.
Please link to any issues the pull request is related.
Branch prefixes are used to help categorise the working branches by type.
Prefix | Description | Example |
| An attempt to fix a bug |
|
| A new feature being worked on |
|
| Documentation fix, addition or improvement |
|
| A release branch to create a new release. |
|
The release/ prefix is to be used by maintainers only.
The docs/ prefix is used alongside Gitbook where the docs are hosted. Branches with this prefix will be automatically generated and made available as a version on the documentation site. This provides an opportunity to preview changes and approve them before being merged.
PostTypes is open source and free to use. It was created to solve a problem while giving something back to the community. There are many ways to show your support, some ideas include:
Creating an issue and pull requests.
Staring the project on GitHub.
Saying "thank you" over on Twitter
Spread the word and let others know.