Merge pull request #6808 from magento/small-changes

Small changes

Author: dobooth

src/cloud/docker/docker-containers.md

@@ -49,7 +49,7 @@ For example, the following command starts the Docker configuration generator in
 ./vendor/bin/ece-docker build:compose --mode="developer" --php 7.2
 ```
 
-See [See Docker services containters] for details.
+See [Docker service containers][] for details.
 
 ## Request Flow
 
@@ -137,7 +137,7 @@ Now you can see all requests that are passing through the TLS container and chec
 [db]: {{site.baseurl}}/cloud/docker/docker-containers-service.html#database-container
 [elasticsearch]: {{site.baseurl}}/cloud/docker/docker-containers-service.html#elasticsearch-container
 [Docker CLI containers]: {{site.baseurl}}/cloud/docker/docker-containers-cli.html
-[Docker service containers]: {{site.baseurl}}/cloud/docker-containers-service.html
+[Docker service containers]: {{site.baseurl}}/cloud/docker/docker-containers-service.html
 [Web containers]: {{site.baseurl}}/cloud/docker/docker-php.html
 [Developer Mode]: {{site.baseurl}}/cloud/docker/docker-mode-developer.html
 [File Synchronization]: {{site.baseurl}}/cloud/docker/docker-syncing-data.html

src/cloud/docker/docker-mode-production.md

@@ -12,7 +12,7 @@ Production mode is the default configuration setting for launching the Docker en
 {%include cloud/note-docker-config-reference-link.md%}
 
 {:.procedure}
-To launch the Docker environment in developer mode:
+To launch the Docker environment in production mode:
 
 1. Download a Magento application template from the [Magento Cloud repository][cloud-repo]. Be careful to select the branch that corresponds with the Magento version.
 
@@ -95,4 +95,4 @@ To launch the Docker environment in developer mode:
 [cloud-repo]: https://github.com/magento/magento-cloud
 [magento-creds]: {{site.baseurl}}/guides/v2.3/install-gde/prereq/connect-auth.html
 [services]: {{site.baseurl}}/cloud/docker/docker-containers.html#service-containers
-[configure Xdebug]: {{site.baseurl}}/cloud/docker/docker-development-debug.html#configure-xdebug
+[configure Xdebug]: {{site.baseurl}}/cloud/docker/docker-development-debug.html#configure-xdebug

src/cloud/release-notes/ece-release-notes.md

@@ -56,7 +56,7 @@ See [Upgrades and patches]({{ site.baseurl }}/cloud/project/project-upgrade-pare
 
    -  {:.new}Added the `ERROR_REPORT_DIR_NESTING_LEVEL` environment variable to simplify error report data management in the `<magento_root>/var/report/` directory. See the variable description in the [build variables]({{site.baseurl}}/cloud/env/variables-build.html#error_report_dir_nesting_level) topic.
 
-   -  {:.fix}Removed the `SCD_EXCLUDE_THEMES`, `STATIC_CONTENT_THREADS`,`DO_DEPLOY_STATIC_CONTENT`, `SKIP_SCD`, and `STATIC_CONTENT_SYMLINK` environment variables. See [Backward incompatible changes]({{site.baseurl}}/cloud/release-notes/backward-incompatible-changes.html#environment-configuration-changes).<!--MAGECLOUD-4407, MAGECLOUD-3873-->
+   -  {:.fix}Removed the `SCD_EXCLUDE_THEMES`, `STATIC_CONTENT_THREADS`,`DO_DEPLOY_STATIC_CONTENT`, and `STATIC_CONTENT_SYMLINK` environment variables. See [Backward incompatible changes]({{site.baseurl}}/cloud/release-notes/backward-incompatible-changes.html#environment-configuration-changes).<!--MAGECLOUD-4407, MAGECLOUD-3873-->
 
    -  {:.fix}Fixed an issue in the Elastic Suite configuration process so that the default configuration is overwritten as expected when you configure the `ELASTICSUITE_CONFIGURATION` deploy variable without the `_merge` option.<!--MAGECLOUD-4388-->
 

src/common/images/ui_comps/ui-text-result.png

@@ -77,6 +77,11 @@ Where the following notation is used:
 -  `<language>`: specified in the `code_subtag` format, for example `en_US`. Only one locale can be specified here. To debug the theme with another locale, create one more theme declaration, having specified another value for `language`.
 -  `<path_to_file>`: path to the root source file, relative to the `app/design/frontend/<Vendor>/<theme>/web` directory. You need to specify all [root source files of the theme]({{ page.baseurl }}/frontend-dev-guide/css-topics/css-preprocess.html#css_preprocess_terms). If your theme [inherits] from a certain theme, and does not contain its own root source files, specify the root source files of the parent theme.
 
+Once these are set correctly, run grunt to watch your changes.
+
+-  Run `grunt exec:<theme>` from the root directory to republish the symlinks.
+-  Run `grunt watch:<theme>` so that grunt will watch for file changes.
+
 ## Using custom Grunt configuration files
 
 There are several ways to declare a custom configuration file.

src/guides/v2.3/frontend-dev-guide/tools/using_grunt.md

@@ -341,9 +341,9 @@ type Customer @doc(description: "Customer defines the customer name and address
     default_shipping: String @doc(description: "The ID assigned to the shipping address")
     date_of_birth: String @doc(description: "The customer's date of birth")
     taxvat: String @doc(description: "The customer's Tax/VAT number (for corporate customers)")
-    id: Int @doc(description: "The ID assigned to the customer")
     is_subscribed: Boolean @doc(description: "Indicates whether the customer is subscribed to the company's newsletter") @resolver(class: "\\Magento\\CustomerGraphQl\\Model\\Resolver\\IsSubscribed")
     addresses: [CustomerAddress] @doc(description: "An array containing the customer's shipping and billing addresses")
+    gender: Int @doc(description: "The customer's gender (Male - 1, Female - 2)")
 }
 ```
 
@@ -361,7 +361,6 @@ mutation {
         }
     ) {
         customer {
-            id
             firstname
             lastname
             email
@@ -378,7 +377,6 @@ A sample response:
   "data": {
     "createCustomer": {
       "customer": {
-        "id": 5,
         "firstname": "John",
         "lastname": "Doe",
         "email": "j.doe@example.com",

src/guides/v2.3/graphql/develop/resolvers.md

@@ -32,7 +32,7 @@ mutation {
         }
         quantity
       }
-      applied_coupon {
+      applied_coupons {
         code
       }
       prices {
@@ -73,7 +73,7 @@ mutation {
             "quantity": 1
           }
         ],
-        "applied_coupon": {
+        "applied_coupons": {
           "code": "H20"
         },
         "prices": {

src/guides/v2.3/graphql/mutations/apply-coupon.md

@@ -37,7 +37,6 @@ mutation {
     id
     region {
       region
-      region_id
       region_code
     }
     country_code

src/guides/v2.3/graphql/mutations/create-customer-address.md

@@ -73,8 +73,8 @@ Attribute |  Data Type | Description
 
 Attribute |  Data Type | Description
 --- | --- | ---
-`order_id` String | The unique ID that identifies the order
-`order_number` String | The unique ID that identifies the order
+`order_id` | String! | Deprecated. Use `order_number` instead. The unique ID that identifies the order
+`order_number` | String | The unique ID that identifies the order
 
 ## Errors
 

src/guides/v2.3/graphql/mutations/place-order.md

@@ -30,7 +30,7 @@ mutation {
         }
         quantity
       }
-      applied_coupon {
+      applied_coupons {
         code
       }
       prices {
@@ -65,7 +65,7 @@ mutation {
             "quantity": 1
           }
         ],
-        "applied_coupon": null,
+        "applied_coupons": null,
         "prices": {
           "grand_total": {
             "value": 39,

src/guides/v2.3/graphql/mutations/remove-coupon.md

@@ -37,7 +37,6 @@ The following call returns information about the logged-in customer. Provide the
       region {
         region_code
         region
-        region_id
       }
       postcode
       country_code
@@ -68,8 +67,7 @@ The following call returns information about the logged-in customer. Provide the
          "city": "Anytown",
          "region": {
            "region_code": "MI",
-           "region": "Michigan",
-           "region_id": 33
+           "region": "Michigan"
          }
          "postcode": "78758",
          "country_code": "US",

src/guides/v2.3/graphql/queries/customer.md

@@ -34,7 +34,7 @@ mutation {
     }
   ) {
     cart {
-      applied_coupon {
+      applied_coupons {
         code
       }
     }
@@ -49,7 +49,7 @@ mutation {
   "data": {
     "applyCouponToCart": {
       "cart": {
-        "applied_coupon": {
+        "applied_coupons": {
           "code": "{ COUPON_CODE }"
         }
       }
@@ -69,7 +69,7 @@ For logged-in customers, send the customer's authorization token in the `Authori
 mutation {
   removeCouponFromCart(input: { cart_id: "{ CART_ID }" }) {
     cart {
-      applied_coupon {
+      applied_coupons {
         code
       }
     }
@@ -84,7 +84,7 @@ mutation {
   "data": {
     "removeCouponFromCart": {
       "cart": {
-        "applied_coupon": {
+        "applied_coupons": {
           "applied_coupon": null
         }
       }

src/guides/v2.3/graphql/tutorials/checkout/checkout-coupon.md

@@ -159,7 +159,7 @@ This configuration is stored in the `window.checkoutConfig` variable that is def
 
 In order to get access to the system configuration, your payment method or a group of payment methods has to implement the [`\Magento\Checkout\Model\ConfigProviderInterface`]({{ site.mage2bloburl }}/{{ page.guide_version }}/app/code/Magento/Checkout/Model/ConfigProviderInterface.php) interface, and the class implementing it must be injected to the composite config provider via DI [frontend](https://glossary.magento.com/frontend) configuration. The following code samples illustrate this.
 
-A sample `.php` class implementing `\Magento\Checkout\Model\ConfigProviderInterface`:
+This is a sample `.php` file implementing `\Magento\Checkout\Model\ConfigProviderInterface`:
 
 ```php?start_inline=1
 class MyCustomPaymentConfigProvider implements \Magento\Checkout\Model\ConfigProviderInterface
@@ -175,7 +175,7 @@ class MyCustomPaymentConfigProvider implements \Magento\Checkout\Model\ConfigPro
 }
 ```
 
-A sample DI configuration file of a custom module `<your_module_dir>/etc/frontend/di.xml`:
+Here is the associated sample DI configuration file of a custom module `<your_module_dir>/etc/frontend/di.xml`:
 
 ```xml
 ...

src/guides/v2.3/howdoi/checkout/checkout_payment.md

@@ -17,6 +17,7 @@ All configuration is done in the `requirejs-config.js` file. It has a single roo
 var config = {
     'map': {...},
     'paths': {...},
+    'deps':[...],
     'shim': {...},
     'config': {
         'mixins': {...},
@@ -52,7 +53,7 @@ You can also use the `map` configuration to override a JS module with a custom J
 
 ### paths {#requirejs-config-paths}
 
-The `paths` configuration, similar to `map`, is used for aliasing not just any real AMD module that calls `define()`, but also any JS file (event from a URL), HTML templates, etc. Magento uses this to alias URLs and third party libraries.
+The `paths` configuration, similar to `map`, is used for aliasing not just any real AMD module that calls `define()`, but also any JS file (even from a URL), HTML templates, etc. Magento uses this to alias URLs and third party libraries.
 
 ```javascript
 paths: {
@@ -95,7 +96,7 @@ shim: {
 
 ### mixins {#requirejs-config-mixin}
 
-The `mixins` configuration is used to overwrite component methods of an AMD module which returns either a UI component,a jQuery widget, or a JS object. Unlike the above configuration properties, the `mixins` property is under the `config` property, apart from the parent object called **config**.
+The `mixins` configuration is used to overwrite component methods of an AMD module which returns either a UI component, a jQuery widget, or a JS object. Unlike the above configuration properties, the `mixins` property is under the `config` property, apart from the parent object called **config**.
 
 In this snippet, `Vendor_Module/js/module-mixin` will overwrite the existing component methods in `Vendor_Module/js/module` with the specified component methods. It is a convention to name the mixin by appending a `-mixin` to the original `path/to/js`, although not required.
 

src/guides/v2.3/javascript-dev-guide/javascript/requirejs.md

@@ -97,7 +97,7 @@ Declare your modifier in your module Di configuration `<Your_Module_dir>/etc/adm
 </virtualType>
 ```
 
-, where `YourNamespace\YourModule\DataProvider\Modifier\Pool` is a [virtual class]({{ page.baseurl }}/extension-dev-guide/depend-inj.html#dependency-types).
+where `YourNamespace\YourModule\DataProvider\Modifier\Pool` is a [virtual class]({{ page.baseurl }}/extension-dev-guide/depend-inj.html#dependency-types).
 
 (If you want to use this sample in your `di.xml`, replace the sample values with the real names of your entities.)
 

src/guides/v2.3/ui_comp_guide/concepts/ui_comp_modifier_concept.md

@@ -46,7 +46,7 @@ Perhaps the most useful aspect of template literals is the ability to access oth
 
 UI Components can have a `<item name="config" xsi:type="array">...</item>` node in the primary XML declaration file ([see an example]({{ page.baseurl }}/ui_comp_guide/concepts/ui_comp_xmldeclaration_concept.html#example-of-a-basic-components-configuration-file)). In that file, a `component` element can be added with a path reference to the RequireJS file. That file is loaded into the registry when it runs on the frontend and other JavaScript files can then access it by the *name* of the UI Component instead of the path to the file itself. The name often will look something like this: `example_component.example_component`.
 
-Names of other registered modules can be added to the [server side](https://glossary.magento.com/server-side) configuration (XML or PHP) that is output through JSON. Those names can then be easily accessed in the JavaScript on the frontend. In the following example, the other UI Component's name will be obtained with a template literal in the `imports` object. When this JavaScript file is loaded, it will process the template literal and look up the name in the registry. If found, it will load that class. Because there is a colon (`:`), it will go on to find the property that is accessed in the other JavaScript class.
+Names of other registered modules can be added to the [server side](https://glossary.magento.com/server-side) configuration ([XML](https://glossary.magento.com/xml) or [PHP](https://glossary.magento.com/php)) that is output through JSON. Those names can then be easily accessed in the JavaScript on the frontend. In the following example, the other UI Component's name will be obtained with a template literal in the `imports` object. When this JavaScript file is loaded, it will process the template literal and look up the name in the registry. If found, it will load that class. Because there is a colon (`:`), it will go on to find the property that is accessed in the other JavaScript class.
 
 ```javascript
 return Element.extend({

src/guides/v2.3/ui_comp_guide/concepts/ui_comp_template_literals.md

@@ -48,7 +48,7 @@ initialize: function () {
 }
 ```
 
-*  The `_super()` method calls the parent UI component method with the same name as the `_super()` method's caller; if that method does not exists in the parent UI component, then the method tries to find it higher in the inheritance chain.
+*  The `_super()` method calls the parent UI component method with the same name as the `_super()` method's caller. If that method does not exists in the parent UI component, then the method tries to find it higher in the inheritance chain.
 
 As an example:
 

src/guides/v2.3/ui_comp_guide/concepts/ui_comp_uiclass_concept.md

@@ -30,7 +30,7 @@ The instance configuration file name is the name of instance (`%instance_name%`)
 Following are the rules for the instance configuration files:
 
 *  The top node must have the name of one of the basic UI components. <!-- need to mention or link what components -->
-*  The top node must contain a link to the XSD schema.
+*  The top node must contain a link to the [XSD](https://glossary.magento.com/xsd) schema.
 
 In the top node, there can be an `<argument/>` node. The `<argument/>` node contains the configuration for that basic UI component. The `<argument/>` node's `name` attribute value must be `data`. The child nodes of the `<argument>` node will be the argument properties that will be passed in to the component.
 
@@ -107,7 +107,7 @@ In the above example, within the top-level `<form>` node the `<fieldset>` node i
 
 The `name` attribute value must be a unique among the other components on the same hierarchical level of the same parent node. Look at the `<argument>` node which `name` attribute has `data` value. The child nodes of this node are the arguments that will be passed in to the component.
 
-All other child nodes are declared as items. `<item name="config"> ...</item>` contains the children nodes that describe the configuration of the current UI component. Please note that although configuration for all components is different, there are base properties that are mostly the same for different components. For example, we can use `<item name="component">...</item>` to define which JS file will be used as the Model for the  Fieldset UI component in the above example. Reference to this JS file can be either be the full path to this file or the alias which is defined in [`require.js` configuration]({{ page.baseurl }}/javascript-dev-guide/javascript/js-resources.html).
+All other child nodes are declared as items. `<item name="config"> ...</item>` contains the children nodes that describe the configuration of the current UI component. Please note that although configuration for all components is different, there are base properties that are mostly the same for different components. For example, we can use `<item name="component">...</item>` to define which JS file will be used as the Model for the Fieldset UI component in the above example. Reference to this JS file can be either be the full path to this file or the alias which is defined in [`require.js`]({{ page.baseurl }}/javascript-dev-guide/javascript/js-resources.html) configuration.
 
 In our example, the `<item name="component">...</item>` node within `<fieldset>` is omitted, because this property of the Fieldset UI component is already defined in `definition.xml`.