Welcome! We’re excited that you’re interested in contributing to our WordPress theme. By contributing, you can help improve the functionality, fix bugs, and add new features to the theme. This document will guide you through the process of contributing.
Note Please only install the Beta theme on a test site. By their nature, Beta releases could be unstable and should not be used on a site where your data is important.
First Interaction: Read our welcome and first interaction file if this is your first time contributing.
To get started with contributing to our WordPress theme, follow these steps:
composer build this will check and format your code, it will also run basic unit tests and static analysis.Brisko requires the following development dependencies:
To start development using all the tools, you need to install the necessary Node.js and Composer dependencies :
$ composer install
$ npm install
If you encounter any issues with the theme, please report them using GitHub Issues. When reporting an issue, provide as much information as possible, including:
If you’d like to fix a bug in the theme, follow these steps:
If you have a feature request for the theme, please follow these steps:
When you’re ready to submit your changes, please follow these steps:
To maintain consistency and readability of the codebase, please adhere to the following coding guidelines:
final.else, else makes code less readable, replace using early returns or using a ternary.We adopted a coding standard for all the usual reasons:
Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly. If you ship your source code as a product, you need to make sure it is as well packaged and clean as any other product you create. https://en.wikipedia.org/wiki/Coding_conventions.
Coding standards, Coding best practices are a set of informal rules that the software development community employs to help improve software quality. https://en.wikipedia.org/wiki/Coding_best_practices
Note Code styling doesn’t need to be perfect. We can automatically apply style fix with
composer codefixandcomposer wpcs-fix(you should probably do this locally before you submit pull request).
Code review is an important and widely adopted practice, and there are numerous how-to guides that teach best practices. They’re all valuable, but what’s most important, I think, is the mindset. If a team shares a positive approach to code reviews, a lot of the benefits of best practice automatically apply. It fundamentally changes how you experience code review, and its effectiveness. The Code Review Mindset
We use Conventional Commits, this helps with releases automation and CHANGELOG.
Release Please assumes you are using Conventional Commit messages. In general the pattern mostly looks like this:
type(scope?): subject #scope is optional; multiple scopes are supported (current delimiter options: "/", "\" and ",")
Real world examples can look like this:
chore: run tests on travis ci
fix(server): send cors headers
feat(blog): add comment section
Common types according to commitlint-config-conventional (based on the Angular convention) can be:
Testing is an important aspect of maintaining the quality of the theme. When making changes, please ensure that:
During your tests, we encourage you to open your browser’s Development Tools and keep the Console open, checking for any errors in the Console and the Network tabs.
To open the Console in Chrome or Firefox, you can press CMD+Alt+i in macOS or F12 in Windows. You can find out more here.
We would also recommend that you check your site’s debug.log as you test.
To make sure errors are logged on your site, you can add the following to your site’s wp-config.php file:
define( 'WP_DEBUG', true );
if ( WP_DEBUG ) {
@error_reporting( E_ALL );
@ini_set( 'log_errors', true );
@ini_set( 'log_errors_max_len', '0' );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'CONCATENATE_SCRIPTS', false );
define( 'SAVEQUERIES', true );
}
Your wp-config.php file may already include a line that says define('WP_DEBUG', false);. You can remove it, and replace it by the code above.
Add Documentation: Be sure to update the README.md where applicable.
Add Tests: Your patch will not be accepted if it does not have tests.
GPL Compatible: All materials contributed must be compatible with GNU General Public License.
Semantic Release: We try to follow Semantic Versioning Specification.
Create Feature Branches: Do not ask us to pull from master branch.
One Pull Request Per Feature: If you want to do more than one thing, send multiple pull requests.
Send Coherent History: Make sure each individual commit in your pull request is meaningful.
Squash Them: If you had to make multiple intermediate commits while developing, squash them before submitting.
We try to follow a very basic CI/CD pipeline workflow.
In software engineering, CI/CD or CICD is the combined practice of continuous integration and continuous delivery or continuous deployment. CI/CD bridges the gaps between development and operation activities and teams by enforcing automation in the building, testing, and deployment of applications. wikipedia
Continuous integration (CI) In software engineering, continuous integration is the practice of merging all developers’ working copies to a shared mainline several times a day. wikipedia
Continuous integration (CI) is a software practice that requires frequently committing code to a shared repository. Committing code more often detects errors sooner and reduces the amount of code a developer needs to debug when finding the source of an error. - GitHub
Stages:
Build: Compiling and testing the code (Continuous Integration)
Package: Producing an artifact from the code, ready to be deployed (Continuous Delivery)
Deploy: Deploying the application to a server automatically (Continuous Deployment)
Good documentation is essential for users and other developers to understand the theme. If you make changes that require updating the documentation, please ensure to do so. This includes:
When contributing to our project, please follow these guidelines to foster a positive and inclusive community:
Available CLI Composer Commands:
These are some of the CLI commands are available and tailored for WordPress theme development :
composer wpcorejohnpbloch/wordpress-core Composer package.composer wpcssrc and template-parts directories.composer wpcs-allwpcs, but includes additional directories for code style checking (src and template-parts).composer wpcs-lintsrc and template-parts directories.composer wpcs-lint-allwpcs-lint, but includes additional directories for code style checking (src and template-parts).composer wpcs-fixsrc and template-parts directories.composer buildcomposer testcomposer test-allcomposer test-integrationcomposer test-icomposer no-devcomposer phpstan:lintcomposer phpstancomposer psalm-installcomposer psalm-removecomposer psalmcomposer psalm-securecomposer psalm-info--show-info=true flag to provide additional information about issues.composer psalm-autofixcomposer setup-local-wpbin/install-wp-tests.sh script.composer setup-github-wpbin/install-wp-tests.sh script.composer lintcomposer codefixcomposer phpcs-fixcomposer php-cs-fixerThese CLI Composer commands help streamline the development process for the Brisko theme by providing automated tools for code quality, testing, and environment setup. You can use these commands to maintain a consistent and efficient development workflow.
We value and appreciate all contributions made to our WordPress theme. By contributing, you are helping to make the theme better for everyone. Thank you for your time and effort in making a positive impact!
By contributing to Brisko, you agree that your contributions will be licensed under its GNU General Public License.