You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/CONTRIBUTING.md
+20-21Lines changed: 20 additions & 21 deletions
Original file line number
Diff line number
Diff line change
@@ -18,30 +18,27 @@ this kind of valuable input.
18
18
19
19
20
20
## Contributing with documentation
21
-
The directory `docs` has our plugins readme, changelog and handbook content.
21
+
The directory `docs` has any documentation that for the plugin which will be included in a release, such as the readme and changelog.
22
+
23
+
Plugin assets, like screenshots and similar are found in the `assets` directory.
22
24
23
25
The handbook lives on the WordPress.org Support Team's site, at https://make.wordpress.org/support/handbook/appendix/troubleshooting-using-the-health-check/.
24
-
The structure of this document will be replicated to the website, and allows us to educate users and
25
-
developers on the benefits of the plugin and how to use it.
26
26
27
27
28
28
## Contributing with code
29
29
30
-
When contributing through code, please make sure each feature is developed as a separate, forked, branch of `develop`.
31
-
32
-
The `master` branch of the repository is kept in a stable state, and should at any given time always be the most recent public release of the plugin.
30
+
When contributing through code, please make sure each feature is developed as a separate, forked, branch of `trunk`.
33
31
34
-
By splitting them up, we are able to make point releases without affecting already developed features intended for future major versions.
32
+
The `trunk` branch is the most recent beta of the plugin at any given time, stable releases of the plugin may be downloaded from the [GitHub releases page](https://github.com/WordPress/health-check/releases), or from the [WordPress.org plugins page](https://wordpress.org/plugins/health-check/).
35
33
36
34
You do not need a local development environment set up to make code changes, although it is useful
37
35
when making changes to JavaScript or SASS (CSS styles) as these are concatenated by our build tools,
38
36
and are only provided in raw form in the repository.
39
37
40
-
The project has 4 primary directories:
41
-
-`assets`, which holds JavaScript and SASS files.
42
-
-`bin`, which holds a shellscript to install the framework for running unit tests.
38
+
The project has 3 primary directories:
43
39
-`src`, which contains general source files for the project.
44
-
-`tests`, where unit tests are created.
40
+
-`tests`, where unit tests are created.
41
+
-`docs`, which houses the plugin readme, its changelog, and potentially any other documentation which may prove valuable.
45
42
46
43
Please do not change version numbers in when providing code changes, these are bumped by the project
47
44
maintainers when a new version is released, and any changes outside of this may lead to confusion.
@@ -50,30 +47,32 @@ maintainers when a new version is released, and any changes outside of this may
50
47
### Setting up a local environment
51
48
52
49
If you wish to set up a local environment for working with the project, start off by installing
[node](https://nodejs.org), [npm](https://www.npmjs.com) (Node Package Manager) or [yarn](https://yarnpkg.com/),
54
51
and [composer](https://getcomposer.org).
55
52
53
+
This project favors yarn, but you may substitute `yarn` for `npm` in the commands below during your local development if you are more comfortable doing so.
54
+
56
55
Once these are installed, you will want to open the command line in the project directory and
57
56
execute the following commands:
58
57
-`composer install` This will install composer dependencies, as defined in the `composer.json` file.
59
-
-`npm install` This will install node modules that we use, as defined in the `package.json` file.
58
+
-`yarn install` This will install node modules that we use, as defined in the `package.json` file.
59
+
-`yarn run build` creates the `health-check` directory with all files for a finished plugin.
60
60
61
61
#### Docker setup
62
-
To make it easier to test your code on the go, a [Docker](https://www.docker.com/) configuration is prepared for you.
63
-
Just run `docker-compose up` and wait for things to finish setting up. Once setup is complete, the following tools are available:
64
-
-`http://health-check.localhost` the main WordPress site install
65
-
-`http://health-check.localhost:8080` Adminer, a lightweight SQL editor
66
-
-`http://health-check.localhost:8025` MailHog, captures emails so you don't need ot worry about spamming inboxes during testing.
67
-
68
-
The Health Check plugin will also be automatically added to the test site, although deactivated initially. Running the `grunt watch` task during development also guarantees your test site is always showing your latest changes.
62
+
This project uses [wp-env](https://developer.wordpress.org/block-editor/packages/packages-env/) for it's Docker setup.
69
63
64
+
Once you have built the project, you may use the `yarn run wp-env start` command to test your code.
65
+
66
+
The `yarn run wp-env` command is a placeholder, and you may pass any command that `wp-env` supports to it.
67
+
68
+
For convenience sake, you may also run `yarn run watch` to automatically build any changes you make to the code during development.
69
+
70
70
### Submitting Pull Requests
71
71
72
72
Once you've got your development environment set up, and you are ready to push your code, here
73
73
are some items you should take note of
74
74
- Does the code follow the [WordPress Coding Standards](https://make.wordpress.org/core/handbook/best-practices/coding-standards/)?
75
75
- Did you include unit tests (if applicable)?
76
-
- Was your local copy recently pulled from `master`, so it's a clean patch?
77
76
78
77
When pushing, you should use a branch name that is short and describes what your code does.
79
78
For example, if your code adds a feature for showing colors, naming it `feature-show-colors` makes
0 commit comments