-
-
+
+
Welcome to the WooCommerce repository on GitHub. Here you can browse the source, look at open issues and keep track of development. We recommend all developers to follow the [WooCommerce development blog](https://woocommerce.wordpress.com/) to stay up to date about everything happening in the project. You can also [follow @DevelopWC](https://twitter.com/DevelopWC) on Twitter for the latest development updates.
@@ -34,4 +34,4 @@ This repository is not suitable for support. Please don't use our issue tracker
Support requests in issues on this repository will be closed on sight.
## Contributing to WooCommerce
-If you have a patch or have stumbled upon an issue with WooCommerce core, you can contribute this back to the code. Please read our [contributor guidelines](https://github.com/woocommerce/woocommerce/blob/master/.github/CONTRIBUTING.md) for more information how you can do this.
+If you have a patch or have stumbled upon an issue with WooCommerce core, you can contribute this back to the code. Please read our [contributor guidelines](https://github.com/woocommerce/woocommerce/blob/trunk/.github/CONTRIBUTING.md) for more information how you can do this.
diff --git a/bin/pre-push.sh b/bin/pre-push.sh
index 1ae76885dfc..8dc3a6e0f9b 100755
--- a/bin/pre-push.sh
+++ b/bin/pre-push.sh
@@ -1,26 +1,26 @@
#!/bin/sh
-PROTECTED_BRANCH="master"
+PROTECTED_BRANCH="trunk"
REMOTE_REF=$(echo "$HUSKY_GIT_STDIN" | cut -d " " -f 3)
if [ -n "$REMOTE_REF" ]; then
if [ "refs/heads/${PROTECTED_BRANCH}" = "$REMOTE_REF" ]; then
if [ "$TERM" = "dumb" ]; then
- >&2 echo "Sorry, you are unable to push to master using a GUI client! Please use git CLI."
+ >&2 echo "Sorry, you are unable to push to trunk using a GUI client! Please use git CLI."
exit 1
fi
- printf "%sYou're about to push to master, is that what you intended? [y/N]: %s" "$(tput setaf 3)" "$(tput sgr0)"
+ printf "%sYou're about to push to trunk, is that what you intended? [y/N]: %s" "$(tput setaf 3)" "$(tput sgr0)"
read -r PROCEED < /dev/tty
echo
if [ "$(echo "${PROCEED:-n}" | tr "[:upper:]" "[:lower:]")" = "y" ]; then
- echo "$(tput setaf 2)Brace yourself! Pushing to the master branch...$(tput sgr0)"
+ echo "$(tput setaf 2)Brace yourself! Pushing to the trunk branch...$(tput sgr0)"
echo
exit 0
fi
- echo "$(tput setaf 2)Push to master cancelled!$(tput sgr0)"
+ echo "$(tput setaf 2)Push to trunk cancelled!$(tput sgr0)"
echo
exit 1
fi
diff --git a/includes/README.md b/includes/README.md
index 7828c06822c..d7c1b794437 100644
--- a/includes/README.md
+++ b/includes/README.md
@@ -1,11 +1,11 @@
# WooCommerce `includes` files
-This directory contains WooCommerce legacy code. Ideally, the code in this folder should only get the minimum required changes for bug fixing, and any new code should go in [the `src` directory](https://github.com/woocommerce/woocommerce/tree/master/src/README.md) instead.
+This directory contains WooCommerce legacy code. Ideally, the code in this folder should only get the minimum required changes for bug fixing, and any new code should go in [the `src` directory](https://github.com/woocommerce/woocommerce/tree/trunk/src/README.md) instead.
## Interacting with the `src` folder
-Whenever you need to get an instance of a class from the `src` directory, please don't instantiate it directly, but instead use [the container](https://github.com/woocommerce/woocommerce/tree/master/src/README.md#the-container). To get an instance of the container itself you can use the `wc_get_container` function, for example:
+Whenever you need to get an instance of a class from the `src` directory, please don't instantiate it directly, but instead use [the container](https://github.com/woocommerce/woocommerce/tree/trunk/src/README.md#the-container). To get an instance of the container itself you can use the `wc_get_container` function, for example:
```php
$container = wc_get_container();
@@ -17,18 +17,18 @@ The exception to this rule might be data-only classes that could be created the
## Adding new actions and filters
-Please take a look at [the considerations for creation new hooks in `src` code](https://github.com/woocommerce/woocommerce/tree/master/src/README.md#defining-new-actions-and-filters), as they apply for `includes` code as well. The short version is that **new hooks should be introduced only if they provide a valuable extension point for plugins**, and not with the purpose of driving WooCommerce's internal logic.
+Please take a look at [the considerations for creation new hooks in `src` code](https://github.com/woocommerce/woocommerce/tree/trunk/src/README.md#defining-new-actions-and-filters), as they apply for `includes` code as well. The short version is that **new hooks should be introduced only if they provide a valuable extension point for plugins**, and not with the purpose of driving WooCommerce's internal logic.
## Writing unit tests
-[As it's the case for the `src` folder](https://github.com/woocommerce/woocommerce/tree/master/src/README.md#writing-unit-tests), writing unit tests is generally mandatory if you are a WooCommerce team member or a contributor from another Automattic team, and encouraged if you are an external contributor. Tests should cover any new code (although as mentioned, adding new code in `includes` should be rare) and any modifications to existing code.
+[As it's the case for the `src` folder](https://github.com/woocommerce/woocommerce/tree/trunk/src/README.md#writing-unit-tests), writing unit tests is generally mandatory if you are a WooCommerce team member or a contributor from another Automattic team, and encouraged if you are an external contributor. Tests should cover any new code (although as mentioned, adding new code in `includes` should be rare) and any modifications to existing code.
In order to make it easier to write unit tests, there are a couple of mechanisms in place that you can use:
-* [The code hacker](https://github.com/woocommerce/woocommerce/blob/master/tests/Tools/CodeHacking/README.md). Pros: you don't need to do any special changes to your code to make it testable. Cons: it's a hack, the tested code is being actually modified while being loaded by the PHP engine, so not an ideal solution.
+* [The code hacker](https://github.com/woocommerce/woocommerce/blob/trunk/tests/Tools/CodeHacking/README.md). Pros: you don't need to do any special changes to your code to make it testable. Cons: it's a hack, the tested code is being actually modified while being loaded by the PHP engine, so not an ideal solution.
-* [The legacy proxy and the related helper methods in WC_Unit_Test_case](https://github.com/woocommerce/woocommerce/tree/master/src/README.md#interacting-with-legacy-code): although these are intended in principle for writing tests for code in the `src` directory, they can be used for `includes` code as well. Pros: a clean approach, no hacks involved. Cons: you need to modify your code to use the proxy whenever you need to call a function or static method that makes the code difficult to test.
+* [The legacy proxy and the related helper methods in WC_Unit_Test_case](https://github.com/woocommerce/woocommerce/tree/trunk/src/README.md#interacting-with-legacy-code): although these are intended in principle for writing tests for code in the `src` directory, they can be used for `includes` code as well. Pros: a clean approach, no hacks involved. Cons: you need to modify your code to use the proxy whenever you need to call a function or static method that makes the code difficult to test.
It's up to you as a contributor to decide which mechanism to use in each case. Choose wisely.
diff --git a/includes/admin/class-wc-admin-help.php b/includes/admin/class-wc-admin-help.php
index e2654e8888f..c4531915bdf 100644
--- a/includes/admin/class-wc-admin-help.php
+++ b/includes/admin/class-wc-admin-help.php
@@ -65,7 +65,7 @@ class WC_Admin_Help {
'content' =>
'' . sprintf( __( 'If you find a bug within WooCommerce core you can create a ticket via Github issues. Ensure you read the contribution guide prior to submitting your report. To help us solve your issue, please be as descriptive as possible and include your system status report.', 'woocommerce' ), 'https://github.com/woocommerce/woocommerce/issues?state=open', 'https://github.com/woocommerce/woocommerce/blob/master/.github/CONTRIBUTING.md', admin_url( 'admin.php?page=wc-status' ) ) . '
' . + '' . sprintf( __( 'If you find a bug within WooCommerce core you can create a ticket via Github issues. Ensure you read the contribution guide prior to submitting your report. To help us solve your issue, please be as descriptive as possible and include your system status report.', 'woocommerce' ), 'https://github.com/woocommerce/woocommerce/issues?state=open', 'https://github.com/woocommerce/woocommerce/blob/trunk/.github/CONTRIBUTING.md', admin_url( 'admin.php?page=wc-status' ) ) . '
' . '' . __( 'Report a bug', 'woocommerce' ) . ' ' . __( 'System status', 'woocommerce' ) . '
', ) diff --git a/readme.txt b/readme.txt index c33be3671c4..eab39a7fb1f 100644 --- a/readme.txt +++ b/readme.txt @@ -162,4 +162,4 @@ WooCommerce comes with some sample data you can use to see how products look; im = 5.2.0 2021-04-xx = -[See changelog for all versions](https://raw.githubusercontent.com/woocommerce/woocommerce/master/changelog.txt). +[See changelog for all versions](https://raw.githubusercontent.com/woocommerce/woocommerce/trunk/changelog.txt). diff --git a/src/Internal/README.md b/src/Internal/README.md index e8e8efae15d..bbd4bd6855d 100644 --- a/src/Internal/README.md +++ b/src/Internal/README.md @@ -2,4 +2,4 @@ All the code in this directory (and hence in the `Automattic\WooCommerce\Internal` namespace) is internal WooCommerce infrastructure code and not intended to be used by plugins. The important thing that this implies is that **backwards compatibility of the public surface for classes in this namespace is not guaranteed in future releases of WooCommerce**. -Therefore **plugin developers should never use classes in this namespace directly in their code**. See [the README file for the src folder](https://github.com/woocommerce/woocommerce/blob/master/src/README.md#the-internal-namespace) for more detailed guidance. +Therefore **plugin developers should never use classes in this namespace directly in their code**. See [the README file for the src folder](https://github.com/woocommerce/woocommerce/blob/trunk/src/README.md#the-internal-namespace) for more detailed guidance. diff --git a/src/README.md b/src/README.md index 59dc9077859..c22c1b7ecfd 100644 --- a/src/README.md +++ b/src/README.md @@ -26,7 +26,7 @@ This directory is home to new WooCommerce class files under the `Automattic\WooCommerce` namespace using [PSR-4](https://www.php-fig.org/psr/psr-4/) file naming. This is to take full advantage of autoloading. -Ideally, all the new code for WooCommerce should consist of classes following the PSR-4 naming and living in this directory, and the code in [the `includes` directory](https://github.com/woocommerce/woocommerce/tree/master/includes/README.md) should receive the minimum amount of changes required for bug fixing. This will not always be possible but that should be the rule of thumb. +Ideally, all the new code for WooCommerce should consist of classes following the PSR-4 naming and living in this directory, and the code in [the `includes` directory](https://github.com/woocommerce/woocommerce/tree/trunk/includes/README.md) should receive the minimum amount of changes required for bug fixing. This will not always be possible but that should be the rule of thumb. A [PSR-11](https://www.php-fig.org/psr/psr-11/) container is in place for registering and resolving the classes in this directory by using the [dependency injection](https://en.wikipedia.org/wiki/Dependency_injection) pattern. There are tools in place to interact with legacy code (and code outside the `src`directory in general) in a way that makes it easy to write unit tests. @@ -281,7 +281,7 @@ What this implies for you as developer depends on what type of contribution are Here by "legacy code" we refer mainly to the old WooCommerce code in the `includes` directory, but the mechanisms described in this section are useful for dealing with any code outside the `src` directory. -The code in the `src` directory can for sure interact directly with legacy code. A function needs to be called? Call it. You need an instance of an object? Instantiate it. The problem is that this makes the code difficult to test: it's not easy to mock functions (unless you use [hacks](https://github.com/woocommerce/woocommerce/blob/master/tests/Tools/CodeHacking/README.md), or objects that are instantiated directly with `new` or whose instance is retrieved via a `TheClass::instance()` method). +The code in the `src` directory can for sure interact directly with legacy code. A function needs to be called? Call it. You need an instance of an object? Instantiate it. The problem is that this makes the code difficult to test: it's not easy to mock functions (unless you use [hacks](https://github.com/woocommerce/woocommerce/blob/trunk/tests/Tools/CodeHacking/README.md), or objects that are instantiated directly with `new` or whose instance is retrieved via a `TheClass::instance()` method). But we want the WooCommerce code base (and especially the code in `src`) to be well covered by unit tests, and so there are mechanisms in place to interact with legacy code while keeping the code testable. @@ -355,7 +355,7 @@ $this->register_legacy_proxy_function_mocks( Of course, for the cases where no mocks are defined `MockableLegacyProxy` works the same way as `LegacyProxy`. -Please see [the code of the MockableLegacyProxy class](https://github.com/woocommerce/woocommerce/blob/master/tests/Tools/DependencyManagement/MockableLegacyProxy.php) and [its unit tests](https://github.com/woocommerce/woocommerce/blob/master/tests/php/src/Proxies/MockableLegacyProxyTest.php) for more detailed usage instructions and examples. +Please see [the code of the MockableLegacyProxy class](https://github.com/woocommerce/woocommerce/blob/trunk/tests/Tools/DependencyManagement/MockableLegacyProxy.php) and [its unit tests](https://github.com/woocommerce/woocommerce/blob/trunk/tests/php/src/Proxies/MockableLegacyProxyTest.php) for more detailed usage instructions and examples. ### But how does `get_instance_of` work? @@ -363,7 +363,7 @@ We use a container to resolve instances of classes in the `src` directory, but h This is a mostly ad-hoc process. When a class has a special way to be instantiated or retrieved (e.g. a static `instance` method), then that is used; otherwise the method fallbacks to simply creating a new instance of the class using `new`. -This means that the `get_instance_of` method will most likely need to evolve over time to cover additional special cases. Take a look at the method code in [LegacyProxy](https://github.com/woocommerce/woocommerce/blob/master/src/Proxies/LegacyProxy.php) for details on how to properly make changes to the method. +This means that the `get_instance_of` method will most likely need to evolve over time to cover additional special cases. Take a look at the method code in [LegacyProxy](https://github.com/woocommerce/woocommerce/blob/trunk/src/Proxies/LegacyProxy.php) for details on how to properly make changes to the method. ### Creating specialized proxies diff --git a/tests/README.md b/tests/README.md index 5a2b453731d..e15a9485241 100644 --- a/tests/README.md +++ b/tests/README.md @@ -1,6 +1,6 @@ # WooCommerce Tests -This document discusses unit tests. See [the e2e README](https://github.com/woocommerce/woocommerce/tree/master/tests/e2e) to learn how to setup testing environment for running e2e tests and run them. +This document discusses unit tests. See [the e2e README](https://github.com/woocommerce/woocommerce/tree/trunk/tests/e2e) to learn how to setup testing environment for running e2e tests and run them. ## Table of contents @@ -108,7 +108,7 @@ Each test file should correspond to an associated source file and be named accor * When testing functions: use one test file per functions group file, for example `wc-formatting-functions-test.php` for code in the `wc-formatting-functions.php` file. -See also [the guidelines for writing unit tests for `src` code](https://github.com/woocommerce/woocommerce/tree/master/src/README.md#writing-unit-tests) and [the guidelines for `includes` code](https://github.com/woocommerce/woocommerce/tree/master/includes/README.md#writing-unit-tests). +See also [the guidelines for writing unit tests for `src` code](https://github.com/woocommerce/woocommerce/tree/trunk/src/README.md#writing-unit-tests) and [the guidelines for `includes` code](https://github.com/woocommerce/woocommerce/tree/trunk/includes/README.md#writing-unit-tests). General guidelines for all the unit tests: diff --git a/tests/e2e/README.md b/tests/e2e/README.md index 5869e776b61..9a56a1e8641 100644 --- a/tests/e2e/README.md +++ b/tests/e2e/README.md @@ -101,7 +101,7 @@ Puppeteer will still automatically download Chromium when needed. - `cd` to the WooCommerce plugin folder -- `git checkout master` or checkout the branch where you need to run tests +- `git checkout trunk` or checkout the branch where you need to run tests - Run `nvm use` @@ -267,7 +267,7 @@ In the WooCommerce Core repository the tests are in `tests/e2e/core-tests/specs/ The following packages are used in write tests: - `@automattic/puppeteer-utils` - utilities and configuration for running puppeteer against WordPress. See details in the [package's repository](https://github.com/Automattic/puppeteer-utils). -- `@woocommerce/e2e-utils` - this package contains utilities to simplify writing e2e tests specific to WooCommmerce. See details in the [package's repository](https://github.com/woocommerce/woocommerce/tree/master/tests/e2e/utils). +- `@woocommerce/e2e-utils` - this package contains utilities to simplify writing e2e tests specific to WooCommmerce. See details in the [package's repository](https://github.com/woocommerce/woocommerce/tree/trunk/tests/e2e/utils). ### Creating test structure diff --git a/tests/e2e/api/package.json b/tests/e2e/api/package.json index 76ce5abae51..976f39c82e9 100644 --- a/tests/e2e/api/package.json +++ b/tests/e2e/api/package.json @@ -3,7 +3,7 @@ "version": "0.1.1", "author": "Automattic", "description": "A simple interface for interacting with a WooCommerce installation.", - "homepage": "https://github.com/woocommerce/woocommerce/tree/master/tests/e2e/api/README.md", + "homepage": "https://github.com/woocommerce/woocommerce/tree/trunk/tests/e2e/api/README.md", "repository": { "type": "git", "url": "https://github.com/woocommerce/woocommerce.git" diff --git a/tests/e2e/core-tests/README.md b/tests/e2e/core-tests/README.md index 5ab37b4757f..cb16278e222 100644 --- a/tests/e2e/core-tests/README.md +++ b/tests/e2e/core-tests/README.md @@ -16,7 +16,7 @@ This package contains the automated end-to-end tests for WooCommerce. ### Setting up the test environment -Follow [E2E setup instructions](https://github.com/woocommerce/woocommerce/blob/master/tests/e2e/README.md). +Follow [E2E setup instructions](https://github.com/woocommerce/woocommerce/blob/trunk/tests/e2e/README.md). ### Setting up core tests diff --git a/tests/e2e/core-tests/package.json b/tests/e2e/core-tests/package.json index 463f960069c..0789cc2146f 100644 --- a/tests/e2e/core-tests/package.json +++ b/tests/e2e/core-tests/package.json @@ -2,7 +2,7 @@ "name": "@woocommerce/e2e-core-tests", "version": "0.1.1", "description": "End-To-End (E2E) tests for WooCommerce", - "homepage": "https://github.com/woocommerce/woocommerce/tree/master/tests/e2e/core-tests/README.md", + "homepage": "https://github.com/woocommerce/woocommerce/tree/trunk/tests/e2e/core-tests/README.md", "repository": { "type": "git", "url": "https://github.com/woocommerce/woocommerce.git" diff --git a/tests/e2e/env/README.md b/tests/e2e/env/README.md index 32b786ec751..f9998325c85 100644 --- a/tests/e2e/env/README.md +++ b/tests/e2e/env/README.md @@ -121,9 +121,9 @@ Jest provides setup and teardown functions similar to PHPUnit. The default setup Depending on the project and testing scenario, the built in testing environment container might not be the best solution for testing. This could be local testing where there is already a testing container, a repository that isn't a plugin or theme and there are multiple folders mapped into the container, or similar. The `e2e-environment` container supports using either the built in container or an external container. See the the appropriate readme for details: -- [Built In Container](https://github.com/woocommerce/woocommerce/tree/master/tests/e2e/env/builtin.md) -- [External Container](https://github.com/woocommerce/woocommerce/tree/master/tests/e2e/env/external.md) +- [Built In Container](https://github.com/woocommerce/woocommerce/tree/trunk/tests/e2e/env/builtin.md) +- [External Container](https://github.com/woocommerce/woocommerce/tree/trunk/tests/e2e/env/external.md) ## Additional information -Refer to [`tests/e2e/core-tests`](https://github.com/woocommerce/woocommerce/tree/master/tests/e2e/core-tests) for some test examples, and [`tests/e2e`](https://github.com/woocommerce/woocommerce/tree/master/tests/e2e) for general information on e2e tests. +Refer to [`tests/e2e/core-tests`](https://github.com/woocommerce/woocommerce/tree/trunk/tests/e2e/core-tests) for some test examples, and [`tests/e2e`](https://github.com/woocommerce/woocommerce/tree/trunk/tests/e2e) for general information on e2e tests. diff --git a/tests/e2e/env/builtin.md b/tests/e2e/env/builtin.md index f6392ec8a41..e02293d876e 100644 --- a/tests/e2e/env/builtin.md +++ b/tests/e2e/env/builtin.md @@ -16,7 +16,7 @@ wp post create --post_type=page --post_status=publish --post_title='Ready' --pos ### Project Initialization -Each project will have its own begin test state and initialization script. For example, a project might start testing expecting that the [sample products](https://github.com/woocommerce/woocommerce/tree/master/sample-data) have already been imported. Below is the WP CLI equivalent of the built in initialization script for WooCommerce Core E2E testing: +Each project will have its own begin test state and initialization script. For example, a project might start testing expecting that the [sample products](https://github.com/woocommerce/woocommerce/tree/trunk/sample-data) have already been imported. Below is the WP CLI equivalent of the built in initialization script for WooCommerce Core E2E testing: ``` diff --git a/tests/e2e/env/external.md b/tests/e2e/env/external.md index 80efe995f84..45da1345f61 100644 --- a/tests/e2e/env/external.md +++ b/tests/e2e/env/external.md @@ -16,7 +16,7 @@ wp post create --post_type=page --post_status=publish --post_title='Ready' --pos ### Project Initialization -Each project will have its own begin test state and initialization script. For example, a project might start testing expecting that the [sample products](https://github.com/woocommerce/woocommerce/tree/master/sample-data) have already been imported. Below is the WP CLI equivalent initialization script for WooCommerce Core E2E testing: +Each project will have its own begin test state and initialization script. For example, a project might start testing expecting that the [sample products](https://github.com/woocommerce/woocommerce/tree/trunk/sample-data) have already been imported. Below is the WP CLI equivalent initialization script for WooCommerce Core E2E testing: ``` diff --git a/tests/e2e/env/package.json b/tests/e2e/env/package.json index e9136a75c09..92d3348cc2a 100644 --- a/tests/e2e/env/package.json +++ b/tests/e2e/env/package.json @@ -10,7 +10,7 @@ "e2e", "puppeteer" ], - "homepage": "https://github.com/woocommerce/woocommerce/tree/master/tests/e2e/env/README.md", + "homepage": "https://github.com/woocommerce/woocommerce/tree/trunk/tests/e2e/env/README.md", "bugs": { "url": "https://github.com/woocommerce/woocommerce/issues" }, diff --git a/tests/e2e/utils/package.json b/tests/e2e/utils/package.json index 941d8c84bc0..7564461a3f7 100644 --- a/tests/e2e/utils/package.json +++ b/tests/e2e/utils/package.json @@ -2,7 +2,7 @@ "name": "@woocommerce/e2e-utils", "version": "0.1.2", "description": "End-To-End (E2E) test utils for WooCommerce", - "homepage": "https://github.com/woocommerce/woocommerce/tree/master/tests/e2e-utils/README.md", + "homepage": "https://github.com/woocommerce/woocommerce/tree/trunk/tests/e2e-utils/README.md", "repository": { "type": "git", "url": "https://github.com/woocommerce/woocommerce.git"