Merge branch 'master' into 2.3-DevdocsPR4

Author: jeff-matthews

_includes/config/message-queue-consumers.md

@@ -31,12 +31,12 @@ Parameter | Value | Required? | Default Value
 `--max-messages=<value>` | The maximum number of messages to consume per invocation. If the number of queued messages is less than the specified max, the consumer polls for new messages until it has processed the max. If you don't specify `--max-messages`, the process runs continuously. | No | 50
 `--batch-size=<value>` | The number of messages to consume per batch. If specified, messages in a queue are consumed in batches of `<value>` each. This option is applicable for the batch consumer only. If `--batch-size` is not defined, the batch consumer receives all available messages in a queue. | No | 500
 `--pid-file-path=<value>` | The file path for saving PID of consumer process. | No | consumer process  such as `/var/someConsumer.pid`
-`--area-code=<value>` | The area code preferred for consumer process. | No | adminhtml
+`--area-code=<value>` | The area code preferred for consumer process. | No | global
 `<consumer_name>` | The consumer to start. | Yes | |
 {:style="table-layout:auto;"}
 
 After consuming all available messages, the command terminates. You can run the command again manually or with a cron job. You can also run multiple instances of the `magento queue:consumers:start` command to process large message queues. For example, you can append `&` to the command to run it in the background, return to a prompt, and continue running commands:
 
 ```bash
 bin/magento queue:consumers:start <consumer_name> &
-```
+```

guides/v2.1/extension-dev-guide/versioning/codebase-changes.md

@@ -19,6 +19,8 @@ The scope of the change determines whether the MAJOR, MINOR, or PATCH number inc
 ## Public vs private code changes
 
 A Magento module's codebase consists of public and private code.
+Public code includes Public {% glossarytooltip 786086f2-622b-4007-97fe-2c19e5283035 %}API{% endglossarytooltip %}(indicated by the `@api` docblock tag) and Public Customization Points.
+Private code is not accessible via the API: classes and constants marked as [private][].
 
 Changes in public code always trigger MINOR or MAJOR version increases.
 
@@ -30,7 +32,7 @@ If this is unavoidable, you must depend on the patch version of the core modules
 
 ## API and customization points
 
-Public code includes Public {% glossarytooltip 786086f2-622b-4007-97fe-2c19e5283035 %}API{% endglossarytooltip %}(indicated by the `@api` docblock tag) and Public Customization Points.
+
 
 Modules call APIs to create new application scenarios.
 Modifications that break the API will trigger an increase in a module's MAJOR version.
@@ -163,3 +165,5 @@ Use this table to understand what changes Magento can make and which version num
 |                                                             | Index added/changed                                                                                  | PATCH          |
 |                                                             | Foreign key added                                                                                    | MAJOR          |
 |                                                             | Temporary tables added/removed/changed                                                               | PATCH          |
+
+[private]: http://php.net/manual/en/language.oop5.visibility.php

guides/v2.1/install-gde/trouble/php/tshoot_php-set.md

@@ -11,22 +11,24 @@ functional_areas:
   - Setup
 ---
 
-### always_populate_raw_post_data error {#trouble-php-always}
+## always_populate_raw_post_data error {#trouble-php-always}
 
 If you're upgrading the Magento 2 software, the following error can display during the readiness check:
 
 ![If all readiness checks pass, click Next and continue with the next step]({{ site.baseurl }}/common/images/upgr_readiness-success.png){:width="700px}
 
 To resolve the error:
 
-1.	Locate your `php.ini` using a [`phpinfo.php`]({{ page.baseurl }}/install-gde/prereq/optional.html#install-optional-phpinfo) page.
+1.	Locate your `php.ini` using a [`phpinfo.php`][] page.
 
 	(Sometimes you have a different `php.ini` for the PHP command line and the web server. The `php.ini` you must change displays as **Loaded Configuration File**)
 
 2.	As a user with `root` privileges, open `php.ini` in a text editor.
 3.	Uncomment the following line:
 
+```php?start_inline=1
 		always_populate_raw_post_data = -1
+```
 4.	Save your changes to `php.ini` and exit the text editor.
 5.	Wait for all steps in the readiness check to finish.
 6.	Resolve any other issues displayed by the readiness check.
@@ -39,7 +41,7 @@ To resolve the error:
 
 8.	On the readiness check page, click **Try Again**.
 
-### PHP memory limit error {#trouble-php-memory}
+## PHP memory limit error {#trouble-php-memory}
 
 The readiness checks makes sure you have at least 1GB of memory set aside for {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} processes. This setting should be sufficient for most installations, including installing optional sample data. However, we recommend at least 2GB for debugging.
 
@@ -62,18 +64,31 @@ To increase your PHP memory limit:
 	*	nginx (both CentOS and Ubuntu): `service nginx restart`
 8.	Try the installation again.
 
-### xdebug maximum function nesting level error {#trouble-php-xdebug}
+
+## max-input-vars error due to large forms
+
+Configurations with a high number of storeviews, products, attributes, or options can generate forms that exceed the preset PHP limit.
+If the number of values sent surpasses the `max-input-vars` limit set within `php.ini` (default is 1000), the remaining data is not transferred and those database values do not get updated.
+When this occurs, a warning appears in the PHP log:
+
+```bash
+PHP message: PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini.
+```
+ There is no 'proper' value for `max-input-vars`; it depends on the size and complexity of your configuration. Modify the value in the `php.ini` file as needed. See [Required PHP settings][].
+
+
+## xdebug maximum function nesting level error {#trouble-php-xdebug}
 
 See [During installation, xdebug maximum function nesting level error]({{ page.baseurl }}/install-gde/trouble/php/tshoot_xdebug.html).
 
-### Errors display when you access a PHTML template {#trouble-php-asptags}
+## Errors display when you access a PHTML template {#trouble-php-asptags}
 
 Error text is typically:
 
     Parse error: syntax error, unexpected 'data' (T_STRING)
 
-#### Solution: Set <code>asp_tags = off</code> in <code>php.ini</code>
-Multiple templates have syntax for support abstract level on templates (use different templates engines like Twig) wrapped in `<% %>` tags, like this [template]({{ site.mage2000url }}app/code/Magento/Catalog/view/adminhtml/templates/product/edit/base_image.phtml){:target="_blank"} for displaying a product image:
+### Solution: Set <code>asp_tags = off</code> in <code>php.ini</code>
+Multiple templates have syntax for support abstract level on templates (use different templates engines like Twig) wrapped in `<% %>` tags, like this [template][]{:target="_blank"} for displaying a product image:
 
 ```php?start_inline=1
 <img
@@ -83,6 +98,13 @@ Multiple templates have syntax for support abstract level on templates (use diff
     alt="<%- data.label %>" />
 ```
 
-More information about [asp_tags](http://php.net/manual/en/ini.core.php#ini.asp-tags){:target="_blank"}.
+More information about [asp_tags][]{:target="_blank"}.
+
+Edit `php.ini` and set `asp_tags = off`. For more information, see [Required PHP settings][].
+
+<!-- Link Reference -->
 
-Edit `php.ini` and set `asp_tags = off`. For more information, see [Required PHP settings]({{ page.baseurl }}/install-gde/prereq/php-settings.html).
+[Required PHP settings]: {{ page.baseurl }}/install-gde/prereq/php-settings.html
+[asp_tags]: http://php.net/manual/en/ini.core.php#ini.asp-tags
+[template]: {{ site.mage2000url }}app/code/Magento/Catalog/view/adminhtml/templates/product/edit/base_image.phtml
+[`phpinfo.php`]: {{ page.baseurl }}/install-gde/prereq/optional.html#install-optional-phpinfo

guides/v2.1/mtf/mtf_entities/mtf_scenariotest.md

@@ -3,25 +3,25 @@ group: functional-testing-framework-guide
 title: Scenario test
 ---
 
-Scenario test is a case of separate test steps where each step is a distinct class. Test steps can be grouped in any order that makes functional testing more agile comparatively with [injectable test].  
+A scenario test is a case of separate test steps where each step is a distinct class. Test steps can be grouped in any order that makes functional testing more agile comparable to [injectable test].  
 
-Scenario test has the following advantages:
+A scenario test has the following advantages:
 
 - Each step in the scenario is a separate {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} class that is placed in the {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} it belongs to.
-- Scenario test reduces code duplication because each step can be used multiple times.
+- A scenario test reduces code duplication because each step can be used multiple times.
 - Scenario tests are flexible and support Magento modularity.
-- New test can be easily created using existing steps.
+- A new test can be easily created using existing steps.
 
-Scenario test is split into four logical components:
+A scenario test is split into four logical components:
 
-- [test case], which executes tests steps in the order defined in a tests scenario
-- [data set], which contains variations of data and constraints for test steps 
-- [test scenario], which defines order of test steps
-- [test step], which contains a test flow
+- [test case], which executes tests steps in the order defined in a tests scenario.
+- [data set], which contains variations of data and constraints for test steps.
+- [test scenario], which defines order of test steps.
+- [test step], which contains a test flow.
 
 ## Test case class   {#test-case}
 
-Test cases are located in `<magento2 root dir>/dev/tests/functional/tests/app/Magento/<module>/Test/TestCase` along with corresponding data sets. Each test case is a PHP class that only runs corresponding scenario, it doesn't contain any other logic than that. In general, the difference between scenario test case and injectable test case is that all test logic is moved to distinct test steps, and their sequence is defined separately in {% glossarytooltip 8c0645c5-aa6b-4a52-8266-5659a8b9d079 %}XML{% endglossarytooltip %} file.
+Test cases are located in `<magento2 root dir>/dev/tests/functional/tests/app/Magento/<module>/Test/TestCase` along with the corresponding data sets. Each test case is a PHP class that runs the corresponding scenario. It does not contain any other logic. In general, the difference between a scenario test case and an injectable test case is that all test logic is moved to distinct test steps, and their sequence is defined separately in a {% glossarytooltip 8c0645c5-aa6b-4a52-8266-5659a8b9d079 %}XML{% endglossarytooltip %} file.
 
 Implementation of a scenario test is always the same. You have to change the name of your test case only.
 
@@ -57,11 +57,11 @@ class FunctionalityYouWantToTest extends Scenario
 
 ```
 
-Scenario test case is a PHP class that extends the `\Magento\Mtf\TestCase\Scenario\` class and implements the `test()` method that calls `executeScenario()`. However, the `Scenario` class is not an interface, so the method can have any other name than `test()`.
+A scenario test case is a PHP class that extends the `\Magento\Mtf\TestCase\Scenario\` class and implements the `test()` method that calls `executeScenario()`. However, the `Scenario` class is not an interface, so the method can have any name other than `test()`.
 
 ## Test scenario    {#test-scenario}
 
-Test scenario is a sequence of test steps. Each scenario test case has its own scenario. All scenarios for a module are collected in an XML file located in `<magento2 root dir>dev/tests/functional/tests/app/Magento/<module>/Test/etc/testcase.xml`.
+A test scenario is a sequence of test steps. Each scenario test case has its own scenario. All scenarios for a module are collected in an XML file located in `<magento2 root dir>dev/tests/functional/tests/app/Magento/<module>/Test/etc/testcase.xml`.
 
 ```xml
 <?xml version="1.0"?>
@@ -96,7 +96,7 @@ The example declares a scenario for `TestCase/OnePageCheckoutTest.php` where `<s
 
 ### `<step>` element    {#step-element}
 
-Each scenario contains test steps as `<step>` child elements. Each `<step>` requires `name` and `module` to define the name of a test step and the module to which it belongs to. All test steps are located in `<module>/Test/TestStep`.
+Each scenario contains test steps as `<step>` child elements. Each `<step>` requires `name` and `module` to define the name of a test step and the module to which it belongs. All test steps are located in `<module>/Test/TestStep`.
 
 Example:
 
@@ -112,9 +112,7 @@ The example defines the following test steps:
 
 #### `next` and `prev` attributes   {#next-prev-attributes}
 
-Using `next` and `prev` attributes you can specify previous or next test step as part of the node.
-
-The following examples show tangled structure to demonstrate logic of the attributes.
+Use `next` and `prev` attributes to specify previous or next test steps as part of the node.
 
 ```xml
 <scenario name="OnePageCheckoutTest" firstStep="setupConfiguration">
@@ -140,7 +138,7 @@ Both examples define the following test steps and their sequence:
 Sometimes you want to use the same test step more then once in your scenario. In this case, you can use the `alias` attribute to define another name for a step that has been already listed as `<step>`.
 
 {: .bs-callout .bs-callout-info }
-Note that you can use `<step>` with the same name in a scenario only once.
+You can only use a `<step>` with the same name within a scenario once.
 
 Example:
 
@@ -160,10 +158,9 @@ The example defines the following test steps and their sequence:
 
 ## Test step class  {#test-step}
 
-All test steps are located in `<module>/Test/TestStep` as PHP classes in the following format:
+The `<module>/Test/TestStep` directory contains each test step as a PHP class with the following format:
 
 ```php
-
 <?php
 
 namespace Magento\YourModule\Test\TestStep;
@@ -174,9 +171,9 @@ class YourTestStep implements TestStepInterface
 {
     public function __construct
     (
-        // data that are required for this step along with other dependencies.
+        // data and other dependencies required for this step.
     ) {
-        // all required classes (fixtures, pages, etc.) have to be assigned here.
+        // all required classes (fixtures, pages, etc.) are assigned here.
     };
 
     public function run()
@@ -190,16 +187,15 @@ class YourTestStep implements TestStepInterface
     }
 
 }
-
 ```
 
-A tests step must implement `Magento\Mtf\TestStep\TestStepInterface` and define:
+A test step must implement `Magento\Mtf\TestStep\TestStepInterface` and define:
 
  - constructor (optional)
  - public method `run()` (required)
  - public method `cleanup()` (optional)
 
-Let's see a test step on the example with `Magento\Customer\Test\TestStep\LoginCustomerOnFrontendStep`.
+An example with `Magento\Customer\Test\TestStep\LoginCustomerOnFrontendStep`:
 
 {% collapsible Show/hide example %}
 
@@ -298,32 +294,32 @@ class LoginCustomerOnFrontendStep implements TestStepInterface
 
 ### `constructor()` method  {#constructor-method}
 
-You can optionally use the `constructor()` method which injects data to be used by `run()`. The data may include classes like pages, variation data, data returned by previous executed steps, etc.
+Optionally, you may use the `constructor()` method, which injects data to be used by `run()`. The data may include classes like pages, variation data, data returned by previous executed steps, etc.
 
 On the previous example the `constructor()`:
 
-- injects the `CmsIndex` and `CustomerAccountLogin` pages
-- injects the `LogoutCustomerOnFrontendStep` step
-- injects the `Customer` fixture data
-- assigns arguments to corresponding class properties
+- injects the `CmsIndex` and `CustomerAccountLogin` pages.
+- injects the `LogoutCustomerOnFrontendStep` step.
+- injects the `Customer` fixture data.
+- assigns arguments to corresponding class properties.
 
 ### `run()` method  {#run-method}
 
 The `run()` method is required to perform a test step and contains logic of the step.
 
 On the previous example the `run()` method:
 
-- logs out if the customer was logged in
-- clicks 'Sign In' on the `LinksBlock` of the `cmsIndex` page
-- waits for requested page loading
-- logs in the customer on the `customerAccountLogin` page
-- waits for logging in the customer
+- logs out if the customer was logged in.
+- clicks 'Sign In' on the `LinksBlock` of the `cmsIndex` page.
+- waits for requested page loading.
+- logs in the customer on the `customerAccountLogin` page.
+- waits for logging in the customer.
 
 ### `cleanup()` method  {#cleanup-method}
 
-The `cleanup()` method is optional. It serves to reset Magento to initial state or execute any other logic after each variation of a test step.
+The `cleanup()` method is optional. It serves to reset Magento to an initial state or executes any other logic after each variation of a test step.
 
-On the previous example the `clean()` method:
+On the previous example, the `clean()` method:
 
 - logs out the customer