diff --git a/_includes/cloud/hooks.md b/_includes/cloud/hooks.md
index bce29f1d092..1b4c430025a 100644
--- a/_includes/cloud/hooks.md
+++ b/_includes/cloud/hooks.md
@@ -2,7 +2,7 @@
For technical reasons, Magento Enterprise Cloud Edition staging and production systems don't implement any deployment hooks automatically. These hooks, defined in the `hooks` section of your [`.magento.app.yaml` file]({{ page.baseurl }}cloud/project/project-conf-files_magento-app.html#cloud-yaml-platform-hooks), must be manually migrated to staging or production.
-Create a [support ticket]({{ page.baseurl }}cloud/get-help.html) to let us help you implement any deployment hooks you set up.
+Create a [support ticket]({{ page.baseurl }}cloud/welcome/get-help.html) to let us help you implement any deployment hooks you set up.
Among the settings you can request us to enable are Xdebug and PHPUnit, which assists you in troubleshooting any coding issues you might have during deployment. Because of its memory requirements, we recommend you disable Xdebug before your site is live.
diff --git a/_includes/cloud/patch.md b/_includes/cloud/patch.md
index 504e3ebb2f7..7faee0d63fe 100644
--- a/_includes/cloud/patch.md
+++ b/_includes/cloud/patch.md
@@ -17,13 +17,13 @@ There are two types of patches:
Copy custom patches to the `m2-hotfixes` directory and test them on your locally. After successfully testing them, push the patches to the remote server.
-Always test a patch your local system, then your [integration environment]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-int) system (that is, the remote Cloud server). Resolve any issues before you patch either [staging]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-stage) or [production]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-prod).
+Always test a patch your local system, then your [integration environment]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-int) system (that is, the remote Cloud server). Resolve any issues before you patch either [staging]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-stage) or [production]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-prod).
## Test general patches {#cloud-patch-gen}
*General patches* are provided for all Magento Enterprise Cloud Edition customers in a repository referenced in your `composer.json`. We apply patches automatically during the build phase when a patch is available. The procedure discussed in this section enables to you test a patch locally anytime you choose.
-The procedure you use is slightly different, depending on the type of environment: [integration]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-int), [staging]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-stage), or [production]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-prod).
+The procedure you use is slightly different, depending on the type of environment: [integration]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-int), [staging]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-stage), or [production]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-prod).
{% collapsibleh3 Get started %}
We recommend you test a patch in the `master` branch.
@@ -87,7 +87,7 @@ After you've successfully tested a patch locally and on your integration environ
## Test custom patches {#cloud-patch-custom}
*Custom patches* are provided to specific customers in a Support ticket. Before you continue, make sure the patch file we provided you is available.
-The procedure you use is slightly different, depending on the type of environment: [integration]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-int), [staging]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-stage), or [production]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-prod).
+The procedure you use is slightly different, depending on the type of environment: [integration]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-int), [staging]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-stage), or [production]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-prod).
{% collapsibleh3 Get started %}
We recommend you test a patch locally in the `master` branch.
diff --git a/_includes/cloud/sens-data-create-config-local.md b/_includes/cloud/sens-data-create-config-local.md
index 1687e24ce57..ea1cb582922 100644
--- a/_includes/cloud/sens-data-create-config-local.md
+++ b/_includes/cloud/sens-data-create-config-local.md
@@ -5,11 +5,11 @@
magento-cloud environment:ssh --pipe
2. Create `config.local.php` on the integration server.
- ssh -k "php bin/magento app:config:scd-dump"
+ ssh -k "php bin/magento magento-cloud:scd-dump"
For example,
- ssh -k itnu84v4m4e5k-master-ouhx5wq@ssh.us.magentosite.cloud "php bin/magento app:config:scd-dump"
+ ssh -k itnu84v4m4e5k-master-ouhx5wq@ssh.us.magentosite.cloud "php bin/magento magento-cloud:scd-dump"
Overview
The Magento software can use the following types of libraries:
-* Magento PHP libraries, which are discussed in the next section.
+* Magento {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} libraries, which are discussed in the next section.
* Magento UI libraries, which are located in the lib/web directory.
For more information, see library documentation on GitHub and View Library.
@@ -30,7 +30,7 @@ The Magento software can use the following types of libraries:
Third-party libraries are organized by vendor to be PSR-0 compliant.
Magento PHP libraries
-Magento PHP libraries include code that is designed to be independent libraries of code useful to a Magento application. Each library has minimal dependencies on any other library.
+Magento PHP libraries include code that is designed to be independent libraries of code useful to a Magento application. Each {% glossarytooltip 08968dbb-2eeb-45c7-ae95-ffca228a7575 %}library{% endglossarytooltip %} has minimal dependencies on any other library.
For example:
diff --git a/guides/v2.0/architecture/arch_themes.md b/guides/v2.0/architecture/arch_themes.md
index fa5e5aa5721..681979bf46f 100644
--- a/guides/v2.0/architecture/arch_themes.md
+++ b/guides/v2.0/architecture/arch_themes.md
@@ -10,13 +10,13 @@ github_link: architecture/arch_themes.md
redirect_from: /guides/v1.0/architecture/arch_themes.html
---
-Themes allow you to customize the look-and-feel of the Magento application. Themes generally provide no new business features of their own, other than branding and user experience. They relate to each other through inheritance, allowing you to customize an existing theme by setting it as the parent and then defining any desired customizations in the new theme.
+Themes allow you to customize the look-and-feel of the Magento application. Themes generally provide no new business features of their own, other than branding and user experience. They relate to each other through inheritance, allowing you to customize an existing {% glossarytooltip d2093e4a-2b71-48a3-99b7-b32af7158019 %}theme{% endglossarytooltip %} by setting it as the parent and then defining any desired customizations in the new theme.
Themes are located in the `/app/design/frontend//` folder of a Magento installation. Each theme contains a `theme.xml` file, which defines the name and version of that theme, as well as the name of the parent theme, if any.
-Themes are also divided by area, allowing you to define themes that customize either the storefront or Magento Admin.
+Themes are also divided by area, allowing you to define themes that customize either the {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %} or {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %}.
-For detailed information about working with themes, refer to Themes in the Frontend Developers Guide.
+For detailed information about working with themes, refer to Themes in the {% glossarytooltip b00459e5-a793-44dd-98d5-852ab33fc344 %}Frontend{% endglossarytooltip %} Developers Guide.
## Related topics {#m2arch-related}
diff --git a/guides/v2.0/architecture/arch_translations.md b/guides/v2.0/architecture/arch_translations.md
index 54af312f638..a3409c60fb8 100644
--- a/guides/v2.0/architecture/arch_translations.md
+++ b/guides/v2.0/architecture/arch_translations.md
@@ -10,7 +10,7 @@ github_link: architecture/arch_translations.md
redirect_from: /guides/v1.0/architecture/arch_translations.html
---
-Any text that's presented to the user can have a variety of captions or labels on the control elements, notifications, and error messages. The Magento application renders all these phrases in English (`US`) language (`en_US`). But if you deploy a storefront in a different language (or use the Magento Admin in different language), you can use other dictionaries for translations.
+Any text that's presented to the user can have a variety of captions or labels on the control elements, notifications, and error messages. The Magento application renders all these phrases in English (`US`) language (`en_US`). But if you deploy a {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %} in a different language (or use the {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %} in different language), you can use other dictionaries for translations.
You can either use translation packages provided with the Magento application, create your own, or obtain packages from the community.
diff --git a/guides/v2.0/architecture/arch_whatis.md b/guides/v2.0/architecture/arch_whatis.md
index 69bd65beb3e..1f04bbabe8c 100644
--- a/guides/v2.0/architecture/arch_whatis.md
+++ b/guides/v2.0/architecture/arch_whatis.md
@@ -19,13 +19,13 @@ Object-Oriented Programming (OOP) design allows for maximum flexibility and exte
This supports the separation of visual presentation from business logic. This compartmentalization simplifies customization of store appearance and behavior. Architectural layers also provide programmers with a high level-model for understanding the optimal placement of features and code in a complex system. Magento tweaks the classic Model-View-Controller architectural model, though: files within modules are typically grouped by functionality rather than file type.
-The *Magento Framework* defines the fundamental concepts and rules for how the components of the web site can behave. The Magento framework contains libraries that modules access but no business logic components. It accepts HTTP requests and routes them to the appropriate module.
+The *Magento Framework* defines the fundamental concepts and rules for how the components of the web site can behave. The Magento framework contains libraries that modules access but no business logic components. It accepts HTTP requests and routes them to the appropriate {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %}.
## Integration with architectural layers
### Presentation layer
-The Presentation layer provides both view components (layouts, blocks, templates) and controllers, which process commands to and from the user interface. The presentation layer can also include web API service bindings. (We include these service bindings in this discussion of the presentation layer model because web API calls come in through HTTP just like browser requests, and can be made via AJAX calls from the user interface. Consequently, while web API calls can originate from an external application, they can also originate from the user interface.)
+The Presentation layer provides both view components (layouts, blocks, templates) and controllers, which process commands to and from the user interface. The presentation layer can also include web {% glossarytooltip 786086f2-622b-4007-97fe-2c19e5283035 %}API{% endglossarytooltip %} service bindings. (We include these service bindings in this discussion of the presentation layer model because {% glossarytooltip 377dc0a3-b8a7-4dfa-808e-2de37e4c0029 %}web API{% endglossarytooltip %} calls come in through HTTP just like browser requests, and can be made via AJAX calls from the user interface. Consequently, while web API calls can originate from an external application, they can also originate from the user interface.)
### Service layer
@@ -33,11 +33,11 @@ Through the use of service contracts, the Service layer defines the overall inte
### Domain layer
-The Domain layer (also referred to as the Business Logic layer) provides business logic and functionality in base classes, resource models, and data access capabilities that you can extend and customize.
+The {% glossarytooltip 41aee03b-a5d5-49c2-8839-894090ef4e86 %}Domain{% endglossarytooltip %} layer (also referred to as the Business Logic layer) provides business logic and functionality in base classes, resource models, and data access capabilities that you can extend and customize.
## Ease of extensibility {#m2arch-extensibility}
-Magento uses dependency injection and service contracts to simplify the process of supplying a new implementation of a defined API.
+Magento uses {% glossarytooltip 2be50595-c5c7-4b9d-911c-3bf2cd3f7beb %}dependency injection{% endglossarytooltip %} and service contracts to simplify the process of supplying a new implementation of a defined API.
Dependency injection benefits include:
@@ -45,7 +45,7 @@ Dependency injection benefits include:
* you can modify a module without altering the client from anywhere you use the dependency injection framework to wire application logic together.
-Service Contracts provide a new way to access public API endpoints. These PHP interfaces to modules streamline the use of APIs for most modules.
+Service Contracts provide a new way to access public API endpoints. These {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} interfaces to modules streamline the use of APIs for most modules.
## Modularity {#m2arch-modularity}
@@ -57,7 +57,7 @@ Extend and customize the core components of your Magento store's PHP-, HTML5- an
## Strong stack of open-source technologies {#m2arch-open-source-stack}
-The Magento tech stack supplies a robust toolset for deploying large, distributed storefronts and for customizing the product for your particular needs. The Magento stack includes popular open-source technologies such as the Linux OS, Apache/Nginx server, MySQL, Zend, and Composer.
+The Magento tech stack supplies a robust toolset for deploying large, distributed storefronts and for customizing the product for your particular needs. The Magento stack includes popular open-source technologies such as the Linux OS, Apache/Nginx server, MySQL, Zend, and {% glossarytooltip d85e2d0a-221f-4d03-aa43-0cda9f50809e %}Composer{% endglossarytooltip %}.
For a comprehensive description of the Magento technology stack, see [Magento Technology Stack]({{page.baseurl}}architecture/tech-stack.html).
diff --git a/guides/v2.0/architecture/archi_perspectives/ALayers_intro.md b/guides/v2.0/architecture/archi_perspectives/ALayers_intro.md
index 413b3b5d532..be812c549c8 100644
--- a/guides/v2.0/architecture/archi_perspectives/ALayers_intro.md
+++ b/guides/v2.0/architecture/archi_perspectives/ALayers_intro.md
@@ -15,7 +15,7 @@ redirect_from: /guides/v1.0/architecture/archi_perspectives/ALayers_intro.html
At its highest level, Magento's product architecture consists of the core product code plus optional modules. These optional modules enhance or replace the basic product code.
-If you are substantially customizing the basic Magento product, module development will be your central focus. Modules organize code that supports a particular task or feature. A module can include code to change the look-and-feel of your storefront as well as its fundamental behavior.
+If you are substantially customizing the basic Magento product, {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} development will be your central focus. Modules organize code that supports a particular task or feature. A module can include code to change the look-and-feel of your {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %} as well as its fundamental behavior.
Your modules function with the core Magento product code, which is organized into layers. Understanding layered software pattern is essential for understanding basic Magento product organization.
@@ -25,9 +25,9 @@ Layered software is a popular, widely discussed principle in software developmen
Layered application design offers many advantages, but users of Magento will appreciate:
-* Stringent separation of business logic from presentation logic simplifies the customization process. For example, you can alter your storefront appearance without affecting any of the backend business logic.
+* Stringent separation of business logic from presentation logic simplifies the customization process. For example, you can alter your storefront appearance without affecting any of the {% glossarytooltip 74d6d228-34bd-4475-a6f8-0c0f4d6d0d61 %}backend{% endglossarytooltip %} business logic.
-* Clear organization of code predictably points extension developers to code location.
+* Clear organization of code predictably points {% glossarytooltip 55774db9-bf9d-40f3-83db-b10cc5ae3b68 %}extension{% endglossarytooltip %} developers to code location.
## Related topics
diff --git a/guides/v2.0/architecture/archi_perspectives/arch_diagrams.md b/guides/v2.0/architecture/archi_perspectives/arch_diagrams.md
index 26265274b94..139a7bb78eb 100644
--- a/guides/v2.0/architecture/archi_perspectives/arch_diagrams.md
+++ b/guides/v2.0/architecture/archi_perspectives/arch_diagrams.md
@@ -12,7 +12,7 @@ redirect_from: /guides/v1.0/architecture/archi_perspectives/arch_diagrams.html
## Magento architecture from different perspectives {#m2arch-whatis-overview}
-Depending upon your role and purpose for learning more about Magento, there are several different ways to view the Magento architecture. For example, a developer who wants to create new modules or perhaps customize an existing module will want to understand the architecture of a module itself, and how it fits into the larger view, with the Magento framework and other components. However, a merchant who wants to quickly build an online store front wants to view the collection of components from a higher level, and understand the components that impact the look, feel, and user interaction components.
+Depending upon your role and purpose for learning more about Magento, there are several different ways to view the Magento architecture. For example, a developer who wants to create new modules or perhaps customize an existing {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} will want to understand the architecture of a module itself, and how it fits into the larger view, with the Magento framework and other components. However, a merchant who wants to quickly build an online store front wants to view the collection of components from a higher level, and understand the components that impact the look, feel, and user interaction components.
## Architecture layers diagram {#archi-layers}
diff --git a/guides/v2.0/architecture/archi_perspectives/arch_layers.md b/guides/v2.0/architecture/archi_perspectives/arch_layers.md
index 0d759b496cf..afdf97c27c3 100644
--- a/guides/v2.0/architecture/archi_perspectives/arch_layers.md
+++ b/guides/v2.0/architecture/archi_perspectives/arch_layers.md
@@ -14,10 +14,10 @@ redirect_from: /guides/v1.0/architecture/archi_perspectives/arch_layers.html
### Overview
-The Magento Framework controls how application components interact, including request flow, routing, indexing, caching, and exception handling. It provides services that reduce the effort of creating modules that contain business logic, contributing to the goal of both making Magento code more modular as well as decreasing dependencies.
+The Magento Framework controls how application components interact, including request flow, routing, indexing, caching, and {% glossarytooltip 53da11f1-d0b8-4a7e-b078-1e099462b409 %}exception{% endglossarytooltip %} handling. It provides services that reduce the effort of creating modules that contain business logic, contributing to the goal of both making Magento code more modular as well as decreasing dependencies.
-This primarily PHP software component is organized into logical groups called libraries, which all modules can call. Most of the framework code sits under the domain layer or encloses the presentation, service, and domain layers. The framework contains no business logic.
-(Although the Magento Framework does not contain resource models, it does contain a library of code to help implement a resource model.)
+This primarily {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} software component is organized into logical groups called libraries, which all modules can call. Most of the framework code sits under the {% glossarytooltip 41aee03b-a5d5-49c2-8839-894090ef4e86 %}domain{% endglossarytooltip %} layer or encloses the presentation, service, and domain layers. The framework contains no business logic.
+(Although the Magento Framework does not contain resource models, it does contain a {% glossarytooltip 08968dbb-2eeb-45c7-ae95-ffca228a7575 %}library{% endglossarytooltip %} of code to help implement a resource model.)
Don't confuse the Magento framework with the Zend web application framework that ships with Magento.
@@ -48,19 +48,19 @@ Lib/
../Framework
-* `/lib/internal` contains some non-PHP as well as PHP components. Non-PHP framework libraries includes JavaScript and LESS/CSS.
+* `/lib/internal` contains some non-PHP as well as PHP components. Non-PHP framework libraries includes {% glossarytooltip 312b4baf-15f7-4968-944e-c814d53de218 %}JavaScript{% endglossarytooltip %} and LESS/CSS.
-* `/lib/internal/Magento/Framework` contains only PHP code. These are libraries of code plus the application entry point that routes requests to modules (that in turn call the framework libraries). For example, libraries in the framework help implement a resource model (base classes and interfaces to inherit from) but not the resource models themselves. Certain libraries also support CSS rendering.
+* `/lib/internal/Magento/Framework` contains only PHP code. These are libraries of code plus the application entry point that routes requests to modules (that in turn call the framework libraries). For example, libraries in the framework help implement a resource model (base classes and interfaces to inherit from) but not the resource models themselves. Certain libraries also support {% glossarytooltip 6c5cb4e9-9197-46f2-ba79-6147d9bfe66d %}CSS{% endglossarytooltip %} rendering.
* `/lib/web` contains JavaScript and CSS/LESS files. These files reside under `web` and not `internal` because they are accessible from a web browser, while the PHP code under `internal` is not. (Any code that a web browser must access should be under `web`, while everything else under `internal`.)
-
The lib/internal/Magento/Framework directory maps to the Magento\Framework namespace.
+
The lib/internal/Magento/Framework directory maps to the Magento\Framework {% glossarytooltip 621ef86b-7314-4fbc-a80d-ab7fa45a27cb %}namespace{% endglossarytooltip %}.
### Highlights of the Magento Framework
-The Magento Framework (`lib/internal/Magento/Framework/`) provides a robust range of functionality. If you are an extension developer, you may be interested in this subset of Framework namespaces.
+The Magento Framework (`lib/internal/Magento/Framework/`) provides a robust range of functionality. If you are an {% glossarytooltip 55774db9-bf9d-40f3-83db-b10cc5ae3b68 %}extension{% endglossarytooltip %} developer, you may be interested in this subset of Framework namespaces.
@@ -185,7 +185,7 @@ Other namespaces under `Magento\Framework` that will interest extension develope
### How Presentation code calls other layers
-Presentation code typically calls service contracts, particularly for a store front. However, presentation code is occasionally dependent on a specific implementation that requires the presentation code to directly call the business logic layer. For example, the Admin UI screens are often tightly linked a specific implementation and are not generic across implementations.
+Presentation code typically calls service contracts, particularly for a store front. However, presentation code is occasionally dependent on a specific implementation that requires the presentation code to directly call the business logic layer. For example, the {% glossarytooltip 29ddb393-ca22-4df9-a8d4-0024d75739b1 %}Admin{% endglossarytooltip %} UI screens are often tightly linked a specific implementation and are not generic across implementations.
## Service layer
@@ -197,17 +197,17 @@ In general, the service layer
* Contains service contracts, which define how the implementation will behave.
-* Provides an easy way to access the REST/SOAP API framework code (which also resides above the service contracts). You can bind service contracts to web service APIs in configuration files -- no coding required.
+* Provides an easy way to access the REST/SOAP {% glossarytooltip 786086f2-622b-4007-97fe-2c19e5283035 %}API{% endglossarytooltip %} framework code (which also resides above the service contracts). You can bind service contracts to web service APIs in configuration files -- no coding required.
* Provides a stable API for other modules to call into.
### Who accesses the service layer?
-All calls from web service interfaces, or users working with your storefront (that is, controller-initiated requests), are typically routed through the service layer. We strongly encourage the use of service contracts to call business logic.
+All calls from web service interfaces, or users working with your {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %} (that is, controller-initiated requests), are typically routed through the service layer. We strongly encourage the use of service contracts to call business logic.
-External applications can make requests for business logic with simple SOAP and REST calls. With some simple XML or JSON, you can expose the service layer's PHP API and make it accessible to REST or SOAP web services. Once implemented, a web service can make a single API call and return an information-rich data structure.
+External applications can make requests for business logic with simple SOAP and REST calls. With some simple {% glossarytooltip 8c0645c5-aa6b-4a52-8266-5659a8b9d079 %}XML{% endglossarytooltip %} or JSON, you can expose the service layer's PHP API and make it accessible to REST or SOAP web services. Once implemented, a web service can make a single API call and return an information-rich data structure.
-Service contract clients include:
+{% glossarytooltip cdf644c4-bc99-4550-a954-dd5ae165785a %}Service contract{% endglossarytooltip %} clients include:
* Controllers (initiated by actions of users of the storefront)
* Web services (SOAP and REST API calls)
@@ -215,7 +215,7 @@ Service contract clients include:
### Service contract anatomy
-The service contract of a module is defined by the set of interfaces in the module's `/Api`. It typically consists of:
+The service contract of a {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} is defined by the set of interfaces in the module's `/Api`. It typically consists of:
* service interfaces in the `/Api` namespace of the module
@@ -227,13 +227,13 @@ Typically, service contracts provide three distinct types of interfaces:
* Management interfaces
-* Metadata interfaces
+* {% glossarytooltip 3f0f2ef1-ad38-41c6-bd1e-390daaa71d76 %}Metadata{% endglossarytooltip %} interfaces
However, there is no requirement that service contracts conform to all three patterns.
### Advantages of service contracts
-Service contracts permit you to add a new customer extension that adds or changes business logic-level resource models and models without breaking the system. How? Through the use of the <preference> element of a dependency injection config file (`di.xml`) file. The `di.xml` file specifies which PHP class to use for the interface `Magento\Customer\Api\CustomerRepositoryInterface`.
+Service contracts permit you to add a new customer extension that adds or changes business logic-level resource models and models without breaking the system. How? Through the use of the <preference> element of a {% glossarytooltip 2be50595-c5c7-4b9d-911c-3bf2cd3f7beb %}dependency injection{% endglossarytooltip %} config file (`di.xml`) file. The `di.xml` file specifies which PHP class to use for the interface `Magento\Customer\Api\CustomerRepositoryInterface`.
Another module can change this interface file by specifying a different class name. However, if the client code uses the interface definition only, no class change is necessary.
diff --git a/guides/v2.0/architecture/archi_perspectives/area_intro.md b/guides/v2.0/architecture/archi_perspectives/area_intro.md
index aecae615d40..379bbc151ce 100644
--- a/guides/v2.0/architecture/archi_perspectives/area_intro.md
+++ b/guides/v2.0/architecture/archi_perspectives/area_intro.md
@@ -12,7 +12,7 @@ redirect_from: /guides/v1.0/architecture/archi_perspectives/area_intro.html
## Overview
-A Magento Area contains user-oriented functionality, which is responsible for managing user interaction with the system. It consists of components that provide a bridge into the core business logic encapsulated in the Domain (business logic) layer.
+A Magento Area contains user-oriented functionality, which is responsible for managing user interaction with the system. It consists of components that provide a bridge into the core business logic encapsulated in the {% glossarytooltip 41aee03b-a5d5-49c2-8839-894090ef4e86 %}Domain{% endglossarytooltip %} (business logic) layer.
— responsible for presentation layer components
@@ -20,7 +20,7 @@ A Magento Area contains user-oriented functionality, which is responsible for ma
— modules independent of area
-— when an area is disabled, then an entry point to module presentation is lost
+— when an area is disabled, then an entry point to {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} presentation is lost
### Magento area module structure
@@ -29,7 +29,7 @@ A Magento Area contains user-oriented functionality, which is responsible for ma
— area configuration
— area code
-The admin panel area serves for managing the store. The code of this area is adminhtml. Respectively, adminhtml subdirectory contains the view resources and Adminhtml subdirectory contains the controllers of the admin panel area.
+The {% glossarytooltip 29ddb393-ca22-4df9-a8d4-0024d75739b1 %}admin{% endglossarytooltip %} panel area serves for managing the store. The code of this area is {% glossarytooltip 749044c4-a002-4006-a3b8-eace2df90303 %}adminhtml{% endglossarytooltip %}. Respectively, adminhtml subdirectory contains the view resources and Adminhtml subdirectory contains the controllers of the admin panel area.
The resources visible and accessible in an area as well as area's behavior are defined by modules. The same module can influence several areas
diff --git a/guides/v2.0/architecture/archi_perspectives/components/AComponents.md b/guides/v2.0/architecture/archi_perspectives/components/AComponents.md
index 0586586a9e4..f176442fe6f 100644
--- a/guides/v2.0/architecture/archi_perspectives/components/AComponents.md
+++ b/guides/v2.0/architecture/archi_perspectives/components/AComponents.md
@@ -13,10 +13,10 @@ redirect_from: /guides/v1.0/architecture/components/AComponents.html
## Magento components
-Magento has several core components that are used to build custom web sites, applications, and integrated systems. When you change the appearance or behavior of your Magento store, you are inevitably changing one or more of these core Magento components, which include modules, themes, and language packages. Together, these core components determine much of server-side and storefront (frontend) appearance and behavior.
+Magento has several core components that are used to build custom web sites, applications, and integrated systems. When you change the appearance or behavior of your Magento store, you are inevitably changing one or more of these core Magento components, which include modules, themes, and language packages. Together, these core components determine much of server-side and {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %} (frontend) appearance and behavior.
-
Throughout the Magento documentation set, we also use the term component in its generic sense to mean element or part. However, the term Magento component explicitly refers to either a module, theme, or language package.
+
Throughout the Magento documentation set, we also use the term component in its generic sense to mean element or part. However, the term Magento component explicitly refers to either a module, theme, or {% glossarytooltip 9c4c7b9b-43f0-4454-8e8c-fb62ad40c35f %}language package{% endglossarytooltip %}.
For more information about individual Magento components, see:
diff --git a/guides/v2.0/architecture/archi_perspectives/components/arch_libraries.md b/guides/v2.0/architecture/archi_perspectives/components/arch_libraries.md
index 67a952b44fb..b6a04cadc20 100644
--- a/guides/v2.0/architecture/archi_perspectives/components/arch_libraries.md
+++ b/guides/v2.0/architecture/archi_perspectives/components/arch_libraries.md
@@ -14,19 +14,19 @@ redirect_from: /guides/v1.0/architecture/arch_libraries.html
Magento uses the following types of libraries:
-* Magento PHP libraries, which are discussed in the next section
+* Magento {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} libraries, which are discussed in the next section
* Magento UI libraries, which are located in the lib/web directory
For more information, see library documentation on GitHub and View Library.
-* Third-party libraries. These libraries include JavaScript libraries as well as PHP-based ones (including the Zend libraries).
+* Third-party libraries. These libraries include {% glossarytooltip 312b4baf-15f7-4968-944e-c814d53de218 %}JavaScript{% endglossarytooltip %} libraries as well as PHP-based ones (including the Zend libraries).
Third-party libraries are organized by vendor to be PSR-0 compliant.
## Magento PHP libraries {#m2arch-libraries-mage}
-Magento PHP libraries include independent libraries of code useful to a Magento application. Each library has minimal dependencies on other library.
+Magento PHP libraries include independent libraries of code useful to a Magento application. Each {% glossarytooltip 08968dbb-2eeb-45c7-ae95-ffca228a7575 %}library{% endglossarytooltip %} has minimal dependencies on other library.
For example:
diff --git a/guides/v2.0/architecture/archi_perspectives/components/arch_themes.md b/guides/v2.0/architecture/archi_perspectives/components/arch_themes.md
index 397bbf5928f..f1702ceee22 100644
--- a/guides/v2.0/architecture/archi_perspectives/components/arch_themes.md
+++ b/guides/v2.0/architecture/archi_perspectives/components/arch_themes.md
@@ -12,15 +12,15 @@ redirect_from: /guides/v1.0/architecture/arch_perspectives/themes_intro.html
## Overview
-A _theme_ is a core Magento component whose primary purpose is to control the appearance of your storefront. Themes use a combination of application elements, such as templates, layouts, styles, and images, and are highly extensible.
+A _theme_ is a core {% glossarytooltip 3425e9ae-5edf-4fc6-b645-06023e9e5e5b %}Magento component{% endglossarytooltip %} whose primary purpose is to control the appearance of your {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %}. Themes use a combination of application elements, such as templates, layouts, styles, and images, and are highly extensible.
-**Custom theme development is one of two main methods of modifying Magento behavior and storefront appearance** (extending modules is the other primary way, and the main way to tailor Magento behavior). Themes are the primary way to customize your Magento storefront appearance. Unlike modules, themes do not provide new business features (other than branding and web user experience).
+**Custom {% glossarytooltip d2093e4a-2b71-48a3-99b7-b32af7158019 %}theme{% endglossarytooltip %} development is one of two main methods of modifying Magento behavior and storefront appearance** (extending modules is the other primary way, and the main way to tailor Magento behavior). Themes are the primary way to customize your Magento storefront appearance. Unlike modules, themes do not provide new business features (other than branding and web user experience).
-Themes within a Magento installation relate to each other through _inheritance_, allowing you to customize an existing theme by defining it as a parent theme whose settings can be inherited by any designated child themes. Themes are also divided by area, allowing you to define themes that customize either the storefront or Magento Admin.
+Themes within a Magento installation relate to each other through _inheritance_, allowing you to customize an existing theme by defining it as a parent theme whose settings can be inherited by any designated child themes. Themes are also divided by area, allowing you to define themes that customize either the storefront or {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %}.
Magento 2.0 themes are also characterized by responsive web design. For more information on responsive design, see Overview of responsive web design in Magento.
-For detailed information about working with themes, refer to Themes in the Frontend Developers Guide.
+For detailed information about working with themes, refer to Themes in the {% glossarytooltip b00459e5-a793-44dd-98d5-852ab33fc344 %}Frontend{% endglossarytooltip %} Developers Guide.
## Theme location
@@ -34,7 +34,7 @@ In the Magento repository on GitHub, themes exist under `app/design/frontend`. F
### Location of themes when installing with Composer
-We recommend using Composer to install your Magento application and components such as modules or themes. Composer places the theme you are installing under `/vendor`. For example, `vendor/Magento/theme-frontend-blank` is the root directory of the Composer package holding the Blank theme.
+We recommend using {% glossarytooltip d85e2d0a-221f-4d03-aa43-0cda9f50809e %}Composer{% endglossarytooltip %} to install your Magento application and components such as modules or themes. Composer places the theme you are installing under `/vendor`. For example, `vendor/Magento/theme-frontend-blank` is the root directory of the {% glossarytooltip b57038ca-7906-4fce-a00f-d614b81d5301 %}Composer package{% endglossarytooltip %} holding the Blank theme.
### Location of custom themes
diff --git a/guides/v2.0/architecture/archi_perspectives/components/arch_translations.md b/guides/v2.0/architecture/archi_perspectives/components/arch_translations.md
index e8e0d91058b..cd074d2107e 100644
--- a/guides/v2.0/architecture/archi_perspectives/components/arch_translations.md
+++ b/guides/v2.0/architecture/archi_perspectives/components/arch_translations.md
@@ -12,17 +12,17 @@ redirect_from: /guides/v1.0/architecture/components/arch_translations.html
## Overview {#m2arch-translations-overview}
-Any text that is presented to the user can have several captions or labels on the control elements, notifications, and error messages. By default, Magento renders all these phrases in English (`US`) language (`en_US`). But if you deploy a storefront in a different language (or use the Magento Admin panel in a different language), you can incorporate other dictionaries for translations.
+Any text that is presented to the user can have several captions or labels on the control elements, notifications, and error messages. By default, Magento renders all these phrases in English (`US`) language (`en_US`). But if you deploy a {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %} in a different language (or use the {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %} panel in a different language), you can incorporate other dictionaries for translations.
You can use the language packages provided with Magento, create your own, or obtain packages from the community. Check out the language packages, modules, and themes available on Magento Marketplace.
-Creating a language package is part of the process of *localizing* your storefront.
+Creating a {% glossarytooltip 9c4c7b9b-43f0-4454-8e8c-fb62ad40c35f %}language package{% endglossarytooltip %} is part of the process of *localizing* your storefront.
## Magento language packages
A language package is a collection of translation dictionaries for a particular language together with additional information that tells Magento how to process the information, including:
-* `.csv` file contains the actual strings that comprise the language dictionary. A translation dictionary is a comma-separated value (`.csv`) file with at least two columns: the original phrase in the `en_US` locale and a translation of that phrase to another locale.
+* `.csv` file contains the actual strings that comprise the language dictionary. A translation dictionary is a comma-separated value (`.csv`) file with at least two columns: the original phrase in the `en_US` {% glossarytooltip 05099dbb-d491-4e33-a065-16035cb2d4d9 %}locale{% endglossarytooltip %} and a translation of that phrase to another locale.
* `composer.json` file contains any dependencies for the language package and a mapping to its defined locale.
diff --git a/guides/v2.0/architecture/archi_perspectives/components/modules/mod_anatomy.md b/guides/v2.0/architecture/archi_perspectives/components/modules/mod_anatomy.md
index b422897d9ea..4d2afc01bff 100644
--- a/guides/v2.0/architecture/archi_perspectives/components/modules/mod_anatomy.md
+++ b/guides/v2.0/architecture/archi_perspectives/components/modules/mod_anatomy.md
@@ -12,7 +12,7 @@ redirect: /guides/v2.0/architecture/modules/mod_anatomy.html
## Overview {#arch-modules-anatomy}
-A Magento module is a logical group of components that encapsulates a particular business function, typically a business task. All components of a module relate to the module's specific function. For example, each element of the Shipping module contains all the code and interfaces needed to implement core shipping-related tasks. A module directory typically contains blocks, controllers, helpers, models, configuration files, and other components that contribute to the module's core purpose.
+A Magento module is a logical group of components that encapsulates a particular business function, typically a business task. All components of a {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} relate to the module's specific function. For example, each element of the Shipping module contains all the code and interfaces needed to implement core shipping-related tasks. A module directory typically contains blocks, controllers, helpers, models, configuration files, and other components that contribute to the module's core purpose.
Module structure is defined by both module code components and logical structure.
@@ -20,23 +20,23 @@ Module structure is defined by both module code components and logical structure
All types of modules contain the following core elements, categorized by directory:
-* `/block`
+* `/Block`
-* `/controllers`
+* `/Controller`
* `/etc`
-* `/helper`
+* `/Helper`
-* `/model`
+* `/Model`
-* `/sql`
+* `/Setup`
### Block
-Blocks help provide the data used in the View component of the module structure. Blocks coordinate models with the template files. The files in this folder load the data from database and transfer it to the templates in your theme (`PHTML` files).
+Blocks help provide the data used in the View component of the module structure. Blocks coordinate models with the template files. The files in this folder load the data from database and transfer it to the templates in your {% glossarytooltip d2093e4a-2b71-48a3-99b7-b32af7158019 %}theme{% endglossarytooltip %} (`PHTML` files).
-### Controllers
+### Controller
Controllers represent all business logic actions for the given request. These actions include `dispatch()`, `preDispatch()`, `postDispatch()` methods and delegate commands to other parts of the system. Controllers correspond to the Controller portion of the Model-View-Controller model.
@@ -58,7 +58,23 @@ Magento 2.x looks for configuration information for each module in that module's
* webapi.xml
-Configuration files that are in the top level of that module's `/etc` directory are global to that component. Configuration files placed in subdirectories (`adminhtml`, `frontend`, `webapi_rest`, `webapi_soap`) apply only to those respective functional areas.
+* system.xml
+
+* {% glossarytooltip 749044c4-a002-4006-a3b8-eace2df90303 %}adminhtml{% endglossarytooltip %}.xml
+
+* events.xml
+
+* page_types.xml
+
+* routes.xml
+
+* sections.xml
+
+* email_templates.xml
+
+* fieldset.xml
+
+Configuration files that are in the top level of that module's `/etc` directory are global to that component. Configuration files placed in subdirectories (`adminhtml`, `frontend`, `webapi_rest`, `webapi_soap`, `crontab`) apply only to those respective functional areas.
The specific set of configuration files that your module requires depends on the module's purpose and the Magento area in which it functions.
@@ -77,8 +93,8 @@ In a typical Model-View-Controller-based application, models are used to connect
A Magento model object contains a reference to a resource model, which it uses to load its data. There's an individual resource model object for each model object. For example, a Product Model has a Product resource model.
-### sql
-Structures in this directory handle any custom database tables that are used by the module and process all upgrades to the extension.
+### Setup
+Structures in this directory handle any custom database tables that are used by the module and process all upgrades to the {% glossarytooltip 55774db9-bf9d-40f3-83db-b10cc5ae3b68 %}extension{% endglossarytooltip %}.
## Related topics {#arch-modules-related}
diff --git a/guides/v2.0/architecture/archi_perspectives/components/modules/mod_and_areas.md b/guides/v2.0/architecture/archi_perspectives/components/modules/mod_and_areas.md
index 300a0292052..e8690c0e65f 100644
--- a/guides/v2.0/architecture/archi_perspectives/components/modules/mod_and_areas.md
+++ b/guides/v2.0/architecture/archi_perspectives/components/modules/mod_and_areas.md
@@ -18,29 +18,29 @@ redirect_from:
An *area* is a logical component that organizes code for optimized request processing. Magento uses areas to streamline web service calls by loading only the dependent code for the specified area. Each of the default areas defined by Magento can contain completely different code on how to process URLs and requests.
-For example, if you are invoking a REST web service call, rather than load all the code related to generating user HTML pages, you can specify a separate area that loads code whose scope is limited to answering REST calls.
+For example, if you are invoking a REST web service call, rather than load all the code related to generating user {% glossarytooltip a2aff425-07dd-4bd6-9671-29b7edefa871 %}HTML{% endglossarytooltip %} pages, you can specify a separate area that loads code whose scope is limited to answering REST calls.
### Magento area types
Magento is organized into these main areas:
-* **Magento Admin** (`adminhtml`): entry point for this area is `index.php` or `pub/index.php`. The Admin panel area includes the code needed for store management. The /app/design/adminhtml directory contains all the code for components you'll see while working in the Admin panel.
+* **Magento Admin** (`adminhtml`): entry point for this area is `index.php` or `pub/index.php`. The {% glossarytooltip 29ddb393-ca22-4df9-a8d4-0024d75739b1 %}Admin{% endglossarytooltip %} panel area includes the code needed for store management. The /app/design/adminhtml directory contains all the code for components you'll see while working in the Admin panel.
-* **Storefront** (`frontend`): entry point for this area is `index.php` or `pub/index.php`. The storefront (or `frontend`) contains template and layout files that define the appearance of your storefront.
+* **Storefront** (`frontend`): entry point for this area is `index.php` or `pub/index.php`. The storefront (or `frontend`) contains template and {% glossarytooltip 73ab5daa-5857-4039-97df-11269b626134 %}layout{% endglossarytooltip %} files that define the appearance of your {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %}.
* **Basic** (`base`): used as a fallback for files absent in `adminhtml` and `frontend` areas.
You can also send requests to Magento using the SOAP and REST APIs. These two areas
-* **Web API REST** (`webapi_rest`): entry point for this area is `index.php` or `pub/index.php`. The REST area has a front controller that understands how to do URL lookups for REST-based URLs.
+* **Web API REST** (`webapi_rest`): entry point for this area is `index.php` or `pub/index.php`. The REST area has a front controller that understands how to do {% glossarytooltip a05c59d3-77b9-47d0-92a1-2cbffe3f8622 %}URL{% endglossarytooltip %} lookups for REST-based URLs.
* **Web API SOAP** (`webapi_soap`): entry point for this area is `index.php` or `pub/index.php`.
## How areas work with modules {#m2arch-module-using}
-Modules define which resources are visible and accessible in an area, as well as an area's behavior. The same module can influence several areas. For instance, the RMA module is represented partly in the `adminhtml` area and partly in the `frontend` area.
+Modules define which resources are visible and accessible in an area, as well as an area's behavior. The same {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} can influence several areas. For instance, the RMA module is represented partly in the `adminhtml` area and partly in the `frontend` area.
-If your extension works in several different areas, ensure it has separate behavior and view components for each area.
+If your {% glossarytooltip 55774db9-bf9d-40f3-83db-b10cc5ae3b68 %}extension{% endglossarytooltip %} works in several different areas, ensure it has separate behavior and view components for each area.
Each area declares itself within a module. All resources specific for an area are located within the same module as well.
@@ -52,13 +52,13 @@ You can enable or disable an area within a module. If this module is enabled, it
* Disabling an area does not result in disabling the modules related to it.
-* Areas are registered in the Dependency Injection framework `di.xml` file.
+* Areas are registered in the {% glossarytooltip 2be50595-c5c7-4b9d-911c-3bf2cd3f7beb %}Dependency Injection{% endglossarytooltip %} framework `di.xml` file.
### Note about Magento request processing
Magento processes a URL request by first stripping off the base URL. The first path segment of the remaining URL identifies the request area.
-After the area name, the URI segment specifies the *full front name*. When an HTTP request arrives, the handle is extracted from the URL. Magento uses the handle to identify which controller (a PHP class) and action (a PHP method in the class) to execute. A common action to display a HTML page is `index`, which returns an HTML page.
+After the area name, the URI segment specifies the *full front name*. When an HTTP request arrives, the handle is extracted from the URL. Magento uses the handle to identify which controller (a {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} class) and action (a PHP method in the class) to execute. A common action to display a HTML page is `index`, which returns an HTML page.
## Related topics {#m2arch-module-related}
diff --git a/guides/v2.0/architecture/archi_perspectives/components/modules/mod_conventions.md b/guides/v2.0/architecture/archi_perspectives/components/modules/mod_conventions.md
index fe1557b45ed..03872d11bc3 100644
--- a/guides/v2.0/architecture/archi_perspectives/components/modules/mod_conventions.md
+++ b/guides/v2.0/architecture/archi_perspectives/components/modules/mod_conventions.md
@@ -24,7 +24,7 @@ Be sure to research additional Magento conventions, beyond those applicable to m
The following table shows the *recommended* location within the Magento file system for specific components.
-(A module must include a `registration.php` file in its root folder.)
+(A {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} must include a `registration.php` file in its root folder.)
We refer to a component's root directory as the top-level directory in which you develop component code. Typically, this directory is located in one of the following directories relative to the Magento root directory:
diff --git a/guides/v2.0/architecture/archi_perspectives/components/modules/mod_depend.md b/guides/v2.0/architecture/archi_perspectives/components/modules/mod_depend.md
index 39e52c92536..0cabf418da2 100644
--- a/guides/v2.0/architecture/archi_perspectives/components/modules/mod_depend.md
+++ b/guides/v2.0/architecture/archi_perspectives/components/modules/mod_depend.md
@@ -18,7 +18,7 @@ redirect_from:
A *software dependency* identifies one software component's reliance on another for proper functioning. A core principle of Magento architecture is the **minimization of software dependencies**. Instead of being closely interrelated with other modules, modules are optimally designed to be loosely coupled. Loosely coupled modules require little or no knowledge of other modules to perform their tasks.
-Each Magento module is responsible for a unique feature. In practice, this means that:
+Each Magento {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} is responsible for a unique feature. In practice, this means that:
* Several modules cannot be responsible for one feature.
@@ -34,9 +34,9 @@ Although Magento architecture favors loosely coupled software components, module
* other modules
-* PHP extensions
+* {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} extensions
-* libraries (either Magento Framework library or third party libraries)
+* libraries (either Magento Framework {% glossarytooltip 08968dbb-2eeb-45c7-ae95-ffca228a7575 %}library{% endglossarytooltip %} or third party libraries)
Note: You can lose the historical information contained in a module if the module is removed or disabled. We recommend alternative storage of module information before you remove or disable a module.
diff --git a/guides/v2.0/architecture/archi_perspectives/components/modules/mod_depend_types.md b/guides/v2.0/architecture/archi_perspectives/components/modules/mod_depend_types.md
index 25039ebbef6..2cbb165f952 100644
--- a/guides/v2.0/architecture/archi_perspectives/components/modules/mod_depend_types.md
+++ b/guides/v2.0/architecture/archi_perspectives/components/modules/mod_depend_types.md
@@ -14,7 +14,7 @@ redirect_from: /guides/v1.0/architecture/modules/mod_depend_types.html
## Two types of dependencies {#m2devgde-moddep-declare-dep}
-There are two types of Magento module dependencies: hard and soft dependencies.
+There are two types of Magento {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} dependencies: hard and soft dependencies.
## Hard dependencies
@@ -36,7 +36,7 @@ Modules with a *soft dependency* on another module can function properly without
* The module extends another module's configuration.
-* The module extends another module's layout.
+* The module extends another module's {% glossarytooltip 73ab5daa-5857-4039-97df-11269b626134 %}layout{% endglossarytooltip %}.
@@ -76,7 +76,7 @@ Modules belonging to the Magento Framework can be used in the application layer
## Dependencies in the Application layer {#m2devgde-moddep-app-layer}
Modules belonging to the application layer cannot be used in the Magento Framework.
-You can build dependencies between classes in the application layer, but these classes must belong to the same module. Dependencies between the modules of the application layer should be built only by the service contract or the service provider interface (SPI).
+You can build dependencies between classes in the application layer, but these classes must belong to the same module. Dependencies between the modules of the application layer should be built only by the {% glossarytooltip cdf644c4-bc99-4550-a954-dd5ae165785a %}service contract{% endglossarytooltip %} or the service provider interface (SPI).
## Related topics {#m2arch-module-related}
diff --git a/guides/v2.0/architecture/archi_perspectives/components/modules/mod_intro.md b/guides/v2.0/architecture/archi_perspectives/components/modules/mod_intro.md
index 9db60113c1e..b4d0472cfcf 100644
--- a/guides/v2.0/architecture/archi_perspectives/components/modules/mod_intro.md
+++ b/guides/v2.0/architecture/archi_perspectives/components/modules/mod_intro.md
@@ -16,11 +16,11 @@ redirect_from:
## What is a Magento module? {#arch-modules-overview}
-A module is a logical group -- that is, a directory containing blocks, controllers, helpers, models -- that are related to a specific business feature. In keeping with Magento's commitment to optimal modularity, a module encapsulates one feature and has minimal dependencies on other modules.
+A module is a logical group -- that is, a directory containing blocks, controllers, helpers, models -- that are related to a specific business feature. In keeping with Magento's commitment to optimal modularity, a {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} encapsulates one feature and has minimal dependencies on other modules.
-Modules and themes are the units of customization in Magento. Modules provide business features, with supporting logic, while themes strongly influence user experience and storefront appearance. Both components have a life cycle that allows them to be installed, deleted, and disabled. From the perspective of both merchants and extension developers, modules are the central unit of Magento organization.
+Modules and themes are the units of customization in Magento. Modules provide business features, with supporting logic, while themes strongly influence user experience and {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %} appearance. Both components have a life cycle that allows them to be installed, deleted, and disabled. From the perspective of both merchants and {% glossarytooltip 55774db9-bf9d-40f3-83db-b10cc5ae3b68 %}extension{% endglossarytooltip %} developers, modules are the central unit of Magento organization.
-The Magento Framework provides a set of core logic: PHP code, libraries, and the basic functions that are inherited by the modules and other components.
+The Magento Framework provides a set of core logic: {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} code, libraries, and the basic functions that are inherited by the modules and other components.
## Module purpose
@@ -28,7 +28,7 @@ The purpose of each module is to provide specific product features by implementi
## Module components
-A module is a directory that contains the PHP and XML files (blocks, controllers, helpers, models) that are related to a specific business feature, such as Shipping. Specifically, a Magento module is composed of these software components: themes, libraries, and language packages.
+A module is a directory that contains the PHP and {% glossarytooltip 8c0645c5-aa6b-4a52-8266-5659a8b9d079 %}XML{% endglossarytooltip %} files (blocks, controllers, helpers, models) that are related to a specific business feature, such as Shipping. Specifically, a Magento module is composed of these software components: themes, libraries, and language packages.
See Module anatomy for an overview of module structure.
diff --git a/guides/v2.0/architecture/archi_perspectives/components/modules/mod_relationships.md b/guides/v2.0/architecture/archi_perspectives/components/modules/mod_relationships.md
index b523951aed9..5b8163c11d3 100644
--- a/guides/v2.0/architecture/archi_perspectives/components/modules/mod_relationships.md
+++ b/guides/v2.0/architecture/archi_perspectives/components/modules/mod_relationships.md
@@ -16,19 +16,19 @@ redirect_from:
## Overview {#m2arch-module-relationships-overview}
-Understanding how one module relates to another helps determine how it reacts to changes in that module.
+Understanding how one {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} relates to another helps determine how it reacts to changes in that module.
A single module can have the following types of relationships with another module:
* **uses**: module A uses module B if it invokes behavior of module B
-* **reacts to**: module A reacts to module B if its behavior is triggered by an event in module B without module B knowing about module A
+* **reacts to**: module A reacts to module B if its behavior is triggered by an {% glossarytooltip c57aef7c-97b4-4b2b-a999-8001accef1fe %}event{% endglossarytooltip %} in module B without module B knowing about module A
* **customizes**: module A customizes module B if it modifies the behavior of module B
* **implements**: module A implements module B if it implements some, not necessarily all, behavior that is defined in module B
-* **replaces**: module A replaces module B if it provides its own version of the API exposed and implemented by module B
+* **replaces**: module A replaces module B if it provides its own version of the {% glossarytooltip 786086f2-622b-4007-97fe-2c19e5283035 %}API{% endglossarytooltip %} exposed and implemented by module B
## Relationship types and scenarios
diff --git a/guides/v2.0/architecture/archi_perspectives/controllers_intro.md b/guides/v2.0/architecture/archi_perspectives/controllers_intro.md
index 747d267696a..73acabae3e4 100644
--- a/guides/v2.0/architecture/archi_perspectives/controllers_intro.md
+++ b/guides/v2.0/architecture/archi_perspectives/controllers_intro.md
@@ -28,7 +28,7 @@ Layouts have output blocks
### Magento Front Controller
-Front controller design pattern has two parts
+Front controller {% glossarytooltip 53755359-9916-4677-bff2-f7d26025095a %}design pattern{% endglossarytooltip %} has two parts
Tasks are highly limited, restricted to routing and dispatching.
diff --git a/guides/v2.0/architecture/archi_perspectives/domain_layer.md b/guides/v2.0/architecture/archi_perspectives/domain_layer.md
index 3e20c4f568b..2ba71bf3cb0 100644
--- a/guides/v2.0/architecture/archi_perspectives/domain_layer.md
+++ b/guides/v2.0/architecture/archi_perspectives/domain_layer.md
@@ -12,7 +12,7 @@ redirect_from: /guides/v1.0/architecture/archi_perspectives/domain_layer.html
## What is Magento Domain layer?
-The domain layer holds the business logic layer of a Magento module. It typically does not contain resource-specific or database-specific information. Its primary functions include:
+The {% glossarytooltip 41aee03b-a5d5-49c2-8839-894090ef4e86 %}domain{% endglossarytooltip %} layer holds the business logic layer of a Magento {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %}. It typically does not contain resource-specific or database-specific information. Its primary functions include:
* Defining the generic Magento data objects, or models, that contain business logic. This logic defines which operations can be performed on particular types of data, such as a Customer object. These models contain generic information only. Applications can also use SOAP or RESTful endpoints to request data from models.
diff --git a/guides/v2.0/architecture/archi_perspectives/framework.md b/guides/v2.0/architecture/archi_perspectives/framework.md
index 5f4e65c7856..f04423eed8a 100644
--- a/guides/v2.0/architecture/archi_perspectives/framework.md
+++ b/guides/v2.0/architecture/archi_perspectives/framework.md
@@ -12,10 +12,10 @@ redirect_from: /guides/v1.0/architecture/archi_perspectives/framework.html
## Overview
-The Magento Framework controls how application components interact, including request flow, routing, indexing, caching, and exception handling. It provides services that reduce the effort of creating modules that contain business logic, contributing to the goal of both making Magento code more modular as well as decreasing dependencies.
+The Magento Framework controls how application components interact, including request flow, routing, indexing, caching, and {% glossarytooltip 53da11f1-d0b8-4a7e-b078-1e099462b409 %}exception{% endglossarytooltip %} handling. It provides services that reduce the effort of creating modules that contain business logic, contributing to the goal of both making Magento code more modular as well as decreasing dependencies.
-This primarily PHP software component is organized into logical groups called libraries, which all modules can call. Most of the framework code sits under the domain layer or encloses the presentation, service, and domain layers. The framework contains no business logic.
-(Although the Magento Framework does not contain resource models, it does contain a library of code to help implement a resource model.)
+This primarily {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} software component is organized into logical groups called libraries, which all modules can call. Most of the framework code sits under the {% glossarytooltip 41aee03b-a5d5-49c2-8839-894090ef4e86 %}domain{% endglossarytooltip %} layer or encloses the presentation, service, and domain layers. The framework contains no business logic.
+(Although the Magento Framework does not contain resource models, it does contain a {% glossarytooltip 08968dbb-2eeb-45c7-ae95-ffca228a7575 %}library{% endglossarytooltip %} of code to help implement a resource model.)
Don't confuse the Magento framework with the Zend web application framework that ships with Magento.
@@ -46,19 +46,19 @@ Lib/
../Framework
-* `/lib/internal` contains some non-PHP as well as PHP components. Non-PHP framework libraries includes JavaScript and LESS/CSS.
+* `/lib/internal` contains some non-PHP as well as PHP components. Non-PHP framework libraries includes {% glossarytooltip 312b4baf-15f7-4968-944e-c814d53de218 %}JavaScript{% endglossarytooltip %} and LESS/CSS.
-* `/lib/internal/Magento/Framework` contains only PHP code. These are libraries of code plus the application entry point that routes requests to modules (that in turn call the framework libraries). For example, libraries in the framework help implement a resource model (base classes and interfaces to inherit from) but not the resource models themselves. Certain libraries also support CSS rendering.
+* `/lib/internal/Magento/Framework` contains only PHP code. These are libraries of code plus the application entry point that routes requests to modules (that in turn call the framework libraries). For example, libraries in the framework help implement a resource model (base classes and interfaces to inherit from) but not the resource models themselves. Certain libraries also support {% glossarytooltip 6c5cb4e9-9197-46f2-ba79-6147d9bfe66d %}CSS{% endglossarytooltip %} rendering.
* `/lib/web` contains JavaScript and CSS/LESS files. These files reside under `web` and not `internal` because they are accessible from a web browser, while the PHP code under `internal` is not. (Any code that a web browser must access should be under `web`, while everything else under `internal`.)
-
The lib/internal/Magento/Framework directory maps to the Magento\Framework namespace.
+
The lib/internal/Magento/Framework directory maps to the Magento\Framework {% glossarytooltip 621ef86b-7314-4fbc-a80d-ab7fa45a27cb %}namespace{% endglossarytooltip %}.
## Highlights of Magento Framework
-The Magento Framework (`lib/internal/Magento/Framework/`) provides a robust range of functionality. If you are an extension developer, you may be interested in this subset of Framework namespaces.
+The Magento Framework (`lib/internal/Magento/Framework/`) provides a robust range of functionality. If you are an {% glossarytooltip 55774db9-bf9d-40f3-83db-b10cc5ae3b68 %}extension{% endglossarytooltip %} developer, you may be interested in this subset of Framework namespaces.
diff --git a/guides/v2.0/architecture/archi_perspectives/present_layer.md b/guides/v2.0/architecture/archi_perspectives/present_layer.md
index db8f0fb897c..d10b8417a11 100644
--- a/guides/v2.0/architecture/archi_perspectives/present_layer.md
+++ b/guides/v2.0/architecture/archi_perspectives/present_layer.md
@@ -12,7 +12,7 @@ redirect_from: /guides/v1.0/architecture/archi_perspectives/present_layer.html
## What is Magento Presentation layer?
-When you interact with the Magento web interface, you are directly working with *presentation layer* code. The presentation layer contains both view elements (layouts, blocks, templates) and controllers, which process commands to and from the user interface. Presentation code controls web user interaction with the product and its appearance. You can extensively customize the user interface by using HTML, CSS, and PHTML files to modify elements of the presentation layer.
+When you interact with the Magento web interface, you are directly working with *presentation layer* code. The presentation layer contains both view elements (layouts, blocks, templates) and controllers, which process commands to and from the user interface. Presentation code controls web user interaction with the product and its appearance. You can extensively customize the user interface by using HTML, CSS, and {% glossarytooltip ae0f1f68-c466-4189-88fd-6cd8b23c804f %}PHTML{% endglossarytooltip %} files to modify elements of the presentation layer.
## Who uses the presentation layer?
@@ -20,25 +20,25 @@ Three types of Magento users interact with presentation layer code. Magento uses
* **Web users** interact with the store front, where they can see the View model of data displayed by Magento and interact with product UI elements to request data for view and manipulation. These users work within the (`frontend`) area.
-* **System administrators** customizing a storefront can indirectly manipulate the presentation layer by, for example, adding themes or widgets to the front end.
+* **System administrators** customizing a {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %} can indirectly manipulate the presentation layer by, for example, adding themes or widgets to the front end.
-* **Web API calls** can be made through HTTP just like browser requests, and can be made via AJAX calls from the user interface.
+* **Web {% glossarytooltip 786086f2-622b-4007-97fe-2c19e5283035 %}API{% endglossarytooltip %} calls** can be made through HTTP just like browser requests, and can be made via AJAX calls from the user interface.
## Presentation layer components
One helpful way of understanding the Magento presentation layer components is by examining Magento themes. Magento themes organize both the visual aspect of your storefront and certain aspects of product behavior.
-Each theme resides in a unique directory and contains custom page layouts, templates, skins, and language files that work together to create a distinct user experience.
+Each {% glossarytooltip d2093e4a-2b71-48a3-99b7-b32af7158019 %}theme{% endglossarytooltip %} resides in a unique directory and contains custom page layouts, templates, skins, and language files that work together to create a distinct user experience.
For an extensive introduction to theme elements and an overview of how to extend and override the default Magento themes, see the Frontend Developer Guide.
## View model
-Magento generates the HTML for a page to display to a user from a tree of view elements.
+Magento generates the {% glossarytooltip a2aff425-07dd-4bd6-9671-29b7edefa871 %}HTML{% endglossarytooltip %} for a page to display to a user from a tree of view elements.
View elements fall into two main categories: blocks and containers.
-* **Blocks** can generate dynamic content and can contain named child view elements that are similar to arguments being passed in. (The `as` attribute holds the child view element names for the parent block to reference them)
+* **Blocks** can generate {% glossarytooltip f7550977-2132-4155-a5e0-d000fcfea866 %}dynamic content{% endglossarytooltip %} and can contain named child view elements that are similar to arguments being passed in. (The `as` attribute holds the child view element names for the parent block to reference them)
* **Containers** collect an ordered group of children view elements.
@@ -46,13 +46,13 @@ The browser forms a product web page by asking the view element tree to render i
## How Presentation code calls other layers
-Presentation code typically calls service contracts, particularly for a store front. However, presentation code is occasionally dependent on a specific implementation that requires the presentation code to directly call the business logic layer. For example, the Admin UI screens are often tightly linked to a specific implementation and are not generic across implementations.
+Presentation code typically calls service contracts, particularly for a store front. However, presentation code is occasionally dependent on a specific implementation that requires the presentation code to directly call the business logic layer. For example, the {% glossarytooltip 29ddb393-ca22-4df9-a8d4-0024d75739b1 %}Admin{% endglossarytooltip %} UI screens are often tightly linked to a specific implementation and are not generic across implementations.
The View layer calls code from the Model to get information about the state of the application (for example, the price of a product). Typically, the way it accesses the Model is through service contracts.
## Presentation layer flow
-Web users interact with components of the presentation layer to select actions that initiate calls to the underlying product layers. Presentation layer components make calls to the Service layer, which in turn sends requests to the Domain (or business logic) layer.
+Web users interact with components of the presentation layer to select actions that initiate calls to the underlying product layers. Presentation layer components make calls to the Service layer, which in turn sends requests to the {% glossarytooltip 41aee03b-a5d5-49c2-8839-894090ef4e86 %}Domain{% endglossarytooltip %} (or business logic) layer.
## Related topics {#related}
diff --git a/guides/v2.0/architecture/archi_perspectives/service_layer.md b/guides/v2.0/architecture/archi_perspectives/service_layer.md
index ee622226f29..5046697bd5d 100644
--- a/guides/v2.0/architecture/archi_perspectives/service_layer.md
+++ b/guides/v2.0/architecture/archi_perspectives/service_layer.md
@@ -12,7 +12,7 @@ redirect_from: /guides/v1.0/architecture/archi_perspectives/service_layer.html
## What is a Service layer?
-The service layer provides a bridge between the presentation layer and the model layer of domain logic and resource-specific data. This is implemented using *service contracts*, which are defined using PHP interfaces.
+The service layer provides a bridge between the presentation layer and the model layer of {% glossarytooltip 41aee03b-a5d5-49c2-8839-894090ef4e86 %}domain{% endglossarytooltip %} logic and resource-specific data. This is implemented using *service contracts*, which are defined using {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} interfaces.
In general, the service layer:
@@ -20,17 +20,17 @@ In general, the service layer:
* Contains service contracts, which define how the implementation will behave.
-* Provides an easy way to access the REST/SOAP API framework code (which also resides above the service contracts). You can bind service contracts to web service APIs in configuration files --- no coding required.
+* Provides an easy way to access the REST/SOAP {% glossarytooltip 786086f2-622b-4007-97fe-2c19e5283035 %}API{% endglossarytooltip %} framework code (which also resides above the service contracts). You can bind service contracts to web service APIs in configuration files --- no coding required.
* Provides a stable API for other modules to call into.
## Who accesses the service layer?
-All calls from web service interfaces, or users working with your storefront (that is, controller-initiated requests), are typically routed through the service layer. We strongly encourage the use of service contracts to call business logic.
+All calls from web service interfaces, or users working with your {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %} (that is, controller-initiated requests), are typically routed through the service layer. We strongly encourage the use of service contracts to call business logic.
-External applications can make requests for business logic with simple SOAP and REST calls. With some simple XML or JSON, you can expose the service layer's PHP API and make it accessible to REST or SOAP web services. Once implemented, a web service can make a single API call and return an information-rich data structure.
+External applications can make requests for business logic with simple SOAP and REST calls. With some simple {% glossarytooltip 8c0645c5-aa6b-4a52-8266-5659a8b9d079 %}XML{% endglossarytooltip %} or JSON, you can expose the service layer's PHP API and make it accessible to REST or SOAP web services. Once implemented, a web service can make a single API call and return an information-rich data structure.
-Service contract clients include:
+{% glossarytooltip cdf644c4-bc99-4550-a954-dd5ae165785a %}Service contract{% endglossarytooltip %} clients include:
* Controllers (initiated by actions of users of the storefront)
@@ -40,9 +40,9 @@ Service contract clients include:
## Service contract anatomy
-The service contract of a module is defined by the set of interfaces in the module's `/Api`. It typically consists of:
+The service contract of a {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} is defined by the set of interfaces in the module's `/Api`. It typically consists of:
-* service interfaces in the `/Api` namespace of the module
+* service interfaces in the `/Api` {% glossarytooltip 621ef86b-7314-4fbc-a80d-ab7fa45a27cb %}namespace{% endglossarytooltip %} of the module
* data (or *entity*) interfaces in the `Api/Data` directory. *Data entities* are data structures passed to and returned from service interfaces.
@@ -52,13 +52,13 @@ Typically, service contracts provide three distinct types of interfaces:
* Management interfaces
-* Metadata interfaces
+* {% glossarytooltip 3f0f2ef1-ad38-41c6-bd1e-390daaa71d76 %}Metadata{% endglossarytooltip %} interfaces
However, there is no requirement that service contracts conform to all three patterns.
## Advantages of service contracts
-Service contracts permit you to add a new customer extension that adds or changes business logic-level resource models and models without breaking the system. How? Through the use of the *<preference>* element of a dependency injection config file (`di.xml`) file. The `di.xml` file specifies which PHP class to use for the interface `Magento\Customer\Api\CustomerRepositoryInterface`.
+Service contracts permit you to add a new customer {% glossarytooltip 55774db9-bf9d-40f3-83db-b10cc5ae3b68 %}extension{% endglossarytooltip %} that adds or changes business logic-level resource models and models without breaking the system. How? Through the use of the *<preference>* element of a {% glossarytooltip 2be50595-c5c7-4b9d-911c-3bf2cd3f7beb %}dependency injection{% endglossarytooltip %} config file (`di.xml`) file. The `di.xml` file specifies which PHP class to use for the interface `Magento\Customer\Api\CustomerRepositoryInterface`.
Another module can change this interface file by specifying a different class name. However, if the client code uses the interface definition only, no class change is necessary.
diff --git a/guides/v2.0/architecture/archi_perspectives/themes_intro.md b/guides/v2.0/architecture/archi_perspectives/themes_intro.md
index 927809534d2..c0f8561e198 100644
--- a/guides/v2.0/architecture/archi_perspectives/themes_intro.md
+++ b/guides/v2.0/architecture/archi_perspectives/themes_intro.md
@@ -1,5 +1,3 @@
-
-
---
layout: default
group: arch-guide
@@ -12,48 +10,54 @@ github_link: architecture/archi_perspectives/themes_intro.md
redirect_from: /guides/v1.0/architecture/archi_perspectives/themes_intro.html
---
-## Overview
+## Introduction
-A theme is a component of Magento application that provides a consistent look and feel (visual design) for entire application area (for example, storefront or Magento admin) using a combination of custom templates, layouts, styles or images.
+A {% glossarytooltip d2093e4a-2b71-48a3-99b7-b32af7158019 %}theme{% endglossarytooltip %} is a component of Magento application that provides a consistent look and feel (visual design) for entire application area (for example, {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %} or Magento admin) using a combination of custom templates, layouts, styles or images.
Out-of-the-box Magento application provides two design themes: Luma, as a demonstration theme, and Blank as a basis for custom theme creation.
-All theme files are stored under app/design////.
+All theme files are stored under `app/design////`.
-Apart from the configuration file and theme metadata file, all theme files fall into the following two categories:
+Apart from the configuration file and theme {% glossarytooltip 3f0f2ef1-ad38-41c6-bd1e-390daaa71d76 %}metadata{% endglossarytooltip %} file, all theme files fall into the following two categories:
-* Static view files are a set of theme files that are returned by the server to a browser as is, without any processing, are called the static files of a theme.
+* Static view files are a set of theme files that are returned by the server to a browser as is, without any processing, are called the {% glossarytooltip 363662cb-73f1-4347-a15e-2d2adabeb0c2 %}static files{% endglossarytooltip %} of a theme.
-* Dynamic view files are view files that are processed or executed by the server in order to provide result to the client. These are: .less files, templates, layouts .
+* Dynamic view files are view files that are processed or executed by the server in order to provide result to the client.
+ These are: .less files, templates, layouts .
Design packets are collections of related themes plus nondefault variants.
-Magento supports multi theme model. . Themes are highly extensible.
+Magento supports multi theme model.
+Themes are highly extensible.
-control
+## Control
-1) the visual aspect of site design (skinning). Includes CSS, images, design/UI- specific Javascript
-2) also control many functional aspects of site. Layouts control which default blocks/modules are available
+1) the visual aspect of site design (skinning).
+Includes CSS, images, design/UI- specific {% glossarytooltip 312b4baf-15f7-4968-944e-c814d53de218 %}Javascript{% endglossarytooltip %}
+2) also control many functional aspects of site.
+Layouts control which default blocks/modules are available
Templates control which data is shown and how
-No business logic included in themes.
+Themes do not include business logic.
-### Theme components
+## Theme components
Magento theme components include:
-Layout: layout XML files. This defines which template file to load.
+* Layout: {% glossarytooltip 73ab5daa-5857-4039-97df-11269b626134 %}layout{% endglossarytooltip %} {% glossarytooltip 8c0645c5-aa6b-4a52-8266-5659a8b9d079 %}XML{% endglossarytooltip %} files.
+This defines which template file to load.
-Template: template files which are generally .phtml files.
+* Template: template files which are generally .phtml files.
-Skin: static files like images, css and js.
+* Skin: static files like images, {% glossarytooltip 6c5cb4e9-9197-46f2-ba79-6147d9bfe66d %}css{% endglossarytooltip %} and js.
-Local: language related file. This will be used when you want to make your theme compatible with different languages.
+* Locale: language related file.
+This will be used when you want to make your theme compatible with different languages.
-### Theme process flow
+## Theme process flow
-Process flow:
+### Process flow
In general Magento's fallback technique for theme is as below:
@@ -61,19 +65,22 @@ Your Custom Package >> Default Package >> Base Package >> Error Message
From above hierarchy you can imagine that if any of the requested file is not available in your theme then it will look for default package first and after that look into Base package and at last it will show error message if requested file is not available in any of the package.
-Theme inheritance based on the fallback mechanism, which guarantees that if a view file is not found in the current theme, the system searches in the ancestor themes, module view files or library
+Theme inheritance based on the fallback mechanism, which guarantees that if a view file is not found in the current theme, the system searches in the ancestor themes, {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} view files or {% glossarytooltip 08968dbb-2eeb-45c7-ae95-ffca228a7575 %}library{% endglossarytooltip %}
-— page templates
-— block templates
-— layouts
+* page templates
+* block templates
+* layouts
Apart from the configuration file and theme metadata file, all theme files fall into the following two categories:
-* Static view files. These theme files are returned by the server to a browser as is, without any processing, and are called the static files of a theme.
+* Static view files.
+ These theme files are returned by the server to a browser as is, without any processing, and are called the static files of a theme.
-* Dynamic view files. View files that are processed or executed by the server in order to provide result to the client. These are: .less files, templates, layouts
+* Dynamic view files.
+ View files that are processed or executed by the server in order to provide result to the client.
+ These are: .less files, templates, layouts
-Where do themes live?
+### Where do themes live?
Each theme resides in a unique directory
diff --git a/guides/v2.0/architecture/archi_perspectives/third-party-libs.md b/guides/v2.0/architecture/archi_perspectives/third-party-libs.md
index b5a987d1794..98a7708d72f 100644
--- a/guides/v2.0/architecture/archi_perspectives/third-party-libs.md
+++ b/guides/v2.0/architecture/archi_perspectives/third-party-libs.md
@@ -10,8 +10,8 @@ github_link: architecture/archi_perspectives/third-party-libs.md
redirect_from: /guides/v1.0/architecture/archi_perspectives/third-party-libs.html
---
-Magento depends on a set of external libraries. You can use Composer to manage these dependencies. Composer downloads all of the external libraries that are included in its main configuration file and installs them under its default installation directory (`vendor/`). Third-party libraries include the Zend framework files and the Symfony libraries.
+Magento depends on a set of external libraries. You can use {% glossarytooltip d85e2d0a-221f-4d03-aa43-0cda9f50809e %}Composer{% endglossarytooltip %} to manage these dependencies. Composer downloads all of the external libraries that are included in its main configuration file and installs them under its default installation directory (`vendor/`). Third-party libraries include the Zend framework files and the Symfony libraries.
-There are some required libraries that Composer does not load. These reside in `lib/` and include JavaScript libraries (none of which are loaded by Composer) and a few PHP libraries. (You can also use Composer to manage dependencies between various components within Magento.)
+There are some required libraries that Composer does not load. These reside in `lib/` and include {% glossarytooltip 312b4baf-15f7-4968-944e-c814d53de218 %}JavaScript{% endglossarytooltip %} libraries (none of which are loaded by Composer) and a few {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} libraries. (You can also use Composer to manage dependencies between various components within Magento.)
-If you are extending your Magento storefront to interact with third-party applications, you might need to include additional external libraries. These external libraries can be as simple as a wrapper for an API of a third-party product you are integrating with your Magento storefront, or an entire framework.
+If you are extending your Magento {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %} to interact with third-party applications, you might need to include additional external libraries. These external libraries can be as simple as a wrapper for an {% glossarytooltip 786086f2-622b-4007-97fe-2c19e5283035 %}API{% endglossarytooltip %} of a third-party product you are integrating with your Magento storefront, or an entire framework.
diff --git a/guides/v2.0/architecture/archi_perspectives/web_endpoints.md b/guides/v2.0/architecture/archi_perspectives/web_endpoints.md
index 2b4c245b2a1..0cefe11b462 100644
--- a/guides/v2.0/architecture/archi_perspectives/web_endpoints.md
+++ b/guides/v2.0/architecture/archi_perspectives/web_endpoints.md
@@ -10,7 +10,7 @@ github_link: architecture/archi_perspectives/web_endpoints.md
redirect_from: /guides/v1.0/architecture/archi_perspectives/web_endpoints.html
---
-Web API endpoints are mentioned in the following topics:
+Web {% glossarytooltip 786086f2-622b-4007-97fe-2c19e5283035 %}API{% endglossarytooltip %} endpoints are mentioned in the following topics:
* Architectural diagrams
diff --git a/guides/v2.0/architecture/areas/areas.md b/guides/v2.0/architecture/areas/areas.md
index 0ec650eb713..295231fa00b 100644
--- a/guides/v2.0/architecture/areas/areas.md
+++ b/guides/v2.0/architecture/areas/areas.md
@@ -16,12 +16,12 @@ redirect_from: /guides/v1.0/architecture/areas/areas.html
Magento uses *areas* to efficiently make web service calls, loading only the dependent code for that area. Examples of areas include the `storefront` (frontend), `Magento Admin` (adminhtml, the administration interface), and `web API REST` (webapi_rest).
-
Although frontend and adminhtml are common in layout paths, layouts are not used by web services. Currently, layouts are used only by HTML generated for the storefront and administration interfaces.
+
Although frontend and adminhtml are common in {% glossarytooltip 73ab5daa-5857-4039-97df-11269b626134 %}layout{% endglossarytooltip %} paths, layouts are not used by web services. Currently, layouts are used only by {% glossarytooltip a2aff425-07dd-4bd6-9671-29b7edefa871 %}HTML{% endglossarytooltip %} generated for the {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %} and administration interfaces.
-Magento processes a URL request by first stripping off the base URL. The first path segment of the remaining URL identifies the request area.
+Magento processes a {% glossarytooltip a05c59d3-77b9-47d0-92a1-2cbffe3f8622 %}URL{% endglossarytooltip %} request by first stripping off the base URL. The first path segment of the remaining URL identifies the request area.
-After the area name, the part of the URI segment specifies the *full front name*. When an HTTP request arrives, the handle is extracted from the URL. The handle is used to identify the controller (a PHP class) and action (a PHP method in the class) to execute. A common action to display a HTML page is `index`, which returns an HTML page.
+After the area name, the part of the URI segment specifies the *full front name*. When an HTTP request arrives, the handle is extracted from the URL. The handle is used to identify the controller (a {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} class) and action (a PHP method in the class) to execute. A common action to display a HTML page is `index`, which returns an HTML page.
The purpose of areas is efficiency. If you are invoking a REST web service call, for example, rather than load up all the code related to generating user HTML pages, there is a separate area (such as `/rest`) which loads code that knows only how to answer the REST call (and not generate HTML pages using layouts). Each area can have completely different code on how to process URLs and requests.
@@ -29,10 +29,10 @@ Typically, an area has behavior and view components, which operate separately.
The Magento areas currently available are:
-* Magento Admin (adminhtml)
+* {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %} (adminhtml)
* Storefront (frontend)
-* Web API REST (webapi_rest)
+* Web {% glossarytooltip 786086f2-622b-4007-97fe-2c19e5283035 %}API{% endglossarytooltip %} REST (webapi_rest)
-If your extension works in several different areas, you should make sure it has separate behavior and view components for each area.
+If your {% glossarytooltip 55774db9-bf9d-40f3-83db-b10cc5ae3b68 %}extension{% endglossarytooltip %} works in several different areas, you should make sure it has separate behavior and view components for each area.
diff --git a/guides/v2.0/architecture/back-compatibility.md b/guides/v2.0/architecture/back-compatibility.md
index 4669d4f4cca..ca74f05805c 100644
--- a/guides/v2.0/architecture/back-compatibility.md
+++ b/guides/v2.0/architecture/back-compatibility.md
@@ -14,9 +14,9 @@ redirect_from: /guides/v2.0/architecture/backward-compatibility.html
Merchants and developers want the process of upgrading between revisions of Magento 2 to be as easy as possible. For merchants, the process must be cost-effective, while developers want their extensions to be forward-compatible for as long as possible.
-To help mitigate these concerns, this release introduces a backward compatibility (BC) policy for PHP code. Magento 2.0 uses Semantic Versioning 2.0.0 to indicate whether a change breaks backward compatibility. Version numbers are in the format MAJOR.MINOR.PATCH, where:
+To help mitigate these concerns, this release introduces a backward compatibility (BC) policy for {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} code. Magento 2.0 uses Semantic Versioning 2.0.0 to indicate whether a change breaks backward compatibility. Version numbers are in the format MAJOR.MINOR.PATCH, where:
-* *MAJOR* indicates incompatible API changes
+* *MAJOR* indicates incompatible {% glossarytooltip 786086f2-622b-4007-97fe-2c19e5283035 %}API{% endglossarytooltip %} changes
* *MINOR* indicates backward-compatible functionality has been added
diff --git a/guides/v2.0/architecture/behavior/price-calc.md b/guides/v2.0/architecture/behavior/price-calc.md
index 60dbb4b272a..e820bfe5d11 100644
--- a/guides/v2.0/architecture/behavior/price-calc.md
+++ b/guides/v2.0/architecture/behavior/price-calc.md
@@ -12,7 +12,7 @@ redirect_from: /guides/v1.0/architecture/behavior/price-calc.html
## Introduction to the Magento pricing library {#m2devgde-pricecalc-intro}
-This article provides in-depth information about Magento price calculation logic implemented in the Magento\Framework\Pricing library.
+This article provides in-depth information about Magento price calculation logic implemented in the Magento\Framework\Pricing {% glossarytooltip 08968dbb-2eeb-45c7-ae95-ffca228a7575 %}library{% endglossarytooltip %}.
## Price calculation: general flow {#m2devgde-pricecalc-gen}
diff --git a/guides/v2.0/architecture/behavior/price-render.md b/guides/v2.0/architecture/behavior/price-render.md
index b32a3d14f16..f65889f1450 100644
--- a/guides/v2.0/architecture/behavior/price-render.md
+++ b/guides/v2.0/architecture/behavior/price-render.md
@@ -12,7 +12,7 @@ redirect_from: /guides/v1.0/architecture/behavior/price-render.html
## Overview
-The Magento software renders prices using the Pricing library as follows:
+The Magento software renders prices using the Pricing {% glossarytooltip 08968dbb-2eeb-45c7-ae95-ffca228a7575 %}library{% endglossarytooltip %} as follows:
@@ -278,7 +278,7 @@ This section discusses the following APIs:
Magento\Framework\Pricing\Render\PriceBox is a main block that wraps all price rendering related content of particular Price Type.
-This is a private class, it cannot be accessed from general layout blocks or templates.
+This is a private class, it cannot be accessed from general {% glossarytooltip 73ab5daa-5857-4039-97df-11269b626134 %}layout{% endglossarytooltip %} blocks or templates.
diff --git a/guides/v2.0/architecture/behavior/pricing.md b/guides/v2.0/architecture/behavior/pricing.md
index 743e9fc2383..6237b4c7429 100644
--- a/guides/v2.0/architecture/behavior/pricing.md
+++ b/guides/v2.0/architecture/behavior/pricing.md
@@ -12,7 +12,7 @@ redirect_from: /guides/v1.0/architecture/behavior/pricing.html
## Magento Pricing library: implementation and usage {#m2devgde-pricelib-intro}
-This topic discusses how to use the Magento\Framework\Pricing library in your module and how to add price rendering to page templates and layouts.
+This topic discusses how to use the Magento\Framework\Pricing {% glossarytooltip 08968dbb-2eeb-45c7-ae95-ffca228a7575 %}library{% endglossarytooltip %} in your {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} and how to add price rendering to page templates and layouts.
## Use the pricing library in your module {#m2devgde-pricelib-integrate}
@@ -22,7 +22,7 @@ To use the pricing library in a module:
2. Add prices and adjustments in the di.xml of a module.
-3. Prepare a layout: create a pricing layout handle (or use the default Magento one) and add a price rendering block to page layouts.
+3. Prepare a layout: create a pricing {% glossarytooltip 73ab5daa-5857-4039-97df-11269b626134 %}layout{% endglossarytooltip %} handle (or use the default Magento one) and add a price rendering block to page layouts.
4. Add price rendering to page templates.
@@ -95,7 +95,7 @@ To add a custom price type, create a corresponding class extending `AbstractPric
To specify the price types which you plan to use for the corresponding product, add the price type codes to Price\Pool in the module's di.xml file.
-An example of Catalog module price configuration in its di.xml.
+An example of {% glossarytooltip 8d40d668-4996-4856-9f81-b1386cf4b14f %}Catalog{% endglossarytooltip %} module price configuration in its di.xml.
Price type codes are discussed in Default price types.
@@ -123,7 +123,7 @@ The name of the layout handle is arbitrary. But if you want to use also default
To learn about locations of layouts in Magento application, see XML instructions.
-For example, the Catalog module's catalog_product_prices.xml defines the basis for a product entity, so its pricing layout handle defines default values: render classes, templates, price types and adjustments. These values can be overridden by settings for particular product types in the `catalog_product_prices.xml` layout handle of the corresponding module.
+For example, the Catalog module's catalog_product_prices.xml defines the basis for a product entity, so its pricing layout handle defines default values: render classes, templates, price types and adjustments. These values can be overridden by settings for particular {% glossarytooltip 6e836354-0067-48ac-84ce-a4ab7c0c492e %}product types{% endglossarytooltip %} in the `catalog_product_prices.xml` layout handle of the corresponding module.
Class and template declarations in the pricing layout handles are based on the following fallback structures.
diff --git a/guides/v2.0/architecture/bk-architecture.md b/guides/v2.0/architecture/bk-architecture.md
index 8fc66464361..75e9a0e568a 100644
--- a/guides/v2.0/architecture/bk-architecture.md
+++ b/guides/v2.0/architecture/bk-architecture.md
@@ -14,7 +14,7 @@ redirect_from: /guides/v1.0/architecture/bk-architecture.html
The Architecture Guide provides a high-level introduction and view of the Magento product.
-The Magento platform and components are explained from the perspective of several audiences: merchants, web store developers (frontend developers), extension developers, system admins, installers, and integrators.
+The Magento platform and components are explained from the perspective of several audiences: merchants, web store developers (frontend developers), {% glossarytooltip 55774db9-bf9d-40f3-83db-b10cc5ae3b68 %}extension{% endglossarytooltip %} developers, system admins, installers, and integrators.
-More detailed information about building online stores, using the Magento APIs, installing, configuring, and extending the platform is included in other books in the Magento library.
+More detailed information about building online stores, using the Magento APIs, installing, configuring, and extending the platform is included in other books in our Magento library.
diff --git a/guides/v2.0/architecture/extensibility.md b/guides/v2.0/architecture/extensibility.md
index bac00e3ddad..6402cb11808 100644
--- a/guides/v2.0/architecture/extensibility.md
+++ b/guides/v2.0/architecture/extensibility.md
@@ -14,7 +14,7 @@ github_link: architecture/extensibility.md
Product extensibility describes how easy it is to expand a product's feature set. An extensible product has been designed from its earliest stages for customization and enhancement. Extensible products are designed for ease in expanding your installation's feature set, enriching current features, and integrating with third-party software.
-Maximizing extensibility has been our goal through all aspects of Magento development. Core tasks such as shipping are packaged as discrete modules, and you expand your features by installing modules that you either buy from third-party vendors or create yourself. While logic specific to each shipping carrier is packaged in a discrete module, you can easily add or delete shipping providers by simply adding or deleting modules. The Magento Framework provides common logic to control routing and other core application functions.
+Maximizing extensibility has been our goal through all aspects of Magento development. Core tasks such as shipping are packaged as discrete modules, and you expand your features by installing modules that you either buy from third-party vendors or create yourself. While logic specific to each {% glossarytooltip b51bd4e9-7174-4ca0-83a0-1a895c9fc9e8 %}shipping carrier{% endglossarytooltip %} is packaged in a discrete module, you can easily add or delete shipping providers by simply adding or deleting modules. The Magento Framework provides common logic to control routing and other core application functions.
## What makes a product extensible?
@@ -24,19 +24,19 @@ Below are the main factors affect extensibility.
### Architectural principles that guide product structure
-Central to the Magento model of software development is the practice of replacing or extending core code rather than editing it. This strategy supports your efforts to maintain the integrity of the tested code we provide while still extensively customizing your storefront.
+Central to the Magento model of software development is the practice of replacing or extending core code rather than editing it. This strategy supports your efforts to maintain the integrity of the tested code we provide while still extensively customizing your {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %}.
### Open-source software to create and manage extensions
-Magento is built on open-source technologies, created for the development community. For example, it uses Composer to manage dependencies. See Technology Stack for a complete list of technologies used.
+Magento is built on open-source technologies, created for the development community. For example, it uses {% glossarytooltip d85e2d0a-221f-4d03-aa43-0cda9f50809e %}Composer{% endglossarytooltip %} to manage dependencies. See Technology Stack for a complete list of technologies used.
### Coding standards
-Adherence to standard best practices for PHP and JavaScript code ensures that the code base is sound. Magento has adopted most of the Zend Framework Coding Standards for PHP. See Coding Standards for more information.
+Adherence to standard best practices for {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} and {% glossarytooltip 312b4baf-15f7-4968-944e-c814d53de218 %}JavaScript{% endglossarytooltip %} code ensures that the code base is sound. Magento has adopted most of the Zend Framework Coding Standards for PHP. See Coding Standards for more information.
### Upgrade and versioning strategies
-Magento has well-defined upgrade and versioning strategies that can help you avoid any problems with software component dependencies. Add modules after confirming that the module version is compatible with the Magento Framework version.
+Magento has well-defined upgrade and versioning strategies that can help you avoid any problems with software component dependencies. Add modules after confirming that the {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} version is compatible with the Magento Framework version.
## Related topics {#m2arch-related}
diff --git a/guides/v2.0/architecture/frontend_custom_strategies.md b/guides/v2.0/architecture/frontend_custom_strategies.md
index c04cb953bfe..fc79181b2a6 100644
--- a/guides/v2.0/architecture/frontend_custom_strategies.md
+++ b/guides/v2.0/architecture/frontend_custom_strategies.md
@@ -12,7 +12,7 @@ github_link: architecture/frontend_custom_strategies.md
## Overview {#m2arch-whatis-overview}
-The Magento frontend is designed to optimize storefront customization, with highly extensible themes being the central customization mechanism.
+The Magento {% glossarytooltip b00459e5-a793-44dd-98d5-852ab33fc344 %}frontend{% endglossarytooltip %} is designed to optimize {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %} customization, with highly extensible themes being the central customization mechanism.
Merchants are encouraged to use Magento components and themes to extend and transform the appearance of their storefronts.
@@ -20,7 +20,7 @@ Merchants are encouraged to use Magento components and themes to extend and tran
Magento provides several tools to help you significantly jumpstart the storefront customization process:
-* Magento Blank Theme
+* Magento Blank {% glossarytooltip d2093e4a-2b71-48a3-99b7-b32af7158019 %}Theme{% endglossarytooltip %}
* Magento UI Library Components
@@ -38,7 +38,7 @@ Using Magento standard coding and styling tools can help:
* enforce for consistency in design across your storefronts
* simplify (and speed up) the design process
-This component library contains standard reusable components for form features, such as fields and buttons, and navigation elements. The Magento UI library is a set of generic web components and Magento-specific patterns, which simplifies the process of Magento theme creation and customization.
+This component {% glossarytooltip 08968dbb-2eeb-45c7-ae95-ffca228a7575 %}library{% endglossarytooltip %} contains standard reusable components for form features, such as fields and buttons, and navigation elements. The Magento UI library is a set of generic web components and Magento-specific patterns, which simplifies the process of Magento theme creation and customization.
See Magento UI Library Components for details about this library.
@@ -46,7 +46,7 @@ See Magento UI Library
A pattern library is a collection of user interface (UI) design patterns that can be re-used in locations throughout your product installation. The Magento Admin Pattern Library defines examples of components that administrators working with the storefront can use.
-Form elements included in the Magento Admin pattern library include:
+Form elements included in the {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %} pattern library include:
* address form
* button bar
@@ -54,9 +54,9 @@ Form elements included in the Magento Admin pattern library include:
* tabs
* sign-in form
-Users of the default Magento storefront encounter examples of these form elements throughout the product. These patterns provide a valuable language of software components (and indirectly, user experiences) for extension developers and administrators.
+Users of the default Magento storefront encounter examples of these form elements throughout the product. These patterns provide a valuable language of software components (and indirectly, user experiences) for {% glossarytooltip 55774db9-bf9d-40f3-83db-b10cc5ae3b68 %}extension{% endglossarytooltip %} developers and administrators.
-The Magento Admin Pattern library is built on the LESS preprocessor and implemented as a module. You can download a free, current version of this module from [Magento Marketplace](https://marketplace.magento.com/){:target="_blank"}.
+The Magento {% glossarytooltip 29ddb393-ca22-4df9-a8d4-0024d75739b1 %}Admin{% endglossarytooltip %} Pattern library is built on the LESS preprocessor and implemented as a {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %}. You can download a free, current version of this module from [Magento Marketplace](https://marketplace.magento.com/){:target="_blank"}.
See Magento Admin Pattern Library for more information on using this library.
diff --git a/guides/v2.0/architecture/global_extensibility_features.md b/guides/v2.0/architecture/global_extensibility_features.md
index 43794b49721..9a0a2eef40d 100644
--- a/guides/v2.0/architecture/global_extensibility_features.md
+++ b/guides/v2.0/architecture/global_extensibility_features.md
@@ -19,20 +19,20 @@ Essential qualities foster extensibility throughout the entire set of Magento co
* Coding standards
* Flexible attribute types
* Web APIs
-* Service contracts and dependency injection
+* Service contracts and {% glossarytooltip 2be50595-c5c7-4b9d-911c-3bf2cd3f7beb %}dependency injection{% endglossarytooltip %}
* Plug-ins
### Modularity
-The concept of the module is the heart of Magento extension development, and modular design of software components (in particular, modules, themes, and language packages) is a core architectural principle of the product. Self-contained modules of discrete code are organized by feature, thereby reducing each module's external dependencies.
+The concept of the module is the heart of Magento {% glossarytooltip 55774db9-bf9d-40f3-83db-b10cc5ae3b68 %}extension{% endglossarytooltip %} development, and modular design of software components (in particular, modules, themes, and language packages) is a core architectural principle of the product. Self-contained modules of discrete code are organized by feature, thereby reducing each module's external dependencies.
-If a module is self-contained, then you can modify or replace it without affecting other areas of the code. This loose coupling of software components reduces the ripple effects throughout your code base of changing code.
+If a {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} is self-contained, then you can modify or replace it without affecting other areas of the code. This loose coupling of software components reduces the ripple effects throughout your code base of changing code.
See the PHP Developer Guide for detailed instructions on how to create modules.
### Reliance on popular design patterns
-Reliance on known architectural and programming structures helps PHP developers orient themselves to the specific development issues that affect coding in a particular product ecosystem. This can reduce the learning curve for new Magento developers.
+Reliance on known architectural and programming structures helps {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} developers orient themselves to the specific development issues that affect coding in a particular product ecosystem. This can reduce the learning curve for new Magento developers.
Design patterns are time-tested, widely recognized software architecture constructs. Magento product architecture incorporates many well known patterns, but Model-View-Controller (MVC) holds particular interest for extension developers.
@@ -44,7 +44,7 @@ See Coding S
### Rich product ecosystem
-The wider Magento ecosystem provides an extensive community and rich third-party marketplace for extensions. Visit [Magento Marketplace](https://marketplace.magento.com/) for an overview of the many modules and themes available for download and to buy modules and theme packages, which offer more possibilities for extending your storefront.
+The wider Magento ecosystem provides an extensive community and rich third-party marketplace for extensions. Visit [Magento Marketplace](https://marketplace.magento.com/) for an overview of the many modules and themes available for download and to buy modules and {% glossarytooltip d2093e4a-2b71-48a3-99b7-b32af7158019 %}theme{% endglossarytooltip %} packages, which offer more possibilities for extending your {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %}.
### Flexible attribute types
@@ -80,17 +80,17 @@ You can enhance your storefront by adding unique attributes to the default produ
Attribute types fall into three general categories:
-* EAV (Entity-Attribute-Value) attributes are site-specific attributes that you can define for a local site using the Magento Admin.
+* EAV (Entity-Attribute-Value) attributes are site-specific attributes that you can define for a local site using the {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %}.
-* Custom attributes are a subset of EAV attributes. Objects that use EAV attributes typically store values in several MySQL tables. The Customer and Catalog modules use EAV attributes.
+* Custom attributes are a subset of EAV attributes. Objects that use EAV attributes typically store values in several MySQL tables. The Customer and {% glossarytooltip 8d40d668-4996-4856-9f81-b1386cf4b14f %}Catalog{% endglossarytooltip %} modules use EAV attributes.
-* Extension attributes often use more complex data types than custom attributes. These attributes do not appear in the storefront. Extension attributes are introduced by modules.
+* Extension attributes often use more {% glossarytooltip fd9ae55f-ccf5-480b-a7f3-bd2c80f0b2a4 %}complex data{% endglossarytooltip %} types than custom attributes. These attributes do not appear in the storefront. Extension attributes are introduced by modules.
See PHP Developer Guide for information about using attributes.
### Web APIs
-Magento or third-party services can be configured as a web API (REST or SOAP) with some simple XML. You can use these services to integrate your Magento installation into third-party applications, such as CRM (Customer Relationship Management), ERP (Enterprise Resource Planning) back office systems, and CMS (Content Management Systems).
+Magento or third-party services can be configured as a web {% glossarytooltip 786086f2-622b-4007-97fe-2c19e5283035 %}API{% endglossarytooltip %} (REST or SOAP) with some simple {% glossarytooltip 8c0645c5-aa6b-4a52-8266-5659a8b9d079 %}XML{% endglossarytooltip %}. You can use these services to integrate your Magento installation into third-party applications, such as CRM (Customer Relationship Management), ERP (Enterprise Resource Planning) back office systems, and {% glossarytooltip f3944faf-127e-4097-9918-a2e9c647d44f %}CMS{% endglossarytooltip %} (Content Management Systems).
See Getting Started with Magento Web APIs for more information.
@@ -108,7 +108,7 @@ See PH
Plug-ins, like modules, are a mechanism for adding features to the core Magento product. Plug-ins enable you to make changes to the behavior of any public method in a Magento class. You can consider it a form of extension that uses the `Plugin` class.
-Plug-ins are also called interceptors. Applications use the plug-in pattern to change method behavior without modifying the actual class. Plug-ins can typically intercept method processing before or after the method runs, or only when the method throws an exception.
+Plug-ins are also called interceptors. Applications use the {% glossarytooltip 9fceecbe-31be-4e49-aac7-11d155a85382 %}plug-in{% endglossarytooltip %} pattern to change method behavior without modifying the actual class. Plug-ins can typically intercept method processing before or after the method runs, or only when the method throws an {% glossarytooltip 53da11f1-d0b8-4a7e-b078-1e099462b409 %}exception{% endglossarytooltip %}.
See Plug-ins in PHP Developer Guide for information on declaring and prioritizing plug-ins.
diff --git a/guides/v2.0/architecture/security_intro.md b/guides/v2.0/architecture/security_intro.md
index c1e02cce865..79fc31a14bb 100644
--- a/guides/v2.0/architecture/security_intro.md
+++ b/guides/v2.0/architecture/security_intro.md
@@ -15,7 +15,7 @@ Magento has strengthened the hashing algorithms (SHA-256) used in password manag
## Improved prevention of cross-site scripting (XSS) attacks by making escaped data the default
-The Magento Framework has adopted conventions that regulate the escaping of data in output. These conventions include the ability to escape output for HTML pages (HTML, JSON, and JavaScript) and email. Where possible, escaping is transparent to client code. See Security measures against XSS attacks in the Frontend Developer Guide.
+The Magento Framework has adopted conventions that regulate the escaping of data in output. These conventions include the ability to escape output for {% glossarytooltip a2aff425-07dd-4bd6-9671-29b7edefa871 %}HTML{% endglossarytooltip %} pages (HTML, JSON, and JavaScript) and email. Where possible, escaping is transparent to client code. See Security measures against XSS attacks in the {% glossarytooltip b00459e5-a793-44dd-98d5-852ab33fc344 %}Frontend{% endglossarytooltip %} Developer Guide.
## More flexible file system ownership and permissions
@@ -33,7 +33,7 @@ Magento safeguards your store from clickjacking attacks by using an X-Frame-Opti
## Use of non-default Magento Admin URL
-A simple Magento Admin URL (like `admin` or `backend`) makes it easy to target attacks on specific locations using automated password guessing. To prevent against this type of attack, Magento by default creates a random Admin URI when you install the product. The CLI is provided so that you can see the password if you forget it. You can also use the CLI to change this URI. Although the use of a non-default admin URL will not secure the site, its use will help prevent large-scale automated attacks. See Display or change the Admin URI in Configuration Guide for more information.
+A simple {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %} {% glossarytooltip a05c59d3-77b9-47d0-92a1-2cbffe3f8622 %}URL{% endglossarytooltip %} (like `admin` or `backend`) makes it easy to target attacks on specific locations using automated password guessing. To prevent against this type of attack, Magento by default creates a random Admin URI when you install the product. The CLI is provided so that you can see the password if you forget it. You can also use the CLI to change this URI. Although the use of a non-default admin URL will not secure the site, its use will help prevent large-scale automated attacks. See Display or change the Admin URI in Configuration Guide for more information.
## Related topics
diff --git a/guides/v2.0/architecture/software_versions.md b/guides/v2.0/architecture/software_versions.md
index 9fa6a845fb8..4543de445c6 100644
--- a/guides/v2.0/architecture/software_versions.md
+++ b/guides/v2.0/architecture/software_versions.md
@@ -19,24 +19,24 @@ Magento versioning policy addresses the concerns of two main types of users:
* merchants, who are focused on **product version numbers**. This product version number loosely corresponds to a platform version.
-* extension developers, who focus on **module version numbers**. Each module is released in its own Composer package, which is identified with a module version number.
+* extension developers, who focus on **module version numbers**. Each {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} is released in its own {% glossarytooltip d85e2d0a-221f-4d03-aa43-0cda9f50809e %}Composer{% endglossarytooltip %} package, which is identified with a module version number.
## Product version numbers (merchant focus)
-All merchant projects depend on the CE metapackage. (A metapackage consists of a `.zip` file that contains more than one Composer package.) Projects can specify a dependency on a specific version number (such as 2.0.1) or use a pattern to pick up patches automatically (such as 2.0.*)
+All merchant projects depend on the CE {% glossarytooltip 7490850a-0654-4ce1-83ff-d88c1d7d07fa %}metapackage{% endglossarytooltip %}. (A metapackage consists of a `.zip` file that contains more than one {% glossarytooltip b57038ca-7906-4fce-a00f-d614b81d5301 %}Composer package{% endglossarytooltip %}.) Projects can specify a dependency on a specific version number (such as 2.0.1) or use a pattern to pick up patches automatically (such as 2.0.*)
Products are currently restricted to Magento Community Edition (CE) and Magento Enterprise Edition (EE). The version numbers of editions are designed for use in discussions with merchants. That is, major and minor increments to the version number will reflect the significance of changes to merchants. This may or may not reflect equally significant changes to developers.
-You can easily view the product version number of your Magento installation in the right footer of the Magento Admin (for example, **Magento** ver. 2.0.0-rc).
+You can easily view the product version number of your Magento installation in the right footer of the {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %} (for example, **Magento** ver. 2.0.0-rc).
## Software version numbers (extension developer focus)
-Software version (module) numbers are relevant only to developer-level discussions. Extension developers typically depend on module major version numbers using version patterns such as 100.*.
+Software version (module) numbers are relevant only to developer-level discussions. {% glossarytooltip 55774db9-bf9d-40f3-83db-b10cc5ae3b68 %}Extension{% endglossarytooltip %} developers typically depend on module major version numbers using version patterns such as 100.*.
If an extension developer depends on a private API, he specifies the major and minor version number such as 100.0.* to prevent the extension from working with the next CE release. This versioning practice forces merchants to upgrade to a newer version of the extension when they upgrade the CE release level.
-The Magento team changes the major version number when we make a change that will affect extension developers. Examples of such changes include public API changes and significant layout file changes.
+The Magento team changes the major version number when we make a change that will affect extension developers. Examples of such changes include public {% glossarytooltip 786086f2-622b-4007-97fe-2c19e5283035 %}API{% endglossarytooltip %} changes and significant {% glossarytooltip 73ab5daa-5857-4039-97df-11269b626134 %}layout{% endglossarytooltip %} file changes.
## Schema and data version numbers (extension developer focus)
diff --git a/guides/v2.0/architecture/storefront_customization.md b/guides/v2.0/architecture/storefront_customization.md
index 9c4d032bf12..a3163d10423 100644
--- a/guides/v2.0/architecture/storefront_customization.md
+++ b/guides/v2.0/architecture/storefront_customization.md
@@ -11,17 +11,17 @@ github_link: architecture/storefront_customization.md
## Overview
-We can generalize about the range of storefront customizations that the Magento supports. This range spans the simplest customizations, which involve only small additions to the default Magento storefront settings, to a complete replacement of Magento-provided HTML and CSS.
+We can generalize about the range of {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %} customizations that the Magento supports. This range spans the simplest customizations, which involve only small additions to the default Magento storefront settings, to a complete replacement of Magento-provided {% glossarytooltip a2aff425-07dd-4bd6-9671-29b7edefa871 %}HTML{% endglossarytooltip %} and {% glossarytooltip 6c5cb4e9-9197-46f2-ba79-6147d9bfe66d %}CSS{% endglossarytooltip %}.
## Storefront customization levels
These four levels of potential storefront customization are listed in order to increase complexity.
### Extend Magento-Provided CSS
-Magento supplies a default theme and a LESS-based CSS. You can substantially change a storefront using CSS only. This uncomplicated strategy might suit projects with a limited budget, or might interest developers who create different skins for a site. A small business enter this process of storefront customization by buying a third-party developed theme from Magento Marketplace to extend the default values.
+Magento supplies a default {% glossarytooltip d2093e4a-2b71-48a3-99b7-b32af7158019 %}theme{% endglossarytooltip %} and a LESS-based CSS. You can substantially change a storefront using CSS only. This uncomplicated strategy might suit projects with a limited budget, or might interest developers who create different skins for a site. A small business enter this process of storefront customization by buying a third-party developed theme from Magento Marketplace to extend the default values.
### Replace PHTML template files
-In addition to extending the default CSS, you can generate different HTML markup. For example, you might need to add a missing CSS class name, or an add an extra `
` tag to achieve some visual effect. You might also need to tweak some JavaScript to cope with different HTML markup. This change is more demanding than simply extending Magento CSS, but is still within the grasp of smaller projects and leaner teams.
+In addition to extending the default CSS, you can generate different HTML {% glossarytooltip 8f407f13-4350-449b-9dc5-217dcf01bc42 %}markup{% endglossarytooltip %}. For example, you might need to add a missing CSS class name, or an add an extra `
` tag to achieve some visual effect. You might also need to tweak some {% glossarytooltip 312b4baf-15f7-4968-944e-c814d53de218 %}JavaScript{% endglossarytooltip %} to cope with different HTML markup. This change is more demanding than simply extending Magento CSS, but is still within the grasp of smaller projects and leaner teams.
### Replace Magento-Provided CSS
Rather than edit the default CSS provided by Magento, you might decide to replace all the default storefront CSS code with your own. This strategy avoids tying a project to the Magento-provided CSS, but puts a greater burden on project development and integration. It also allows use of different CSS tools or technologies not provided with Magento. Partners who build their own set of CSS libraries could reuse these libraries on different customer projects. (These unique CSS libraries may help differentiate a partner from others in the market.)
@@ -32,7 +32,7 @@ In addition to replacing CSS files, you might need to replace small amounts of H
Delivering a sharply different shopping experience than the default Magento installation provides is a more substantial task. However, the tradeoff might be a more complicated experience integrating additional extensions into your installation in the future.
-
Any customization of your storefront will work optimally, and provide the easiest path for later upgrades, if you follow the best practice of consistently compartmentalizing code by type. For example, keep all HTML in PHTML files; keep all JavaScript in JavaScript files.
+
Any customization of your storefront will work optimally, and provide the easiest path for later upgrades, if you follow the best practice of consistently compartmentalizing code by type. For example, keep all HTML in {% glossarytooltip ae0f1f68-c466-4189-88fd-6cd8b23c804f %}PHTML{% endglossarytooltip %} files; keep all JavaScript in JavaScript files.
### Related topics
diff --git a/guides/v2.0/architecture/tech-stack.md b/guides/v2.0/architecture/tech-stack.md
index 242471c432e..9459d3efcbc 100644
--- a/guides/v2.0/architecture/tech-stack.md
+++ b/guides/v2.0/architecture/tech-stack.md
@@ -22,11 +22,11 @@ Magento's highly modular structure includes the following open-source technologi
### Web servers
* Apache
-* nginx
+* {% glossarytooltip b14ef3d8-51fd-48fe-94df-ed069afb2cdc %}nginx{% endglossarytooltip %}
### PHP
-* Composer (dependency management package for PHP)
+* {% glossarytooltip d85e2d0a-221f-4d03-aa43-0cda9f50809e %}Composer{% endglossarytooltip %} (dependency management package for PHP)
### Database
@@ -50,8 +50,8 @@ Magento's highly modular structure includes the following open-source technologi
### Additional technologies
* HTML5
-* CSS3 (LESS CSS pre-processor)
-* jQuery (primary JavaScript library)
+* CSS3 (LESS {% glossarytooltip 6c5cb4e9-9197-46f2-ba79-6147d9bfe66d %}CSS{% endglossarytooltip %} pre-processor)
+* {% glossarytooltip 5bfa8a8e-6f3e-4fed-a43e-62339916f02e %}jQuery{% endglossarytooltip %} (primary {% glossarytooltip 312b4baf-15f7-4968-944e-c814d53de218 %}JavaScript{% endglossarytooltip %} library)
* RequireJS (library that helps load JavaScript resources on demand)
* Knockout.js (simplifies JavaScript UIs with the Model-View-View Model pattern)
* Third-party libraries (Zend Framework 1, Zend Framework 2, Symfony)
@@ -66,7 +66,7 @@ Magento's highly modular structure includes the following open-source technologi
Magento is *compatible with but not supported* for:
-* HHVM 3.9 PHP interpreter
+* HHVM 3.9 {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} interpreter
### Automated testing
diff --git a/guides/v2.0/architecture/versioning overview.md b/guides/v2.0/architecture/versioning overview.md
index cd4a858e08d..04236ee956b 100644
--- a/guides/v2.0/architecture/versioning overview.md
+++ b/guides/v2.0/architecture/versioning overview.md
@@ -16,7 +16,7 @@ github_link: architecture/versioning_overview.md
Versioning policy overview
-Magento uses software versioning to indicate the compatibility of changes in the code. By comparing two versions of the same component, you can tell whether it has any backward-incompatible changes in the public API or other significant code changes.
+Magento uses software versioning to indicate the compatibility of changes in the code. By comparing two versions of the same component, you can tell whether it has any backward-incompatible changes in the public {% glossarytooltip 786086f2-622b-4007-97fe-2c19e5283035 %}API{% endglossarytooltip %} or other significant code changes.
Versioning also helps:
@@ -53,7 +53,7 @@ The pre-release version format is: `MAJOR.MINOR.PATCH-n`, whe
Source code is considered part of the public API only if it is explicitly marked as such using the `@api` docblock tag. This designation indicates that the code can be used or customized by other components, such as formal interfaces and dependency injection points. Note that if you mark private code with `@api`, any change in this private interface will trigger a version change.
-For PHP code, compatibility of `@api` can be tracked on the level of structural elements (class signatures, interfaces, methods, etc.). For other source code, compatibility is tracked only on the file level (for example, the file has been deleted or renamed).
+For {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} code, compatibility of `@api` can be tracked on the level of structural elements (class signatures, interfaces, methods, etc.). For other source code, compatibility is tracked only on the file level (for example, the file has been deleted or renamed).
Related topics
diff --git a/guides/v2.0/architecture/versioning.md b/guides/v2.0/architecture/versioning.md
index 647a72f87b9..b494a492f25 100644
--- a/guides/v2.0/architecture/versioning.md
+++ b/guides/v2.0/architecture/versioning.md
@@ -12,7 +12,7 @@ redirect_from: /guides/v1.0/architecture/versioning.html
## Overview {#verpol}
-The Magento system and its components use the software (or "platform") version to indicate the compatibility of changes in the implementation (on the code level). By comparing two versions of the same component, one can tell whether it has any backward-incompatible changes in the public API or other significant code changes.
+The Magento system and its components use the software (or "platform") version to indicate the compatibility of changes in the implementation (on the code level). By comparing two versions of the same component, one can tell whether it has any backward-incompatible changes in the public {% glossarytooltip 786086f2-622b-4007-97fe-2c19e5283035 %}API{% endglossarytooltip %} or other significant code changes.
Magento software versioning complies with the following specifications:
@@ -37,13 +37,13 @@ The pre-release version format is: `MAJOR.MINOR.PATCH-n`, whe
## Public APIs
-Source code is considered public API only if it is explicitly marked as such using the `@api` docblock tag. This designation indicates the code can be used or customized by other components, such as formal interfaces and dependency injection points.
+Source code is considered public API only if it is explicitly marked as such using the `@api` docblock tag. This designation indicates the code can be used or customized by other components, such as formal interfaces and {% glossarytooltip 2be50595-c5c7-4b9d-911c-3bf2cd3f7beb %}dependency injection{% endglossarytooltip %} points.
-For PHP code, compatibility of `@api` may be tracked on the level of structural elements (class signatures, interfaces, methods, etc.). For other source code, compatibility is tracked only on file level (for example, the file has been deleted or renamed).
+For {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} code, compatibility of `@api` may be tracked on the level of structural elements (class signatures, interfaces, methods, etc.). For other source code, compatibility is tracked only on file level (for example, the file has been deleted or renamed).
## Where versioning is used
-The software version can be found in the source code of any Magento component or bundle, inside the `composer.json` file.
+The software version can be found in the source code of any {% glossarytooltip 3425e9ae-5edf-4fc6-b645-06023e9e5e5b %}Magento component{% endglossarytooltip %} or bundle, inside the `composer.json` file.
It can be declared as the version of the component:
@@ -139,7 +139,7 @@ The `x.y.z` numbers will change according to Semantic Versioning policy provisio
## Example lifecycle
-The following steps demonstrate the packaging and backward compatibility story from the view of Magento, system integrators, and extension developers. This example uses several composer packages on the public github to simulate a merchant site, 2 core Magento modules, and a third-party extension.
+The following steps demonstrate the packaging and backward compatibility story from the view of Magento, system integrators, and {% glossarytooltip 55774db9-bf9d-40f3-83db-b10cc5ae3b68 %}extension{% endglossarytooltip %} developers. This example uses several {% glossarytooltip d85e2d0a-221f-4d03-aa43-0cda9f50809e %}composer{% endglossarytooltip %} packages on the public github to simulate a merchant site, 2 core Magento modules, and a third-party extension.
Start by cloning the master branch from github.
diff --git a/guides/v2.0/architecture/versioning_overview.md b/guides/v2.0/architecture/versioning_overview.md
index 5d5a115928b..90d8b7e109e 100644
--- a/guides/v2.0/architecture/versioning_overview.md
+++ b/guides/v2.0/architecture/versioning_overview.md
@@ -16,7 +16,7 @@ github_link: architecture/versioning_overview.md
Versioning policy overview
-Magento uses software versioning to identify the compatibility of changes in the public code. By comparing two versions of the same component, you can tell whether it has any backward-incompatible changes in the public API or other significant code changes.
+Magento uses software versioning to identify the compatibility of changes in the public code. By comparing two versions of the same component, you can tell whether it has any backward-incompatible changes in the public {% glossarytooltip 786086f2-622b-4007-97fe-2c19e5283035 %}API{% endglossarytooltip %} or other significant code changes.
Versioning also helps:
@@ -28,14 +28,14 @@ Versioning also helps:
What is a public API?
-Source code is considered part of the public API only if it is explicitly marked by the `@api` docblock tag. This designation indicates that the code can be used or customized by other components, such as formal interfaces and dependency injection points.
+Source code is considered part of the public API only if it is explicitly marked by the `@api` docblock tag. This designation indicates that the code can be used or customized by other components, such as formal interfaces and {% glossarytooltip 2be50595-c5c7-4b9d-911c-3bf2cd3f7beb %}dependency injection{% endglossarytooltip %} points.
Do not mark private code with @api or changes to this private interface will trigger a version change.
-For PHP code, compatibility of @api can be tracked on the level of structural elements (such as class signatures, interfaces, or methods). For other source code, compatibility is tracked only on the file level (for example, the file has been deleted or renamed).
+For {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} code, compatibility of @api can be tracked on the level of structural elements (such as class signatures, interfaces, or methods). For other source code, compatibility is tracked only on the file level (for example, the file has been deleted or renamed).
diff --git a/guides/v2.0/architecture/versioning_spec_format.md b/guides/v2.0/architecture/versioning_spec_format.md
index 7c09d978d7a..927465d23c0 100644
--- a/guides/v2.0/architecture/versioning_spec_format.md
+++ b/guides/v2.0/architecture/versioning_spec_format.md
@@ -29,7 +29,7 @@ Magento software versioning policy complies with these widely used specification
Stable release versions are in the format `MAJOR.MINOR.PATCH`, where:
-* MAJOR indicates incompatible API changes
+* MAJOR indicates incompatible {% glossarytooltip 786086f2-622b-4007-97fe-2c19e5283035 %}API{% endglossarytooltip %} changes
* MINOR indicates backward-compatible functionality has been added
@@ -39,7 +39,7 @@ Stable release versions are in the format `MAJOR.MINOR.PATCH`, where:
The pre-release version format is: `MAJOR.MINOR.PATCH-n`, where `alpha`, `beta` or `rc` are stability indications, as described in the `version_compare()` specification, and
`n` is an increment number to distinguish releases of the non-stable versions.
-If you are an extension developer, familiarize yourself about the types of code changes that will initiate a MAJOR-, MINOR-, or PATCH- level change. See Changes to classes and method versions.
+If you are an {% glossarytooltip 55774db9-bf9d-40f3-83db-b10cc5ae3b68 %}extension{% endglossarytooltip %} developer, familiarize yourself about the types of code changes that will initiate a MAJOR-, MINOR-, or PATCH- level change. See Changes to classes and method versions.
Schema version formats
diff --git a/guides/v2.0/architecture/view/design-abstract.md b/guides/v2.0/architecture/view/design-abstract.md
index 96d176daba8..7864fdc6af0 100644
--- a/guides/v2.0/architecture/view/design-abstract.md
+++ b/guides/v2.0/architecture/view/design-abstract.md
@@ -12,9 +12,9 @@ redirect_from: /guides/v1.0/architecture/view/design-abstract.html
## Overview {#m2devgde-design-abstract-intro}
-A *design abstraction* is a layout file (a set of layout instructions) that does not have its own implementation as a page rendered by a certain controller action (page type), but could be used by one or more of such pages to define the look and feel of a page. Design abstractions are used to qualify pages by type, providing business users the ability to customize designs for certain types of pages. In particular design abstractions are used in widget creation to define the types of pages where a widget can be displayed.
+A *design abstraction* is a {% glossarytooltip 73ab5daa-5857-4039-97df-11269b626134 %}layout{% endglossarytooltip %} file (a set of layout instructions) that does not have its own implementation as a page rendered by a certain controller action (page type), but could be used by one or more of such pages to define the look and feel of a page. Design abstractions are used to qualify pages by type, providing business users the ability to customize designs for certain types of pages. In particular design abstractions are used in {% glossarytooltip f0dcf847-ce21-4b88-8b45-83e1cbf08100 %}widget{% endglossarytooltip %} creation to define the types of pages where a widget can be displayed.
-For example, there is a design abstraction defining a two-column page layout. So when creating a widget, you can select it to be displayed on all pages with two-column page layout. This article describes how design abstractions are declared, called in layout files, and used in widget creation in the Admin panel. This information is a practical reference for frontend developers working with layouts, and is also useful for the wider audience of server-side and frontend developers who want to understand how the Magento system implements layouts.
+For example, there is a design abstraction defining a two-column page layout. So when creating a widget, you can select it to be displayed on all pages with two-column page layout. This article describes how design abstractions are declared, called in layout files, and used in widget creation in the {% glossarytooltip 29ddb393-ca22-4df9-a8d4-0024d75739b1 %}Admin{% endglossarytooltip %} panel. This information is a practical reference for {% glossarytooltip b00459e5-a793-44dd-98d5-852ab33fc344 %}frontend{% endglossarytooltip %} developers working with layouts, and is also useful for the wider audience of server-side and frontend developers who want to understand how the Magento system implements layouts.
## About design abstractions {#m2devgde-design-abstract-what}
@@ -39,7 +39,7 @@ When a page is rendered, all `customer_account` layouts are merged, and the page
## Declare design abstractions {#m2devgde-design-abstract-declare}
According to the layout naming convention, the name of a layout file corresponds to the layout handle it defines.
-To declare a layout file as a design abstraction, you need to set the layout handle (the root XML node of a file which represents a handle) attributes as follows:
+To declare a layout file as a design abstraction, you need to set the layout handle (the root {% glossarytooltip 8c0645c5-aa6b-4a52-8266-5659a8b9d079 %}XML{% endglossarytooltip %} node of a file which represents a handle) attributes as follows:
<layout label="{your_custom_value}" design_abstraction="custom" />
@@ -65,7 +65,7 @@ To complete the `customer_account.xml` design abstraction example, look at Content/ Frontend App. After choosing to create a new widget instance, a user specifies the widget type and the design theme. Then a page for configuring other widget options is displayed. To select a page where the widget should be displayed, you need to click Add Layout Update. Now you can specify pages by selecting the corresponding layout handles. If you want a widget to be displayed on pages with a certain layout, choose Page Layouts.
+Specifying the pages where a widget is displayed is one of the required steps during widget creation. Widgets are added in the Admin under Content/ Frontend App. After choosing to create a new widget instance, a user specifies the widget type and the design {% glossarytooltip d2093e4a-2b71-48a3-99b7-b32af7158019 %}theme{% endglossarytooltip %}. Then a page for configuring other widget options is displayed. To select a page where the widget should be displayed, you need to click Add Layout Update. Now you can specify pages by selecting the corresponding layout handles. If you want a widget to be displayed on pages with a certain layout, choose Page Layouts.
diff --git a/guides/v2.0/architecture/view/page-assets.md b/guides/v2.0/architecture/view/page-assets.md
index 4949e1f8543..976c0673757 100644
--- a/guides/v2.0/architecture/view/page-assets.md
+++ b/guides/v2.0/architecture/view/page-assets.md
@@ -13,10 +13,10 @@ redirect_from: /guides/v1.0/architecture/view/page-assets.html
## Overview {#m2devgde-page-assets-intro}
-An _asset_ is a reference to a certain resource linked to an HTML page; that is, references to scripts, stylesheets, RSS feeds, and so on using ``, ``, `` elements.
+An _asset_ is a reference to a certain resource linked to an {% glossarytooltip a2aff425-07dd-4bd6-9671-29b7edefa871 %}HTML{% endglossarytooltip %} page; that is, references to scripts, stylesheets, RSS feeds, and so on using ``, ``, `` elements.
This topic discusses how to work with Magento page assets (particularly interfaces and classes). The article is mostly aimed at developers
-who have solid experience with PHP and are familiar with Magento XML layouts.
+who have solid experience with {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} and are familiar with Magento XML layouts.
## Asset interfaces {#m2devgde-page-assets-interf}
@@ -41,7 +41,7 @@ These types are represented as interfaces in the
The classes Implement the interfaces are responsible for:
-* Remote: Implements an asset for which there is only URL and content type information. Used for rendering included RSS feeds, for example.
+* Remote: Implements an asset for which there is only {% glossarytooltip a05c59d3-77b9-47d0-92a1-2cbffe3f8622 %}URL{% endglossarytooltip %} and content type information. Used for rendering included RSS feeds, for example.
* File: Implements a local asset that is referred using a relative path in Magento file system. The same relative path invariant is appended to the base URL when the full URL is requested. Because these assets are available locally, the Magento system can work with them in many ways; for example, transform the content, merge assets, or substitute with other assets.
@@ -65,7 +65,7 @@ It accepts URL and `content-type` in the constructor and serves only as a value
\Magento\Framework\View\Asset\File represents resources that reside in the local file system and for which you know the absolute file system path and an invariant "file path".
-This kind of asset accommodates arbitrary static view files that might be embedded in, or referred from, a web page. That might include anything from user-uploaded images to CSS files provided in Magento themes. Because these assets are available locally, the Magento software can manipulate them in many ways; for example, transform the content, merge assets, or substitute with other assets.
+This kind of asset accommodates arbitrary static view files that might be embedded in, or referred from, a web page. That might include anything from user-uploaded images to {% glossarytooltip 6c5cb4e9-9197-46f2-ba79-6147d9bfe66d %}CSS{% endglossarytooltip %} files provided in Magento themes. Because these assets are available locally, the Magento software can manipulate them in many ways; for example, transform the content, merge assets, or substitute with other assets.
Its asset class diagram follows:
@@ -98,11 +98,11 @@ http://example.com/pub/static/frontend/magento_theme/en_US/css-topics/styles.css
## Page assets and static view files {#m2devgde-page-assets-static-view}
-According to the Magento classification of view files, CSS, JavaScript, images, and other assets that are included in a web page and presented on the storefront without modification are _static view files_.
+According to the Magento classification of view files, CSS, JavaScript, images, and other assets that are included in a web page and presented on the {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %} without modification are _static view files_.
Like all Magento view files, static view files are located using the fallback mechanism. This mechanism implements inheritance of files from one directory to others. In this way, we enable you to extend or override view files of existing components with new components.
-For example, a particular theme might extend or override files of its parent theme, all themes generally override module view files, and so on.
+For example, a particular {% glossarytooltip d2093e4a-2b71-48a3-99b7-b32af7158019 %}theme{% endglossarytooltip %} might extend or override files of its parent theme, all themes generally override {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} view files, and so on.
## Manipulate page assets {#m2devgde-page-assets-static-manip}
@@ -114,7 +114,7 @@ This section discusses the following ways to work with view assets:
### Use layout XML to manipulate assets {#m2devgde-page-assets-static-manip-xml}
-Although you can use the API to manipulate assets, frontend developers should use layout XML instructions to register assets.
+Although you can use the {% glossarytooltip 786086f2-622b-4007-97fe-2c19e5283035 %}API{% endglossarytooltip %} to manipulate assets, {% glossarytooltip b00459e5-a793-44dd-98d5-852ab33fc344 %}frontend{% endglossarytooltip %} developers should use layout XML instructions to register assets.
This method is preferred because it enables you to implement particular discriminators for assets, like browser matching and conditional loading.
@@ -152,7 +152,7 @@ Expand one of the following sections for more information:
#### Use layout XML to manipulate browser matching {#m2devgde-page-assets-static-manip-xml-brows}
-Use _browser matching_ to change the behavior of JavaScript and CSS for certain browsers only (usually because of technology-specific workarounds). The following example illustrates using layout instructions to set using a CSS file only when a page is loaded in Internet Explorer:
+Use _browser matching_ to change the behavior of {% glossarytooltip 312b4baf-15f7-4968-944e-c814d53de218 %}JavaScript{% endglossarytooltip %} and CSS for certain browsers only (usually because of technology-specific workarounds). The following example illustrates using {% glossarytooltip 73ab5daa-5857-4039-97df-11269b626134 %}layout{% endglossarytooltip %} instructions to set using a CSS file only when a page is loaded in Internet Explorer:
Layout instructions:
diff --git a/guides/v2.0/architecture/view/page-type.md b/guides/v2.0/architecture/view/page-type.md
index e2cf35badcf..beb0602181c 100644
--- a/guides/v2.0/architecture/view/page-type.md
+++ b/guides/v2.0/architecture/view/page-type.md
@@ -12,9 +12,9 @@ redirect_from: /guides/v1.0/architecture/view/page-type.html
## Overview
-Page types are semantic abstractions of those controller actions which are used for page rendering. They help to qualify pages by context type, like Product View page, Shopping Cart page, and so on, providing business users the ability to customize page design. In particular, page types are used in the widget creation to define the pages where a widget can be displayed.
+Page types are semantic abstractions of those controller actions which are used for page rendering. They help to qualify pages by context type, like Product View page, {% glossarytooltip c7ecb18d-cefe-452d-83e2-3c4d5e355db9 %}Shopping Cart{% endglossarytooltip %} page, and so on, providing business users the ability to customize page design. In particular, page types are used in the {% glossarytooltip f0dcf847-ce21-4b88-8b45-83e1cbf08100 %}widget{% endglossarytooltip %} creation to define the pages where a widget can be displayed.
-Page types are defined for the frontend area only, that is for the store front pages.
+Page types are defined for the {% glossarytooltip b00459e5-a793-44dd-98d5-852ab33fc344 %}frontend{% endglossarytooltip %} area only, that is for the store front pages.
Reviewer: Clarify "for now"
@@ -28,7 +28,7 @@ Full action names are mapped to the controller actions as follows:
where
-* `module` is the name of a module
+* `module` is the name of a {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %}
* `Controller` is the module's `Controller` directory
@@ -42,7 +42,7 @@ For example,
## Page types and layout handles {#m2devgde-pagetype-handles}
-In Magento, full action names also used as identifiers for sets of layout instructions (layout handles): a controller action by default loads a layout handle which coincides with its full action name. This means that page types correspond to some of the layout handles.
+In Magento, full action names also used as identifiers for sets of {% glossarytooltip 73ab5daa-5857-4039-97df-11269b626134 %}layout{% endglossarytooltip %} instructions (layout handles): a controller action by default loads a layout handle which coincides with its full action name. This means that page types correspond to some of the layout handles.
There are also other types of layout handles, like specific page handles, as well as custom handles.
@@ -72,11 +72,11 @@ An example is shown in the previously referenced Customer module `page_types.xml
## Page types in widget creation {#m2devge-pagetype-widget}
-To create a widget, you must specify the pages on which it displays in the Magento Admin as follows:
+To create a widget, you must specify the pages on which it displays in the {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %} as follows:
1. In the Magento Admin, click **Content** > **Frontend App**.
-2. After choosing to create a new widget instance, specify the widget type and the design theme.
+2. After choosing to create a new widget instance, specify the widget type and the design {% glossarytooltip d2093e4a-2b71-48a3-99b7-b32af7158019 %}theme{% endglossarytooltip %}.
3. In the page for configuring other widget options, click **Add Layout Update**. You can now specify pages by clicking the corresponding layout handle names.
diff --git a/guides/v2.0/architecture/view/static-process.md b/guides/v2.0/architecture/view/static-process.md
index b7493370a34..fdb174ba707 100644
--- a/guides/v2.0/architecture/view/static-process.md
+++ b/guides/v2.0/architecture/view/static-process.md
@@ -35,9 +35,9 @@ Whenever a static view file is requested in the Magento application, it uses the
Magento generates CSS files from LESS files.
-
CSS and JavaScript file merging
+
CSS and {% glossarytooltip 312b4baf-15f7-4968-944e-c814d53de218 %}JavaScript{% endglossarytooltip %} file merging
-
Magento merges all CSS or JavaScript assets linked in the <head> element of the page into a single files and replaces referenced files with a single reference.
+
Magento merges all CSS or JavaScript assets linked in the <head> element of the page into a single file and replaces referenced files with a single reference.
JavaScript files minifying
@@ -47,13 +47,13 @@ Whenever a static view file is requested in the Magento application, it uses the
## Fallback mechanism example {#example-fallback}
-As an example of static file fallback, suppose there is a request for the `logo.svg` image in the Blank theme.
+As an example of static file fallback, suppose there is a request for the `logo.svg` image in the Blank {% glossarytooltip d2093e4a-2b71-48a3-99b7-b32af7158019 %}theme{% endglossarytooltip %}.
-The request URL is similar to:
+The request {% glossarytooltip a05c59d3-77b9-47d0-92a1-2cbffe3f8622 %}URL{% endglossarytooltip %} is similar to:
http://www.example.com/pub/static/frontend/Magento/blank/en_US/images/logo.svg
-The Magento API request is similar to:
+The Magento {% glossarytooltip 786086f2-622b-4007-97fe-2c19e5283035 %}API{% endglossarytooltip %} request is similar to:
$this->getViewFileUrl('logo.svg');
@@ -97,7 +97,7 @@ To use the static view file publication tool, see Merging enabled
@@ -167,7 +167,7 @@ the identified references are published from following locations:
### Context notation in CSS file references {#context-notation}
-
@@ -184,7 +184,7 @@ The `create()` method in Magento\Framework\View\TemplateEngineInterface defines the render()method. The resulting markup generated by the template engine is not sent directly to the output buffer, but it is returned to the caller.
+Magento\Framework\View\TemplateEngineInterface defines the render()method. The resulting {% glossarytooltip 8f407f13-4350-449b-9dc5-217dcf01bc42 %}markup{% endglossarytooltip %} generated by the template engine is not sent directly to the output buffer, but it is returned to the caller.
@@ -236,7 +236,7 @@ render(
The Magento template rendering subsystem supports the following:
-* Your module can introduce a new template engine.
+* Your {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} can introduce a new template engine.
* You can use PHTML templates together with other kinds of templates.
* You can embed any block to other blocks regardless of the underlying template engine.
@@ -270,6 +270,6 @@ Where:
* {engine_class} is the name of the class that implements a template engine
-Example of a dependency injection configuration file:
+Example of a {% glossarytooltip 2be50595-c5c7-4b9d-911c-3bf2cd3f7beb %}dependency injection{% endglossarytooltip %} configuration file:
diff --git a/guides/v2.0/architecture/view/view-lib.md b/guides/v2.0/architecture/view/view-lib.md
index 2a1bec5e967..862a7704d4c 100644
--- a/guides/v2.0/architecture/view/view-lib.md
+++ b/guides/v2.0/architecture/view/view-lib.md
@@ -14,14 +14,14 @@ redirect_from: /guides/v1.0/architecture/view/view-lib.html
An independent view layer domain, the View component was created to eliminate
global dependencies on `Magento_Core`, `Magento_Backend`, `Magento_Adminhtml` and `Magento_Page` modules
-for HTML content rendering. All application modules perform rendering using the
+for {% glossarytooltip a2aff425-07dd-4bd6-9671-29b7edefa871 %}HTML{% endglossarytooltip %} content rendering. All application modules perform rendering using the
View component, and remain independent from each other.
The View component is represented as `Magento\Framework\View` library: `/lib/internal/Magento/Framework/View`.
## Using Magento\Framework\View library
-The View component contains basic classes, factories and interfaces used to implement HTML content rendering for the frontend and backend application areas.
+The View component contains basic classes, factories and interfaces used to implement HTML content rendering for the {% glossarytooltip b00459e5-a793-44dd-98d5-852ab33fc344 %}frontend{% endglossarytooltip %} and {% glossarytooltip 74d6d228-34bd-4475-a6f8-0c0f4d6d0d61 %}backend{% endglossarytooltip %} application areas.
## Magento\View Library components
@@ -41,7 +41,7 @@ The `Magento\Framework\View` library has the following components:
* Theme
-* Layout.
+* {% glossarytooltip 73ab5daa-5857-4039-97df-11269b626134 %}Layout{% endglossarytooltip %}.
## Magento\Framework\View library dependencies
diff --git a/guides/v2.0/architecture/view/xml-schema-layout.md b/guides/v2.0/architecture/view/xml-schema-layout.md
index e46dbe717f9..7fd4dde261a 100644
--- a/guides/v2.0/architecture/view/xml-schema-layout.md
+++ b/guides/v2.0/architecture/view/xml-schema-layout.md
@@ -12,7 +12,7 @@ redirect_from: /guides/v1.0/architecture/view/xml-schema-layout.html
## Overview {#m2devgde-xml-layout-intro}
-
In the Magento system, you define application page layouts in XML files, also known as layouts.
+
In the Magento system, you define application page layouts in {% glossarytooltip 8c0645c5-aa6b-4a52-8266-5659a8b9d079 %}XML{% endglossarytooltip %} files, also known as layouts.
The system uses the Magento XML schemas to validate these layouts.
@@ -48,7 +48,7 @@ These layout-specific XML schemas might use additional universal XML schemas.
## XML layout elements and structure {#layout-elements}
-The following table lists the allowable XML layout elements. The table reflects the correct structure for these elements.
+The following table lists the allowable XML {% glossarytooltip 73ab5daa-5857-4039-97df-11269b626134 %}layout{% endglossarytooltip %} elements. The table reflects the correct structure for these elements.
diff --git a/guides/v2.0/bk-get-started-magento.md b/guides/v2.0/bk-get-started-magento.md
index 3d4af933cdf..542646ceb19 100644
--- a/guides/v2.0/bk-get-started-magento.md
+++ b/guides/v2.0/bk-get-started-magento.md
@@ -14,11 +14,11 @@ redirect_from: /guides/v1.0/bk-get-started-magento.html
Welcome to Magento 2.0 documentation! And welcome to Magento 2.0!
-Here we explain the Magento platform and components from the perspective of several audiences: merchants, web store developers (frontend developers), extension developers, system administrators, installers, and integrators.
+Here we explain the Magento platform and components from the perspective of several audiences: merchants, web store developers (frontend developers), {% glossarytooltip 55774db9-bf9d-40f3-83db-b10cc5ae3b68 %}extension{% endglossarytooltip %} developers, system administrators, installers, and integrators.
Magento is a highly-customizable eCommerce platform and content management system that is primarily used to build online storefronts or web sites for selling merchandise.
-Magento is written using the PHP programming language, and leverages elements of the Zend framework and the model-view-controller architecture. Magento runs on the MySQL relational database, and Magento schema and tables are included in the Magento installation package.
+Magento is written using the {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} programming language, and leverages elements of the Zend framework and the model-view-controller architecture. Magento runs on the MySQL relational database, and Magento schema and tables are included in the Magento installation package.
Help improve this documentation
diff --git a/guides/v2.0/cloud/access-acct/fastly.md b/guides/v2.0/cloud/access-acct/fastly.md
index 09fb5cb0695..1273e827311 100644
--- a/guides/v2.0/cloud/access-acct/fastly.md
+++ b/guides/v2.0/cloud/access-acct/fastly.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: Set up Fastly
menu_title: Set up Fastly
menu_order: 500
@@ -10,14 +10,14 @@ version: 2.0
github_link: cloud/access-acct/fastly.md
---
-[Fastly](https://www.fastly.com/why-fastly){:target="_blank"} is required for Magento Enterprise Cloud Edition. It works with Varnish to provide fast caching capabilities and a Content Delivery Network (CDN) for static assets.
+[Fastly](https://www.fastly.com/why-fastly){:target="_blank"} is required for Magento Enterprise Cloud Edition. It works with Varnish to provide fast caching capabilities and a {% glossarytooltip f83f1fa7-7a64-467b-b629-c2d0c25d2e7f %}Content Delivery Network{% endglossarytooltip %} (CDN) for static assets.
## Get your Fastly credentials {#cloud-fastly-creds}
-To get Fastly credentials, open a [support ticket]({{ page.baseurl }}cloud/get-help.html). You must provide your fully-qualified domain name.
+To get Fastly credentials, open a [support ticket]({{ page.baseurl }}cloud/welcome/get-help.html). You must provide your fully-qualified {% glossarytooltip 41aee03b-a5d5-49c2-8839-894090ef4e86 %}domain{% endglossarytooltip %} name.
We'll provide you with the following information so you can enable Fastly:
-* Fastly API key
+* Fastly {% glossarytooltip 786086f2-622b-4007-97fe-2c19e5283035 %}API{% endglossarytooltip %} key
* Fastly service ID
## Get started {#cloud-fastly-start}
@@ -46,7 +46,7 @@ In the procedure that follows, make sure you *branch* a new environment; don't u
git add -A; git commit -m "Install Fastly"; git push origin
## Enable Fastly using the Magento Admin {#cloud-fastly-admin}
-1. Log in to your local Magento Admin as an administrator.
+1. Log in to your local {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %} as an administrator.
If you don't remember your login information, enter the following command:
@@ -79,7 +79,7 @@ In the procedure that follows, make sure you *branch* a new environment; don't u
Configure Fastly using the following:
* We provide your Fastly service ID and API key.
-* Set most other Fastly configuration options in the Magento Admin.
+* Set most other Fastly configuration options in the Magento {% glossarytooltip 29ddb393-ca22-4df9-a8d4-0024d75739b1 %}Admin{% endglossarytooltip %}.
* You can fine-tune the Fastly configuration as discussed in [Custom VCLs](#custom-vcl).
To configure Fastly in the Admin:
@@ -95,7 +95,7 @@ To configure Fastly in the Admin:
For details about Fastly configuration, see the [Fastly documentation](https://docs.fastly.com/guides){:target="_blank"}.
### Create a custom error/maintenance page {#fastly-errpg}
-You can optionally create a custom HTML page for errors or when your site is down for maintenance. This page can give confidence to your customers; instead of seeing HTTP error codes, they'll see a page that explains that your site is down temporarily.
+You can optionally create a custom {% glossarytooltip a2aff425-07dd-4bd6-9671-29b7edefa871 %}HTML{% endglossarytooltip %} page for errors or when your site is down for maintenance. This page can give confidence to your customers; instead of seeing HTTP error codes, they'll see a page that explains that your site is down temporarily.
To create a custom error/maintenance page:
diff --git a/guides/v2.0/cloud/access-acct/first-time-setup.md b/guides/v2.0/cloud/access-acct/first-time-setup.md
index 29b6f2da5e4..9550f32100f 100644
--- a/guides/v2.0/cloud/access-acct/first-time-setup.md
+++ b/guides/v2.0/cloud/access-acct/first-time-setup.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: First-time setup (developers)
menu_title: First-time setup (developers)
menu_order: 1
@@ -20,5 +20,5 @@ After you receive an invitation, you can complete the following tasks:
* Deploy the Magento software to the cloud:
* [Create a sample Magento project from a template]({{ page.baseurl }}cloud/access-acct/first-time-setup_template.html)
- * [Import an existing Magento project]({{ page.baseurl }}cloud/access-acct/first-time-setup_import.html)
-* [Step 1, Get started setting up an environment]({{ page.baseurl }}cloud/before/before-setup-env-1_get-started.html)
+ * [Import an existing Magento project]({{ page.baseurl }}cloud/access-acct/first-time-setup_import-first-steps.html)
+* [Step 1, Get started setting up an environment]({{ page.baseurl }}cloud/before/before-setup-env-1_get-start.html)
diff --git a/guides/v2.0/cloud/access-acct/first-time-setup_dir-structure.md b/guides/v2.0/cloud/access-acct/first-time-setup_dir-structure.md
index c5295455454..300e87e01d6 100644
--- a/guides/v2.0/cloud/access-acct/first-time-setup_dir-structure.md
+++ b/guides/v2.0/cloud/access-acct/first-time-setup_dir-structure.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: Project directory structure
menu_title: Project directory structure
menu_order: 600
@@ -36,11 +36,11 @@ Not including the Magento application itself, your local project has the followi
The following sections discuss information you need to know about directories in the systems deployed to Magento Enterprise Cloud Edition.
### Magento application root directory
-In your [integration systems]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-int), the Magento application is located in the `/app` directory.
+In your [integration systems]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-int), the Magento application is located in the `/app` directory.
-In [staging]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-stage), it's located in the `/_stg` directory.
+In [staging]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-stage), it's located in the `/_stg` directory.
-In [production]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-prod), it's located in the ` /` directory.
+In [production]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-prod), it's located in the ` /` directory.
### Writable directories
In integration, staging, and production, for security reasons, *only* the following directories are writable:
diff --git a/guides/v2.0/cloud/access-acct/first-time-setup_import-first-steps.md b/guides/v2.0/cloud/access-acct/first-time-setup_import-first-steps.md
index 3f4bb215921..d813860e2f1 100644
--- a/guides/v2.0/cloud/access-acct/first-time-setup_import-first-steps.md
+++ b/guides/v2.0/cloud/access-acct/first-time-setup_import-first-steps.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: First steps for importing Magento EE
menu_title: First steps for importing Magento EE
menu_order: 151
@@ -35,7 +35,7 @@ Following is our recommended workflow:
3. [Import your Magento database]({{ page.baseurl }}cloud/access-acct/first-time-setup_import-import.html#cloud-import-db) into your Magento Enterprise Cloud Edition project.
4. [Import your static files]({{ page.baseurl }}cloud/access-acct/first-time-setup_import-import.html#cloud-import-media) into your Magento Enterprise Cloud Edition project.
5. Copy your Magento EE [encryption key]({{ page.baseurl }}cloud/access-acct/first-time-setup_import-import.html#cloud-import-key) to your Magento Enterprise Cloud Edition project.
-6. Clear the cache and verify the project imported successfully.
+6. Clear the {% glossarytooltip 0bc9c8bc-de1a-4a06-9c99-a89a29c30645 %}cache{% endglossarytooltip %} and verify the project imported successfully.
## Create a new, empty Magento Enterprise Edition project {#cloud-import-proj}
diff --git a/guides/v2.0/cloud/access-acct/first-time-setup_import-import.md b/guides/v2.0/cloud/access-acct/first-time-setup_import-import.md
index f78dadd815e..c54df4c90a2 100644
--- a/guides/v2.0/cloud/access-acct/first-time-setup_import-import.md
+++ b/guides/v2.0/cloud/access-acct/first-time-setup_import-import.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: Import Magento EE into Magento Enterprise Cloud Edition
menu_title: Import Magento EE into Magento Enterprise Cloud Edition
menu_order: 154
@@ -27,7 +27,7 @@ Before you continue, make sure you have the [encryption key]({{ page.baseurl }}c
## Create a remote Git reference {#cloud-import-ref}
This section discusses how to create a remote Git reference from your Cloud Git repository to the repository in which your Magento EE installation is located.
-Before you continue, make sure you know the SSH or HTTPS URL for your Magento EE installation Git repository.
+Before you continue, make sure you know the SSH or HTTPS {% glossarytooltip a05c59d3-77b9-47d0-92a1-2cbffe3f8622 %}URL{% endglossarytooltip %} for your Magento EE installation Git repository.
To create a remote Git reference:
@@ -98,7 +98,7 @@ To import the Magento database in Magento Enterprise Cloud Edition, you must kno
* The database name, user name, and password of the [Cloud database]({{ page.baseurl }}cloud/access-acct/first-time-setup_import-prepare.html#cloud-import-pre-cloudb)
-This topic discusses how to import the [integration system]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-int) database. The database connection information is different for [staging]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-stage) and [production]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-prod) systems. You'll need the assistance of Magento Support before you can migrate your integration system database to staging or production.
+This topic discusses how to import the [integration system]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-int) database. The database connection information is different for [staging]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-stage) and [production]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-prod) systems. You'll need the assistance of Magento Support before you can migrate your integration system database to staging or production.
### Drop and re-create the Cloud database
@@ -205,16 +205,16 @@ On the Cloud environment, enter the following commands in the order shown:
bin/magento magento setup:static-content:deploy
bin/magento cache:flush
-After the cache flushes, enter `exit` to close the SSH tunnel.
+After the {% glossarytooltip 0bc9c8bc-de1a-4a06-9c99-a89a29c30645 %}cache{% endglossarytooltip %} flushes, enter `exit` to close the SSH tunnel.
## Verify the import
To verify everything imported properly, perform the following tasks in your local Cloud development environment:
-1. On your Cloud environment, enter the following commands to find the information to log in to the Magento Admin and to view the storefront:
+1. On your Cloud environment, enter the following commands to find the information to log in to the {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %} and to view the storefront:
magento-cloud environment:url
-2. Log in to the Magento Admin using the user name and password of your Magento EE system.
+2. Log in to the Magento {% glossarytooltip 29ddb393-ca22-4df9-a8d4-0024d75739b1 %}Admin{% endglossarytooltip %} using the user name and password of your Magento EE system.
3. Make sure settings in the Admin are the same as your Magento EE system.
-3. Access the storefront.
+3. Access the {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %}.
4. Make sure categories, products, and so on display as you expect.
-5. Test everything thoroughly.
\ No newline at end of file
+5. Test everything thoroughly.
diff --git a/guides/v2.0/cloud/access-acct/first-time-setup_import-parent.md b/guides/v2.0/cloud/access-acct/first-time-setup_import-parent.md
index baef217c875..9f71ab4ea9a 100644
--- a/guides/v2.0/cloud/access-acct/first-time-setup_import-parent.md
+++ b/guides/v2.0/cloud/access-acct/first-time-setup_import-parent.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: Import an existing Magento project
menu_title: Import an existing Magento project
menu_order: 150
diff --git a/guides/v2.0/cloud/access-acct/first-time-setup_import-prepare.md b/guides/v2.0/cloud/access-acct/first-time-setup_import-prepare.md
index b5c74088940..20b6833ed35 100644
--- a/guides/v2.0/cloud/access-acct/first-time-setup_import-prepare.md
+++ b/guides/v2.0/cloud/access-acct/first-time-setup_import-prepare.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: Prepare your existing Magento EE system
menu_title: Prepare your existing Magento EE system
menu_order: 153
@@ -84,7 +84,7 @@ In some cases, you might already have `auth.json` so check to see if it exists a
[Get a sample `auth.json`](https://raw.githubusercontent.com/magento/magento-cloud/master/auth.json.sample){:target="_blank"}
-To create a new `auth.json` in the event you don't have one:
+To create a new `auth.json` in the {% glossarytooltip c57aef7c-97b4-4b2b-a999-8001accef1fe %}event{% endglossarytooltip %} you don't have one:
1. Use a text editor to create a file named `auth.json` in your Magento root directory.
3. Replace `` and `` with your Magento EE authentication credentials.
@@ -164,7 +164,7 @@ This section discusses how to use the [`magento setup:backup --media`]({{ page.b
rsync /var/www/html/magento2/var/backups/1487962699_filesystem_media.tgz 43bkopvkhelhy-master-l8uv4kp@ssh.us.magentosite.cloud:var/media.tgz
### Copy the encryption key {#cloud-import-copykey}
-To be able to decrypt encrypted data from your imported database, copy your encryption from your existing `env.php` file. `env.php` contains a nested PHP array storing configuration data.
+To be able to decrypt encrypted data from your imported database, copy your encryption from your existing `env.php` file. `env.php` contains a nested {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} array storing configuration data.
1. Open `/app/etc/env.php` in a text editor.
2. Search for the value of `key` (it's in the `crypt` array).
diff --git a/guides/v2.0/cloud/access-acct/first-time-setup_import-prereq.md b/guides/v2.0/cloud/access-acct/first-time-setup_import-prereq.md
index 3b83dba175b..1a53c07afda 100644
--- a/guides/v2.0/cloud/access-acct/first-time-setup_import-prereq.md
+++ b/guides/v2.0/cloud/access-acct/first-time-setup_import-prereq.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: Find the information you need for your import
menu_title: Find the information you need for your import
menu_order: 152
@@ -19,7 +19,7 @@ You must enter all Magento Enterprise Cloud Edition commands on the machine on w
## Cloud SSH URL {#cloud-import-pre-sshurl}
-To transfer the database dump and files to Magento Enterprise Cloud Edition, you must know its SSH URL.
+To transfer the database dump and files to Magento Enterprise Cloud Edition, you must know its SSH {% glossarytooltip a05c59d3-77b9-47d0-92a1-2cbffe3f8622 %}URL{% endglossarytooltip %}.
You can find it using:
@@ -66,7 +66,7 @@ The database connection information is displayed:
In the preceding example, the database name is `main`, its listen port is `3306`, its host name is `database.internal`, its root user name is `user` and the user has no password.
## Cloud integration system's unsecure base URL {#cloud-import-pre-baseurl}
-After you import the Magento EE database into Magento Enterprise Cloud Edition, you must change the base URL so you can access the Magento Admin and storefront.
+After you import the Magento EE database into Magento Enterprise Cloud Edition, you must change the base URL so you can access the {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %} and {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %}.
You can find it using:
diff --git a/guides/v2.0/cloud/access-acct/first-time-setup_template.md b/guides/v2.0/cloud/access-acct/first-time-setup_template.md
index 2248deb570b..9984874b521 100644
--- a/guides/v2.0/cloud/access-acct/first-time-setup_template.md
+++ b/guides/v2.0/cloud/access-acct/first-time-setup_template.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: Create a new Magento project
menu_title: Create a new Magento project
menu_order: 100
diff --git a/guides/v2.0/cloud/access-acct/resources.md b/guides/v2.0/cloud/access-acct/resources.md
index db09527d9e3..40392dee0b7 100644
--- a/guides/v2.0/cloud/access-acct/resources.md
+++ b/guides/v2.0/cloud/access-acct/resources.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: Magento 2 resources
menu_title: Magento 2 resources
menu_order: 550
@@ -10,7 +10,7 @@ version: 2.0
github_link: cloud/access-acct/resources.md
---
-For more information, or in the event of issues, you can find help and information as follows:
+For more information, or in the {% glossarytooltip c57aef7c-97b4-4b2b-a999-8001accef1fe %}event{% endglossarytooltip %} of issues, you can find help and information as follows:
### Documentation
We have the following resources available:
@@ -28,4 +28,4 @@ We have the following resources available:
* [Configuration]({{ page.baseurl}}config-guide/bk-config-guide.html)
### Technical support
-See [Get help with your deployment]({{ page.baseurl }}cloud/get-help.html)
\ No newline at end of file
+See [Get help with your deployment]({{ page.baseurl }}cloud/welcome/get-help.html)
diff --git a/guides/v2.0/cloud/access-acct/trouble.md b/guides/v2.0/cloud/access-acct/trouble.md
index ea2988fca01..6a88f4b942f 100644
--- a/guides/v2.0/cloud/access-acct/trouble.md
+++ b/guides/v2.0/cloud/access-acct/trouble.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: Troubleshoot deployment
menu_title: Troubleshoot deployment
menu_order: 700
diff --git a/guides/v2.0/cloud/admin/admin-submodules.md b/guides/v2.0/cloud/admin/admin-submodules.md
index 795acde678d..d91a75a77db 100644
--- a/guides/v2.0/cloud/admin/admin-submodules.md
+++ b/guides/v2.0/cloud/admin/admin-submodules.md
@@ -1,7 +1,7 @@
---
layout: default
group:
-subgroup: 30_admin
+subgroup: 030_admin
title: Reuse code across projects with Git submodules
menu_title: Reuse code across projects with Git submodules
menu_order: 200
@@ -34,7 +34,7 @@ When you run `git push`, messages similar to the following display:
Updated submodule git://github.com/orocrm/OroEntitySerializedFieldsBundle: 11 references updated.
## Error validating submodules
-The following error displays if you access a Git URL like `git@github.com:...` because no SSH key is present in the repository referenced by the submodule:
+The following error displays if you access a Git {% glossarytooltip a05c59d3-77b9-47d0-92a1-2cbffe3f8622 %}URL{% endglossarytooltip %} like `git@github.com:...` because no SSH key is present in the repository referenced by the submodule:
Validating submodules.
Found unresolvable links, updating submodules.
diff --git a/guides/v2.0/cloud/before/before-project-owner.md b/guides/v2.0/cloud/before/before-project-owner.md
index 12e0855c914..ddcd96b6f49 100644
--- a/guides/v2.0/cloud/before/before-project-owner.md
+++ b/guides/v2.0/cloud/before/before-project-owner.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 06_setup
+subgroup: 060_setup
title: Account owner tasks
menu_title: Account owner tasks
menu_order: 1
@@ -41,7 +41,7 @@ We recommend against providing the keys over e-mail because it isn't secure; ins
{% endcollapsible %}
## Create project administrators {#cloud-owner-admins}
-As discussed in more detail in [Manage users]({{ page.baseurl }}cloud/admin/admin-user-admin.html), Magento Enterprise Cloud Edition has a number of user roles.
+As discussed in more detail in [Manage users]({{ page.baseurl }}cloud/project/user-admin.html), Magento Enterprise Cloud Edition has a number of user roles.
Typically, the only user the account owner must create is the *project administrator* (also referred to as the super user). This user can create other users and delegate roles as desired.
@@ -80,7 +80,7 @@ The super users you add receive an e-mail inviting them to join the Magento Ente
Initially, a super user must create the project in any of the following ways:
* [Create a sample Magento project from a template]({{ page.baseurl }}cloud/access-acct/first-time-setup_template.html)
-* [Import an existing Magento project]({{ page.baseurl }}cloud/access-acct/first-time-setup_import.html)
+* [Import an existing Magento project]({{ page.baseurl }}cloud/access-acct/first-time-setup_import-first-steps.html)
{% endcollapsible %}
diff --git a/guides/v2.0/cloud/before/before-repos.md b/guides/v2.0/cloud/before/before-repos.md
deleted file mode 100644
index 3959ef3bd11..00000000000
--- a/guides/v2.0/cloud/before/before-repos.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-layout: default
-group: cloud
-subgroup: 05_before
-title: Magento Enterprise Cloud Edition repositories
-menu_title: Magento Enterprise Cloud Edition repositories
-menu_order: 4
-menu_node:
-version: 2.0
-github_link: cloud/before/before-repos.md
----
-
-We use Git to manage your environments (branches) and to deploy them to branch-specific web sites as well as to your production site. Thus, you can use your already-established Git workflow with Magento Enterprise Cloud Edition or you can create a new workflow.
-
-Magento Enterprise Cloud Edition provides a Git server. This server is always available and it's used to deploy the `master` branch to your production site. However, this Git server lacks the GitHub interface and it's not very well suited for use with a development team.
-
-Especially if you already have a GitHub repository and workflows for code review and testing, we recommend you integrate Magento Enterprise Cloud Edition with an existing private Git repository. This repository must be dedicated to Magento; don't share it with other applications (unless you deploy those applications with Magento).
-
-Don't have a Git repository? See the [GitHub](https://help.github.com/articles/create-a-repo){:target="_blank"} documentation for more information.
-
-#### Next step
-[Set up a Magento workspace]({{page.baseurl}}cloud/before/before-workspace.html)
-
-
diff --git a/guides/v2.0/cloud/before/before-setup-env-1_get-start.md b/guides/v2.0/cloud/before/before-setup-env-1_get-start.md
index 2d710217ee6..f9c5979d03e 100644
--- a/guides/v2.0/cloud/before/before-setup-env-1_get-start.md
+++ b/guides/v2.0/cloud/before/before-setup-env-1_get-start.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: Step 1, Get started setting up an environment
menu_title: Step 1, Get started setting up an environment
menu_order: 161
diff --git a/guides/v2.0/cloud/before/before-setup-env-2_clone.md b/guides/v2.0/cloud/before/before-setup-env-2_clone.md
index 895c5e29b29..131e6cb65e0 100644
--- a/guides/v2.0/cloud/before/before-setup-env-2_clone.md
+++ b/guides/v2.0/cloud/before/before-setup-env-2_clone.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: Step 2, Clone the project
menu_title: Step 2, Clone the project
menu_order: 162
@@ -37,7 +37,7 @@ To clone the project's `master` environment:
magento-cloud environment:list
- `magento-cloud environment:list` displays environment hierarchies whereas `git branch` displays does not. If you have any nested environments, use `magento-cloud environment:list`.
+ `magento-cloud environment:list` displays environment hierarchies whereas `git branch` does not. If you have any nested environments, use `magento-cloud environment:list`.
5. Fetch origin branches:
@@ -48,7 +48,7 @@ To clone the project's `master` environment:
git pull origin
## Change the Magento Admin URL, user name, and password
-This section discusses how to change Magento Admin parameters for security reasons. If you change the variables in the `master` branch, you have to do it only once because other environments inherit the variables from `master`.
+This section discusses how to change {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %} parameters for security reasons. If you change the variables in the `master` branch, you have to do it only once because other environments inherit the variables from `master`.
If your master branch is already configured, skip this section and continue with [Step 3: Clone or branch an environment](#setenv-new-env).
@@ -67,7 +67,7 @@ If you're not sure whether or not the master branch has been configured, enter t
magento-cloud variable:set ADMIN_PASSWORD admin_A456 -e master
6. Wait while the project redeploys.
-7. To set the Admin URI to `magento_A8v10`, enter:
+7. To set the {% glossarytooltip 29ddb393-ca22-4df9-a8d4-0024d75739b1 %}Admin{% endglossarytooltip %} URI to `magento_A8v10`, enter:
magento-cloud variable:set ADMIN_URL magento_A8v10 -e master
6. Wait while the project redeploys.
diff --git a/guides/v2.0/cloud/before/before-setup-env-cron.md b/guides/v2.0/cloud/before/before-setup-env-cron.md
index d5f96d69794..12e1b62a0ec 100644
--- a/guides/v2.0/cloud/before/before-setup-env-cron.md
+++ b/guides/v2.0/cloud/before/before-setup-env-cron.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: Step 4, Set up cron
menu_title: Step 4, Set up cron
menu_order: 164
diff --git a/guides/v2.0/cloud/before/before-setup-env-env.md b/guides/v2.0/cloud/before/before-setup-env-env.md
index 60636faddeb..883fc03c5ef 100644
--- a/guides/v2.0/cloud/before/before-setup-env-env.md
+++ b/guides/v2.0/cloud/before/before-setup-env-env.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: Step 5, Clone or branch an environment
menu_title: Step 5, Clone or branch an environment
menu_order: 165
@@ -15,7 +15,7 @@ github_link: cloud/before/before-setup-env-env.md
{::options syntax_highlighter="rouge" /}
-Now that you've changed the Magento Admin variables, you should create a new environment for your development work; this new environment inherits the variable values from master.
+Now that you've changed the {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %} variables, you should create a new environment for your development work; this new environment inherits the variable values from master.
After you create the branch, update project dependencies so you can install the Magento software locally.
diff --git a/guides/v2.0/cloud/before/before-setup-env-install.md b/guides/v2.0/cloud/before/before-setup-env-install.md
index af1fa3406f9..2a43fda42c2 100644
--- a/guides/v2.0/cloud/before/before-setup-env-install.md
+++ b/guides/v2.0/cloud/before/before-setup-env-install.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: Step 6, Install Magento
menu_title: Step 6, Install Magento
menu_order: 166
@@ -16,7 +16,7 @@ github_link: cloud/before/before-setup-env-install.md
To be able to customize the Magento software on your local machine, you should install it using the following information:
* Host name or IP address of your machine
-* Admin user name, password, and URI you created earlier
+* {% glossarytooltip 29ddb393-ca22-4df9-a8d4-0024d75739b1 %}Admin{% endglossarytooltip %} user name, password, and URI you created earlier
Before you begin, list the environment variables.
diff --git a/guides/v2.0/cloud/before/before-setup-env-keys.md b/guides/v2.0/cloud/before/before-setup-env-keys.md
index 6200825002a..842b8420d88 100644
--- a/guides/v2.0/cloud/before/before-setup-env-keys.md
+++ b/guides/v2.0/cloud/before/before-setup-env-keys.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: Step 3, Set up authentication keys
menu_title: Step 3, Set up authentication keys
menu_order: 163
@@ -14,9 +14,9 @@ github_link: cloud/before/before-setup-env-keys.md
{::options syntax_highlighter="rouge" /}
## Add authentication keys to the project
-This topic discusses how to add authentication keys to the project, which means the keys don't have to be stored in the Git repository. (Developers who need to update Magento dependencies or to install extension need authentication keys locally; this is discussed in the next section.)
+This topic discusses how to add authentication keys to the project, which means the keys don't have to be stored in the Git repository. (Developers who need to update Magento dependencies or to install {% glossarytooltip 55774db9-bf9d-40f3-83db-b10cc5ae3b68 %}extension{% endglossarytooltip %} need authentication keys locally; this is discussed in the next section.)
-_Only a [project administrator]({{ page.baseurl }}cloud/admin/admin-user-admin.html#cloud-role-project) can perform this task._ The project administrator must have the public and private authentication keys for Magento Enterprise Cloud Edition. You should contact the Magento Enterprise Cloud Edition account owner to get the keys.
+_Only a [project administrator]({{ page.baseurl }}cloud/project/user-admin.html#cloud-role-project) can perform this task._ The project administrator must have the public and private authentication keys for Magento Enterprise Cloud Edition. You should contact the Magento Enterprise Cloud Edition account owner to get the keys.
To set up authentication keys in the project:
diff --git a/guides/v2.0/cloud/before/before-setup-env-parent.md b/guides/v2.0/cloud/before/before-setup-env-parent.md
index 1a9377f7099..48261566fad 100644
--- a/guides/v2.0/cloud/before/before-setup-env-parent.md
+++ b/guides/v2.0/cloud/before/before-setup-env-parent.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: Set up an environment and install Magento locally
menu_title: Set up an environment and install Magento locally
menu_order: 160
diff --git a/guides/v2.0/cloud/before/before-setup-env-perms.md b/guides/v2.0/cloud/before/before-setup-env-perms.md
index b36e92b0fb1..7a2cd53020b 100644
--- a/guides/v2.0/cloud/before/before-setup-env-perms.md
+++ b/guides/v2.0/cloud/before/before-setup-env-perms.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: Step 7, Set file system permissions and ownership
menu_title: Step 7, Set file system permissions and ownership
menu_order: 167
diff --git a/guides/v2.0/cloud/before/before-workspace-cli.md b/guides/v2.0/cloud/before/before-workspace-cli.md
index bf571cae82e..49ba409a719 100644
--- a/guides/v2.0/cloud/before/before-workspace-cli.md
+++ b/guides/v2.0/cloud/before/before-workspace-cli.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: Step 2, Install the CLI
menu_title: Step 2, Install the CLI
menu_order: 54
@@ -18,7 +18,7 @@ The Magento Enterprise Cloud Edition command-line interface (CLI) helps you mana
To install the Magento Enterprise Cloud Edition CLI:
1. Log in to your local development machine, or switch to, the [Magento file system owner]({{ page.baseurl }}cloud/before/before-workspace-file-sys-owner.html).
-2. Change to a directory to which the Magento file system owner has write access (for example, the web server docroot).
+2. Change to a directory to which the {% glossarytooltip 5e7de323-626b-4d1b-a7e5-c8d13a92c5d3 %}Magento file system owner{% endglossarytooltip %} has write access (for example, the web server docroot).
1. Enter the following command:
curl -sS https://accounts.magento.cloud/cli/installer | php
diff --git a/guides/v2.0/cloud/before/before-workspace-cloud-account.md b/guides/v2.0/cloud/before/before-workspace-cloud-account.md
index 5afc2b20ebc..ea8ffc0da2c 100644
--- a/guides/v2.0/cloud/before/before-workspace-cloud-account.md
+++ b/guides/v2.0/cloud/before/before-workspace-cloud-account.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: Step 1, Set up an account
menu_title: Step 1, Set up an account
menu_order: 52
diff --git a/guides/v2.0/cloud/before/before-workspace-file-sys-owner.md b/guides/v2.0/cloud/before/before-workspace-file-sys-owner.md
index 4305aa7db1b..c64dfffa9ed 100644
--- a/guides/v2.0/cloud/before/before-workspace-file-sys-owner.md
+++ b/guides/v2.0/cloud/before/before-workspace-file-sys-owner.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: Step 6, Set up the Magento file system owner
menu_title: Step 6, Set up the Magento file system owner
menu_order: 58
@@ -13,9 +13,9 @@ github_link: cloud/before/before-workspace-file-sys-owner.md
---
### About the shared group {#mage-owner-about-group}
-To enable the web server to write files and directories in the Magento file system but to also maintain *ownership* by the Magento file system owner, both users must be in the same group. This is necessary so both users can share access to Magento files (including files created using the Magento Admin or other web-based utilities).
+To enable the web server to write files and directories in the Magento file system but to also maintain *ownership* by the Magento file system owner, both users must be in the same group. This is necessary so both users can share access to Magento files (including files created using the {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %} or other web-based utilities).
-This section discusses how to create a new Magento file system owner and put that user in the web server's group. You can use an existing user account if you wish; we recommend the user have a strong password for security reasons.
+This section discusses how to create a new {% glossarytooltip 5e7de323-626b-4d1b-a7e5-c8d13a92c5d3 %}Magento file system owner{% endglossarytooltip %} and put that user in the web server's group. You can use an existing user account if you wish; we recommend the user have a strong password for security reasons.
### Step 1: Create the Magento file system owner and give the user a strong password {#mage-owner-create-user}
This section discusses how to create the Magento file system owner. (Magento file system owner is another term for the *command-line user*.)
diff --git a/guides/v2.0/cloud/before/before-workspace-magento-prereqs.md b/guides/v2.0/cloud/before/before-workspace-magento-prereqs.md
index 14fa1da92b5..6a58323a03b 100644
--- a/guides/v2.0/cloud/before/before-workspace-magento-prereqs.md
+++ b/guides/v2.0/cloud/before/before-workspace-magento-prereqs.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: Step 4, Install Magento prerequisites
menu_title: Step 4, Install Magento prerequisites
menu_order: 56
@@ -18,7 +18,7 @@ For you to install Magento locally, you must install the prequisite software:
* [Apache]({{ page.baseurl }}install-gde/prereq/apache.html)
You can also use nginx but those instructions aren't documented at this time.
-* PHP
+* {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %}
* [CentOS]({{ page.baseurl }}install-gde/prereq/php-centos.html)
* [Ubuntu]({{ page.baseurl }}install-gde/prereq/php-ubuntu.html)
diff --git a/guides/v2.0/cloud/before/before-workspace-parent.md b/guides/v2.0/cloud/before/before-workspace-parent.md
index 4fab61dcea8..075fb3e8d79 100644
--- a/guides/v2.0/cloud/before/before-workspace-parent.md
+++ b/guides/v2.0/cloud/before/before-workspace-parent.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: Set up a Magento workspace
menu_title: Set up a Magento workspace
menu_order: 50
diff --git a/guides/v2.0/cloud/before/before-workspace-php.md b/guides/v2.0/cloud/before/before-workspace-php.md
index a3de9af3e87..2e1461a7fdd 100644
--- a/guides/v2.0/cloud/before/before-workspace-php.md
+++ b/guides/v2.0/cloud/before/before-workspace-php.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: Step 5, Set up PHP and MySQL
menu_title: Step 5, Set up PHP and MySQL
menu_order: 57
@@ -13,7 +13,7 @@ github_link: cloud/before/before-workspace-php.md
---
## Set up PHP {#cloud-first-php}
-When you're working with the Magento Cloud CLI, local environment settings come from the machine on which you're working, not from Magento Enterprise Cloud Edition. For example, certain things (like debugging) require a larger PHP `memory_limit` than most PHP distributions provide by default.
+When you're working with the Magento Cloud CLI, local environment settings come from the machine on which you're working, not from Magento Enterprise Cloud Edition. For example, certain things (like debugging) require a larger {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} `memory_limit` than most PHP distributions provide by default.
{% collapsible To set `memory_limit`: %}
diff --git a/guides/v2.0/cloud/before/before-workspace-ssh.md b/guides/v2.0/cloud/before/before-workspace-ssh.md
index c9fb1aa20f6..5a00ec370ce 100644
--- a/guides/v2.0/cloud/before/before-workspace-ssh.md
+++ b/guides/v2.0/cloud/before/before-workspace-ssh.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: Step 3, Enable Secure Shell (SSH)
menu_title: Step 3, Enable Secure Shell (SSH)
menu_order: 55
diff --git a/guides/v2.0/cloud/before/before-workspace.md b/guides/v2.0/cloud/before/before-workspace.md
index 27a5adc3fcf..c8480ab8c93 100644
--- a/guides/v2.0/cloud/before/before-workspace.md
+++ b/guides/v2.0/cloud/before/before-workspace.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: Overview of a Magento workspace
menu_title: Overview of a Magento workspace
menu_order: 51
@@ -14,7 +14,7 @@ github_link: cloud/before/before-workspace.md
The following sections discuss your options for setting up a Magento Enterprise Cloud Edition project.
-We assume you'll install the Magento software so you can use the command line and the Magento Admin on your laptop. That means you must set up the Magento file system owner on your laptop so files and directories you created are owned by that user.
+We assume you'll install the Magento software so you can use the command line and the {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %} on your laptop. That means you must set up the {% glossarytooltip 5e7de323-626b-4d1b-a7e5-c8d13a92c5d3 %}Magento file system owner{% endglossarytooltip %} on your laptop so files and directories you created are owned by that user.
To be able to manage your projects, environments, and services, you must set up the Magento Enterprise Cloud Edition command-line interface (CLI) and Secure Shell (SSH). These tools enable you to perform tasks like:
diff --git a/guides/v2.0/cloud/before/before.md b/guides/v2.0/cloud/before/before.md
deleted file mode 100644
index 982448993b3..00000000000
--- a/guides/v2.0/cloud/before/before.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-layout: default
-group: cloud
-subgroup: 05_before
-title: Before you get started
-menu_title: Before you get started
-menu_order: 1
-menu_node: parent
-version: 2.0
-github_link: cloud/before/before.md
----
-
-
-
-
-## Before you get started
-These topics discuss what you need to do before you get started using Magento Enterprise Cloud Edition:
-
-* Understand [Common terminology]({{page.baseurl}}cloud/before/terms.html).
-* Decide which [Git repository]({{page.baseurl}}cloud/before/before-repos.html) to use (the one provided with Magento Enterprise Cloud Edition or a private repository you already use).
diff --git a/guides/v2.0/cloud/before/integration-ip-addr.md b/guides/v2.0/cloud/before/integration-ip-addr.md
index e25666f678f..b782817bb12 100644
--- a/guides/v2.0/cloud/before/integration-ip-addr.md
+++ b/guides/v2.0/cloud/before/integration-ip-addr.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 08_setup
+subgroup: 080_setup
title: Public IP addresses for integration environments
menu_title: Public IP addresses for integration environments
menu_order: 900
@@ -10,7 +10,7 @@ version: 2.0
github_link: cloud/before/integration-ip-addr.md
---
-This topic lists incoming and outgoing IP addresses used by Magento Enterprise Cloud Edition [integration environments]({{page.baseurl }}cloud/discover-arch.html#cloud-arch-int).These IP addresses are stable, but might change in the future. Prior to any future change, all affected customers will receive ample warning.
+This topic lists incoming and outgoing IP addresses used by Magento Enterprise Cloud Edition [integration environments]({{page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-int).These IP addresses are stable, but might change in the future. Prior to any future change, all affected customers will receive ample warning.
## Outbound IP addresses
This section lists public outbound IP addresses for integration environments.
diff --git a/guides/v2.0/cloud/before/terms.md b/guides/v2.0/cloud/before/terms.md
deleted file mode 100644
index d35c5caef71..00000000000
--- a/guides/v2.0/cloud/before/terms.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-layout: default
-group: cloud
-subgroup: 05_before
-title: Common terms
-menu_title: Common terms
-menu_order: 2
-menu_node:
-version: 2.0
-github_link: cloud/before/terms.md
----
-
-This topic provides definitions for common terms.
-
-Project
-: A container for your Magento cloud deployment, representing your Magento store. A project contains a live deployment and one or more *environments* that enable developers to work on features, fix bugs, or test your site.
-
-The project always has a `master` branch, which corresponds to your live site.
-
-You configure the details of your project using configuration files.
-
-Magento Enterprise Cloud Edition project configuration files
-: A set of `yaml` files located in the project root directory that define the project. These files are the only way to configure or reconfigure the project. In particular,
-
- * [`/.magento.app.yaml`]({{page.baseurl}}cloud/project/project-conf-files_magento-app.html), which configures things like the project name, access roles, service relationships, web server configuration (such as docroot), disk space, mount points, and cron.
- * [`/.magento/routes.yaml`]({{page.baseurl}}cloud/project/project-conf-files_routes.html), which specifies routes for your environments, URL redirects, server side includes, caching, and so on.
- * [`/.magento/services.yaml`]({{page.baseurl}}cloud/project/project-conf-files_services.html), which defines available services and their disk space allocations.
-
-Environment
-: A project's Git branch. You can use environments for development and testing, and use a standard Git workflow to synchronize (pull) and merge (push) to its parent. Merging an environment with the `master` enables you to deploy the changes to your staging and production systems.
-
-In addition, you can create up to seven other active branches for development and testing. An active environment is a branch in the Cloud Git repo you're using for development and integration. (Additional environments are available for additional cost.)
-
-
-You can have an unlimited number of *inactive* environments. An inactive environment is a Git branch you either deleted from the Cloud Git repository or one that is not associated with the Cloud Git repository at all. For example, you might already have several Git branches with Magento code that you don't need to use for Magento Enterprise Cloud Edition. As long as you don't add those environments to the Cloud Git repo, they don't count against your total of eight active environments.
-
-
-Service
-: Third-party software for your Magento store. For example, PHP, MySQL, Elasticsearch, Solr, Redis, Varnish, and Fastly are all examples of services. You configure services using `services.yaml` and use them in your environments for development, testing, and in your live deployment.
-
diff --git a/guides/v2.0/cloud/bk-cloud.md b/guides/v2.0/cloud/bk-cloud.md
index 897f2c6aaa0..23c2fe49b70 100644
--- a/guides/v2.0/cloud/bk-cloud.md
+++ b/guides/v2.0/cloud/bk-cloud.md
@@ -1,11 +1,11 @@
---
layout: default
group: cloud
-subgroup: 01_welcome
+subgroup: 010_welcome
title: Welcome to Magento Enterprise Cloud Edition
landing-page: Cloud
menu_title: Welcome to Magento Enterprise Cloud Edition
-menu_order: 1
+menu_order: 10
menu_node: parent
version: 2.0
github_link: cloud/bk-cloud.md
@@ -30,12 +30,11 @@ middleman between your code and deployment.
You can have an unlimited number of *inactive* environments. An inactive environment is a Git branch you either deleted from the Cloud Git repository or one that is not associated with the Cloud Git repository at all. For example, you might already have several Git branches with Magento code that you don't need to use for Magento Enterprise Cloud Edition. As long as you don't add those environments to the Cloud Git repo, they don't count against your total of eight active environments.
* You can add fully managed services like MySQL, Elasticsearch, Redis, RabbitMQ, and so on, without requiring external add-ons.
-* We use a robust Composer build process.
+* We use a robust {% glossarytooltip d85e2d0a-221f-4d03-aa43-0cda9f50809e %}Composer{% endglossarytooltip %} build process.
* You can increase the amount of memory and CPU as needed.
#### Related topics
-* [Magento Enterprise Cloud Edition requirements]({{page.baseurl}}cloud/cloud-requirements.html)
-* [Common terms]({{page.baseurl}}cloud/before/terms.html)
-* [Architecture]({{page.baseurl}}cloud/discover-arch.html)
-* [Workflow]({{page.baseurl}}cloud/discover-workflow.html)
+* [Magento Enterprise Cloud Edition requirements]({{page.baseurl}}cloud/requirements/cloud-requirements.html)
+* [Architecture]({{page.baseurl}}cloud/reference/discover-arch.html)
+* [Workflow]({{page.baseurl}}cloud/welcome/discover-workflow.html)
diff --git a/guides/v2.0/cloud/discover-tools.md b/guides/v2.0/cloud/discover-tools.md
deleted file mode 100644
index ac2ec1e1d1f..00000000000
--- a/guides/v2.0/cloud/discover-tools.md
+++ /dev/null
@@ -1,42 +0,0 @@
----
-layout: default
-group: cloud
-subgroup: 01_welcome
-title: Tooling
-menu_title: Tooling
-menu_order: 5
-menu_node:
-version: 2.0
-github_link: cloud/discover-tools.md
----
-
-Our job is to make developers and teams more productive, so we spent a lot of
-time not only in making Magento Enterprise Cloud Edition a very robust hosting environment but also
-a very easy one to use.
-
-### Command-line interface (CLI)
-We offer a feature-rich CLI that allows you to manage and automate every aspect
-of Magento Enterprise Cloud Edition.
-
-### Web Interface
-You can configure most aspects of Magento Enterprise Cloud Edition using our Web Interface
-Even a non-technical user can create new environments, can set up
-access control, map domains. and manage users.
-
-A project manager could use Magento Enterprise Cloud Edition without ever using the CLI.
-
-### Git
-Everything in Magento Enterprise Cloud Edition is managed using a Git repository. You can simply modify a couple
-of configuration files and manage almost all aspects of operations that way.
-
-### Seamless GitHub integration
-We have perfectly seamless integrations for Github. You can
-log in to Magento Enterprise Cloud Edition with your Bitbucket or Github account. And you can have
-Magento Enterprise Cloud Edition environments be automatically created for every pull-request or
-branch you create and get feedback on deployments right there without
-switching tools.
-
-#### Related topics
-* [Set up the Magento workspace]({{page.baseurl}}cloud/before/before-workspace.html)
-* [Project quick tour]({{page.baseurl}}cloud/project/projects.html)
-* [Magento Enterprise Cloud Edition repositories]({{page.baseurl}}cloud/before/before-repos.html)
diff --git a/guides/v2.0/cloud/env/environment-vars-parent.md b/guides/v2.0/cloud/env/environment-vars-parent.md
index a32f765ed57..894d82ee1ad 100644
--- a/guides/v2.0/cloud/env/environment-vars-parent.md
+++ b/guides/v2.0/cloud/env/environment-vars-parent.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 12_env
+subgroup: 120_env
title: Environment variables
menu_title: Environment variables
menu_order: 70
diff --git a/guides/v2.0/cloud/env/environment-vars_cloud.md b/guides/v2.0/cloud/env/environment-vars_cloud.md
index 68202d10543..d0777667181 100644
--- a/guides/v2.0/cloud/env/environment-vars_cloud.md
+++ b/guides/v2.0/cloud/env/environment-vars_cloud.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 12_env
+subgroup: 120_env
title: Magento Enterprise Cloud Edition environment variables
menu_title: Magento Enterprise Cloud Edition environment variables
menu_order: 75
diff --git a/guides/v2.0/cloud/env/environment-vars_magento.md b/guides/v2.0/cloud/env/environment-vars_magento.md
index cfe62afa2d2..ecaae24598a 100644
--- a/guides/v2.0/cloud/env/environment-vars_magento.md
+++ b/guides/v2.0/cloud/env/environment-vars_magento.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 12_env
+subgroup: 120_env
title: Magento application environment variables
menu_title: Magento application environment variables
menu_order: 80
@@ -80,7 +80,7 @@ The following table lists variables that you can override using environment vari
For an example, see [Step 1, Get started setting up an environment]({{page.baseurl}}cloud/access-acct/set-up-env.html#setup-env-adminurl).
## Troubleshooting {#cloud-env-vars-tshoot}
-In the event something goes wrong and you can't access your environment after it deploys, try the following:
+In the {% glossarytooltip c57aef7c-97b4-4b2b-a999-8001accef1fe %}event{% endglossarytooltip %} something goes wrong and you can't access your environment after it deploys, try the following:
* [SSH to the environment]({{page.baseurl}}cloud/env/environments-start.html#env-start-tunn) and make sure [services]({{page.baseurl}}cloud/env/environments-start.html#cloud-ssh-tunnel-service) are running.
* Restore your snapshot:
diff --git a/guides/v2.0/cloud/env/environment-vars_over.md b/guides/v2.0/cloud/env/environment-vars_over.md
index 85063cacea1..eece41c9cc0 100644
--- a/guides/v2.0/cloud/env/environment-vars_over.md
+++ b/guides/v2.0/cloud/env/environment-vars_over.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 12_env
+subgroup: 120_env
title: Overview of environment variables
menu_title: Overview of environment variables
menu_order: 71
@@ -13,7 +13,7 @@ github_link: cloud/env/environment-vars_over.md
---
## Environment variables {#cloud-env-set-vars}
-Magento Enterprise Cloud Edition enables you to create variables in your environment that override configuration options. For example, we strongly recommend you *immediately* change your Magento Admin URI and administrative user's password to prevent someone guessing your login and changing settings without your knowledge.
+Magento Enterprise Cloud Edition enables you to create variables in your environment that override configuration options. For example, we strongly recommend you *immediately* change your {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %} URI and administrative user's password to prevent someone guessing your login and changing settings without your knowledge.
We support the following types of variables:
@@ -26,7 +26,7 @@ Environment variable names must use the characters `a-z`, `A-Z`, `0-9`, and `.`,
Platform variables that are expressed as base64-encoded JSON object can be up to 4KB in size.
-Environment variables have an `env` namespace.
+Environment variables have an `env` {% glossarytooltip 621ef86b-7314-4fbc-a80d-ab7fa45a27cb %}namespace{% endglossarytooltip %}.
Variables are hierarchical, which means that if a variable is not overridden, it is inherited from the parent environment and is indicated as inherited.
diff --git a/guides/v2.0/cloud/env/environments-ssh.md b/guides/v2.0/cloud/env/environments-ssh.md
index 0359819f086..bc8812716db 100644
--- a/guides/v2.0/cloud/env/environments-ssh.md
+++ b/guides/v2.0/cloud/env/environments-ssh.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 12_env
+subgroup: 120_env
title: SSH into your environment
menu_title: SSH into your environment
menu_order: 3
@@ -10,9 +10,9 @@ version: 2.0
github_link: cloud/env/environments-ssh.md
---
-Before you can use SSH to connect to an [integration]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-int) environment, you must add your [SSH public key]({{page.baseurl}}cloud/before/before-workspace-ssh.html) to your account.
+Before you can use SSH to connect to an [integration]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-int) environment, you must add your [SSH public key]({{page.baseurl}}cloud/before/before-workspace-ssh.html) to your account.
-For security reasons, to add your public key to a [production]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-prod) or [staging]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-stage) system, you must create a [support ticket]({{ page.baseurl }}cloud/get-help.html).
+For security reasons, to add your public key to a [production]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-prod) or [staging]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-stage) system, you must create a [support ticket]({{ page.baseurl }}cloud/welcome/get-help.html).
You can then connect using SSH in any of the following ways:
@@ -52,8 +52,8 @@ To SSH to an environment using the Web Interface:
{% endcollapsibleh3 %}
## Staging and production systems {#cloud-ssh-stage}
-You can't use the `magento-cloud` command line to SSH into staging and production systems. To SSH into staging and production systems, first create a [support ticket]({{ page.baseurl }}cloud/get-help.html) requesting for your public key to be added to the system. The user and URL will have been supplied when the system was provisioned.
+You can't use the `magento-cloud` command line to SSH into staging and production systems. To SSH into staging and production systems, first create a [support ticket]({{ page.baseurl }}cloud/welcome/get-help.html) requesting for your public key to be added to the system. The user and {% glossarytooltip a05c59d3-77b9-47d0-92a1-2cbffe3f8622 %}URL{% endglossarytooltip %} will have been supplied when the system was provisioned.
#### Related topics
* [Manage your environments]({{page.baseurl}}cloud/env/environments.html)
-* [Adding keys to your environment]({{page.baseurl}}cloud/before/before-workspace.html#cloud-ssh-cli-ssh)
\ No newline at end of file
+* [Adding keys to your environment]({{page.baseurl}}cloud/before/before-workspace.html#cloud-ssh-cli-ssh)
diff --git a/guides/v2.0/cloud/env/environments-start.md b/guides/v2.0/cloud/env/environments-start.md
index 4c005f8f36d..a7f0bf80c1d 100644
--- a/guides/v2.0/cloud/env/environments-start.md
+++ b/guides/v2.0/cloud/env/environments-start.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 12_env
+subgroup: 120_env
title: Get started with an environment
menu_title: Get started with an environment
menu_order: 2
diff --git a/guides/v2.0/cloud/env/environments.md b/guides/v2.0/cloud/env/environments.md
index d29536d50e5..af224ffe3d1 100644
--- a/guides/v2.0/cloud/env/environments.md
+++ b/guides/v2.0/cloud/env/environments.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 12_env
+subgroup: 120_env
title: Manage your environments
menu_title: Manage your environments
menu_order: 1
@@ -72,7 +72,7 @@ In this example, the following can happen:
* Creates the Sprint-X environments and grants contributor privileges to developers to create the story environments.
* Creates all the environments and grants contributor privileges to developers.
-2. When the sprint is finished (or when the story is closed), the administrator can review the work by accessing the website of the feature environment. The new feature is then merged back to the Sprint-X environment.
+2. When the sprint is finished (or when the story is closed), the administrator can review the work by accessing the {% glossarytooltip a3c8f20f-b067-414e-9781-06378c193155 %}website{% endglossarytooltip %} of the feature environment. The new feature is then merged back to the Sprint-X environment.
3. The administrator synchronizes Sprint-X with QA so all features can be tested.
3. The administrator backs up the live site, then merges the Sprint-X environment into the `master` environment, making it live.
4. The administrator synchronizes the next sprint's environment with data from the `master` environment to repeat and continue the development process.
diff --git a/guides/v2.0/cloud/howtos/custom-theme.md b/guides/v2.0/cloud/howtos/custom-theme.md
index 739f4d77437..0943e530364 100644
--- a/guides/v2.0/cloud/howtos/custom-theme.md
+++ b/guides/v2.0/cloud/howtos/custom-theme.md
@@ -1,16 +1,16 @@
---
layout: default
group: cloud
-subgroup: 15_howto
+subgroup: How To
title: Install a theme
menu_title: Install a theme
menu_order: 60
-menu_node:
+menu_node:
version: 2.0
github_link: cloud/howtos/custom-theme.md
---
-This topic discusses how to install a theme either by extracting its code to the Magento file system or using Composer.
+This topic discusses how to install a {% glossarytooltip d2093e4a-2b71-48a3-99b7-b32af7158019 %}theme{% endglossarytooltip %} either by extracting its code to the Magento file system or using {% glossarytooltip d85e2d0a-221f-4d03-aa43-0cda9f50809e %}Composer{% endglossarytooltip %}.
### Get started
diff --git a/guides/v2.0/cloud/howtos/debug.md b/guides/v2.0/cloud/howtos/debug.md
index 5cfe9ca30a4..0c6b0c7ce10 100644
--- a/guides/v2.0/cloud/howtos/debug.md
+++ b/guides/v2.0/cloud/howtos/debug.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 15_howto
+subgroup: How To
title: Run a PHP debugger
menu_title: Run a PHP debugger
menu_order: 100
@@ -10,7 +10,7 @@ version: 2.0
github_link: cloud/howtos/debug.md
---
-This topic discusses how to run a PHP debugger using Xdebug as an example.
+This topic discusses how to run a {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} debugger using Xdebug as an example.
### Get started
diff --git a/guides/v2.0/cloud/howtos/environment-tutorial-env-merge.md b/guides/v2.0/cloud/howtos/environment-tutorial-env-merge.md
index f6d3415e77f..8096f3f8f8a 100644
--- a/guides/v2.0/cloud/howtos/environment-tutorial-env-merge.md
+++ b/guides/v2.0/cloud/howtos/environment-tutorial-env-merge.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 15_howto
+subgroup: How To
title: Merge and delete an environment (tutorial)
menu_title: Merge and delete an environment (tutorial)
menu_order: 51
@@ -61,7 +61,7 @@ Before you delete an environment, make sure you don't need it anymore. You canno
You cannot delete the master environment of any project.
-You must be a [project administrator]({{page.baseurl}}cloud/admin/admin-user-admin.html#cloud-role-project), [environment administrator]({{page.baseurl}}cloud/admin/admin-user-admin.html#cloud-role-env), or [account owner]({{page.baseurl}}cloud/admin/admin-user-admin.html#cloud-role-acct-owner) to perform this task.
+You must be a [project administrator]({{page.baseurl}}cloud/project/user-admin.html#cloud-role-project), [environment administrator]({{page.baseurl}}cloud/project/user-admin.html#cloud-role-env), or [account owner]({{page.baseurl}}cloud/project/user-admin.html#cloud-role-acct-owner) to perform this task.
This section discusses how to optionally delete an environment in the following ways:
diff --git a/guides/v2.0/cloud/howtos/how-to.md b/guides/v2.0/cloud/howtos/how-to.md
index e796f68ea23..029249c7567 100644
--- a/guides/v2.0/cloud/howtos/how-to.md
+++ b/guides/v2.0/cloud/howtos/how-to.md
@@ -1,7 +1,8 @@
+
---
layout: default
group: cloud
-subgroup: 15_howto
+subgroup: How To
title: Tutorials
menu_title: Tutorials
menu_order: 1
diff --git a/guides/v2.0/cloud/howtos/howto-upgrade-parent.md b/guides/v2.0/cloud/howtos/howto-upgrade-parent.md
index 5adb2cafff9..e3f3752961e 100644
--- a/guides/v2.0/cloud/howtos/howto-upgrade-parent.md
+++ b/guides/v2.0/cloud/howtos/howto-upgrade-parent.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 15_howto
+subgroup: How To
title: Test a Magento patch or upgrade
menu_title: Test a Magento patch or upgrade
menu_order: 25
diff --git a/guides/v2.0/cloud/howtos/install-components.md b/guides/v2.0/cloud/howtos/install-components.md
index d3a60ff1294..2d5919974cd 100644
--- a/guides/v2.0/cloud/howtos/install-components.md
+++ b/guides/v2.0/cloud/howtos/install-components.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 15_howto
+subgroup: How To
title: Install extensions
menu_title: Install extensions
menu_order: 41
@@ -15,11 +15,11 @@ github_link: cloud/howtos/install-components.md
This topic discusses how to install *extensions*, which can be any of the following:
* Modules (extend Magento capabilities)
-* Themes (change the look and feel of your storefront and Admin)
+* Themes (change the look and feel of your {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %} and Admin)
* Language packages (localize the storefront and Admin)
-
This topic discusses how to install extensions you purchased from Magento Marketplace. You can use the same procedure to install any extension; all you need is the extension's Composer name. To find it, open the extension's composer.json file and note the values for "name" and "version".
+
This topic discusses how to install extensions you purchased from Magento Marketplace. You can use the same procedure to install any extension; all you need is the extension's {% glossarytooltip d85e2d0a-221f-4d03-aa43-0cda9f50809e %}Composer{% endglossarytooltip %} name. To find it, open the extension's composer.json file and note the values for "name" and "version".
@@ -28,7 +28,7 @@ This topic discusses how to install *extensions*, which can be any of the follow
To install a extension, you must:
-1. Obtain the extension from [Magento Marketplace](https://marketplace.magento.com){:target="_blank"} or elsewhere.
+1. Obtain the {% glossarytooltip 55774db9-bf9d-40f3-83db-b10cc5ae3b68 %}extension{% endglossarytooltip %} from [Magento Marketplace](https://marketplace.magento.com){:target="_blank"} or elsewhere.
1. [Get the extension's Composer name](#cloud-howto-comp-composer) and version from your purchase history.
2. In your local Magento Enterprise Cloud Edition project, [update the Magento `composer.json`](#cloud-howto-comp-json) file with the name and version of the extension.
3. [Push](#cloud-howto-comp-push) the changes to your environment.
diff --git a/guides/v2.0/cloud/howtos/patch-magento.md b/guides/v2.0/cloud/howtos/patch-magento.md
index d646dc9e9a7..4ecb0cb238d 100644
--- a/guides/v2.0/cloud/howtos/patch-magento.md
+++ b/guides/v2.0/cloud/howtos/patch-magento.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 15_howto
+subgroup: How To
title: Test a Magento patch
menu_title: Test a Magento patch
menu_order: 27
diff --git a/guides/v2.0/cloud/howtos/sample-data.md b/guides/v2.0/cloud/howtos/sample-data.md
index bbdad5b7bfc..4734d86ad10 100644
--- a/guides/v2.0/cloud/howtos/sample-data.md
+++ b/guides/v2.0/cloud/howtos/sample-data.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 15_howto
+subgroup: How To
title: Install optional sample data
menu_title: Install optional sample data
menu_order: 70
@@ -36,7 +36,7 @@ To install sample data:
git add -A && git commit -m "Install sample data"
git push origin
3. Wait for the project to deploy.
-4. Verify the installation was successful by going to your storefront main page.
+4. Verify the installation was successful by going to your {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %} main page.
The URL displays on the command line under the heading `Environment routes:` after the project deploys.
5. Take a snapshot of your environment:
diff --git a/guides/v2.0/cloud/howtos/update-components.md b/guides/v2.0/cloud/howtos/update-components.md
index aed0a5453f4..e1060a7bff4 100644
--- a/guides/v2.0/cloud/howtos/update-components.md
+++ b/guides/v2.0/cloud/howtos/update-components.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 15_howto
+subgroup: How To
title: Update extensions
menu_title: Update extensions
menu_order: 45
@@ -17,7 +17,7 @@ This topic discusses how to update extensions you previously installed from Mage
Before you continue, you must:
* Know the extension's [Composer name](#update-composer-name) and version
-* Know the extension is compatible with your project (in particular, check the required PHP version)
+* Know the {% glossarytooltip 55774db9-bf9d-40f3-83db-b10cc5ae3b68 %}extension{% endglossarytooltip %} is compatible with your project (in particular, check the required {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} version)
You must check in composer.lock to your environment; otherwise, the extension won't load in Magento Enterprise Cloud Edition. That's because we run composer install (which uses composer.lock) and not composer update when we build and deploy the environment.
diff --git a/guides/v2.0/cloud/howtos/update-extensions-parent.md b/guides/v2.0/cloud/howtos/update-extensions-parent.md
index f274f5e41e5..41a33711373 100644
--- a/guides/v2.0/cloud/howtos/update-extensions-parent.md
+++ b/guides/v2.0/cloud/howtos/update-extensions-parent.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 15_howto
+subgroup: How To
title: Install and update extensions
menu_title: Install and update extensions
menu_order: 40
diff --git a/guides/v2.0/cloud/howtos/upgrade-magento.md b/guides/v2.0/cloud/howtos/upgrade-magento.md
index 70906ce16d4..591d1d6ba92 100644
--- a/guides/v2.0/cloud/howtos/upgrade-magento.md
+++ b/guides/v2.0/cloud/howtos/upgrade-magento.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 15_howto
+subgroup: How To
title: Test a Magento upgrade
menu_title: Test a Magento upgrade
menu_order: 26
diff --git a/guides/v2.0/cloud/live/live-prot.md b/guides/v2.0/cloud/live/live-prot.md
index 92e7ed3e7db..f86bc5b6ba1 100644
--- a/guides/v2.0/cloud/live/live-prot.md
+++ b/guides/v2.0/cloud/live/live-prot.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 40_live
+subgroup: 160_live
title: Protective block
menu_title: Protective block
menu_order: 900
@@ -47,7 +47,7 @@ to stay mostly online.
parts of a request, such as a query string, cookies or any additional
headers, might be removed from GET requests. All other requests may be
blocked entirely—this could apply to logging in, form submission, or
-product checkout.
+product {% glossarytooltip 278c3ce0-cd4c-4ffc-a098-695d94d73bde %}checkout{% endglossarytooltip %}.
Unblocking is automated upon resolution of the security risk. The block
is removed soon after you apply a security upgrade and removes
diff --git a/guides/v2.0/cloud/live/live-sanity-check.md b/guides/v2.0/cloud/live/live-sanity-check.md
index d13b3dd037f..433bffdb84c 100644
--- a/guides/v2.0/cloud/live/live-sanity-check.md
+++ b/guides/v2.0/cloud/live/live-sanity-check.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 40_live
+subgroup: 160_live
title: Build and deploy before pushing to staging or production
menu_title: Build and deploy before pushing to staging or production
menu_order: 90
@@ -10,9 +10,9 @@ version: 2.0
github_link: cloud/live/live-sanity-check.md
---
-This topic discusses tasks we strongly recommend you perform before pushing code from an [integration system]({{ page.baseurl}}cloud/discover-arch.html#cloud-arch-int) to either [staging]({{ page.baseurl}}cloud/discover-arch.html#cloud-arch-stage}}) or [production]({{ page.baseurl}}cloud/discover-arch.html#cloud-arch-prod}}). Failure to perform these tasks can result in additional debugging and delays in testing your site.
+This topic discusses tasks we strongly recommend you perform before pushing code from an [integration system]({{ page.baseurl}}cloud/reference/discover-arch.html#cloud-arch-int) to either [staging]({{ page.baseurl}}cloud/reference/discover-arch.html#cloud-arch-stage}}) or [production]({{ page.baseurl}}cloud/reference/discover-arch.html#cloud-arch-prod}}). Failure to perform these tasks can result in additional debugging and delays in testing your site.
-As discussed in [Deployment process]({{ page.baseurl }}cloud/discover-deploy.html), building and deployment is a five-phase process. This topic discusses how to simulate build and deploy steps locally, which can expose issues early in your development process when they're easier to debug and fix.
+As discussed in [Deployment process]({{ page.baseurl }}cloud/reference/discover-deploy.html), building and deployment is a five-phase process. This topic discusses how to simulate build and deploy steps locally, which can expose issues early in your development process when they're easier to debug and fix.
Do your testing in an integration or staging environment _only_. Do not do any testing in production; the production environment is your live site; it shouldn't be used for testing.
@@ -21,7 +21,7 @@ Your staging environment is better for testing because it has Fastly, New Relic,
## Step 1: Push code to the Cloud server
-Before you continue, make sure you push all current code to the remote Cloud server so that, in event of issues, you can recover the state of the Magento application.
+Before you continue, make sure you push all current code to the remote Cloud server so that, in {% glossarytooltip c57aef7c-97b4-4b2b-a999-8001accef1fe %}event{% endglossarytooltip %} of issues, you can recover the state of the Magento application.
### Get started
@@ -45,12 +45,12 @@ Before you continue, make sure you push all current code to the remote Cloud ser
{% endcollapsible %}
## Step 2: Build phase
-During the [build phase]({{ page.baseurl }}cloud/discover-deploy.html#cloud-deploy-over-phases-build), we perform the following tasks:
+During the [build phase]({{ page.baseurl }}cloud/reference/discover-deploy.html#cloud-deploy-over-phases-build), we perform the following tasks:
* Apply patches distributed to all Magento Enterprise Cloud Edition customers
* Apply patches we provided specifically to you
* Enable all modules
-* Compile code and the dependency injection configuration
+* Compile code and the {% glossarytooltip 2be50595-c5c7-4b9d-911c-3bf2cd3f7beb %}dependency injection{% endglossarytooltip %} configuration
Before you continue, you must know the file system path to any patch we provided specifically to you. Typically, hot fixes are in the `/m2-hotfixes` directory.
@@ -111,18 +111,18 @@ Before you continue, you must know the file system path to any patch we provided
... more ...
Interception cache generation... 7/7 [============================] 100% 5 mins 324.0 MiB
-If errors display, debug them if possible or open a [support ticket]({{ page.baseurl }}cloud/get-help.html) to get additional assistance.
+If errors display, debug them if possible or open a [support ticket]({{ page.baseurl }}cloud/welcome/get-help.html) to get additional assistance.
We strongly recommend you do all your testing in an integration or staging environment only, and _not_ in production.
{% endcollapsible %}
## Step 3: Deploy phase
-During the [deployment phase]({{ page.baseurl }}cloud/discover-deploy.html#cloud-deploy-over-phases-hook), we perform the following tasks:
+During the [deployment phase]({{ page.baseurl }}cloud/reference/discover-deploy.html#cloud-deploy-over-phases-hook), we perform the following tasks:
* Installs the Magento application if it isn't already
* If the Magento application is installed, upgrades components
-* Clears the cache
+* Clears the {% glossarytooltip 0bc9c8bc-de1a-4a06-9c99-a89a29c30645 %}cache{% endglossarytooltip %}
* Sets the Magento application for [`production`]({{ page.baseurl}}config-guide/bootstrap/magento-modes.html#mode-production) mode
{% collapsible To deploy your site: %}
diff --git a/guides/v2.0/cloud/live/live.md b/guides/v2.0/cloud/live/live.md
index 7bebeff2877..95d1b3abeb6 100644
--- a/guides/v2.0/cloud/live/live.md
+++ b/guides/v2.0/cloud/live/live.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 40_live
+subgroup: 160_live
title: Go live
menu_title: Go live
menu_order: 800
diff --git a/guides/v2.0/cloud/live/stage-prod-live.md b/guides/v2.0/cloud/live/stage-prod-live.md
index 184078d26cc..475d07cfc88 100644
--- a/guides/v2.0/cloud/live/stage-prod-live.md
+++ b/guides/v2.0/cloud/live/stage-prod-live.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 40_live
+subgroup: 160_live
title: From integration to live
menu_title: From integration to live
menu_order: 1
diff --git a/guides/v2.0/cloud/live/stage-prod-migrate-prereq.md b/guides/v2.0/cloud/live/stage-prod-migrate-prereq.md
index 14db5ce5608..d8516b660c0 100644
--- a/guides/v2.0/cloud/live/stage-prod-migrate-prereq.md
+++ b/guides/v2.0/cloud/live/stage-prod-migrate-prereq.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 40_live
+subgroup: 160_live
title: Prepare to migrate data
menu_title: Prepare to migrate data
menu_order: 101
@@ -29,7 +29,7 @@ After setting this up, your workflow is to code and test in your integration sys
### Get your access URLs {#cloud-live-migrate-urls}
Your Magento Enterprise Cloud Edition OneDrive account includes an onboarding document that contains your Git, SSH, and project URLs for staging and production. You must know those URLs to continue.
-* Git URL format:
+* Git {% glossarytooltip a05c59d3-77b9-47d0-92a1-2cbffe3f8622 %}URL{% endglossarytooltip %} format:
* Staging: `git@git.ent.magento.cloud:_stg.git`
* Production: `git@git.ent.magento.cloud:.git`
diff --git a/guides/v2.0/cloud/live/stage-prod-migrate.md b/guides/v2.0/cloud/live/stage-prod-migrate.md
index 56f62c35246..52654605e2e 100644
--- a/guides/v2.0/cloud/live/stage-prod-migrate.md
+++ b/guides/v2.0/cloud/live/stage-prod-migrate.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 40_live
+subgroup: 160_live
title: Migrate data
menu_title: Migrate data
menu_order: 200
@@ -20,7 +20,7 @@ To migrate your database and code:
In the event of issues, make fixes in your integration system, test them, and push updated code to your staging repository using Git commands.
### Migrate static files {#cloud-live-migrate-static}
-This section discusses how to migrate static files from your `pub/media` directory to staging or production. We recommend using the Linux remote synchronization and file transfer command [`rsync`](https://en.wikipedia.org/wiki/Rsync){:target="_blank"}. rsync uses an algorithm that minimizes the amount of data by moving only the portions of files that have changed; in addition, it supports compression.
+This section discusses how to migrate {% glossarytooltip 363662cb-73f1-4347-a15e-2d2adabeb0c2 %}static files{% endglossarytooltip %} from your `pub/media` directory to staging or production. We recommend using the Linux remote synchronization and file transfer command [`rsync`](https://en.wikipedia.org/wiki/Rsync){:target="_blank"}. rsync uses an algorithm that minimizes the amount of data by moving only the portions of files that have changed; in addition, it supports compression.
We suggest using the following syntax:
diff --git a/guides/v2.0/cloud/live/stage-prod-over.md b/guides/v2.0/cloud/live/stage-prod-over.md
index a6c69b655e9..d3ec70583ea 100644
--- a/guides/v2.0/cloud/live/stage-prod-over.md
+++ b/guides/v2.0/cloud/live/stage-prod-over.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 40_live
+subgroup: 160_live
title: Overview of staging and production
menu_title: Overview of staging and production
menu_order: 3
@@ -16,7 +16,7 @@ background: none!important;
}
-As discussed in more detail in [Architecture]({{ page.baseurl }}cloud/discover-arch.html), Magento Enterprise Cloud Edition has three types of systems:
+As discussed in more detail in [Architecture]({{ page.baseurl }}cloud/reference/discover-arch.html), Magento Enterprise Cloud Edition has three types of systems:
* *Integration*, used by a developer to write custom code and test it.
@@ -78,7 +78,7 @@ After you fix bugs, you merge Feature1 with master, making that code potentially
*Assisted deployment* means that your staging and production systems require you to perform the tasks discussed in the following paragraphs.
### Support ticket
-Create a [support ticket]({{ page.baseurl }}cloud/get-help.html) to notify us you're ready to move to either staging or production.
+Create a [support ticket]({{ page.baseurl }}cloud/welcome/get-help.html) to notify us you're ready to move to either staging or production.
{% include cloud/hooks.md %}
diff --git a/guides/v2.0/cloud/live/stage-prod-parent.md b/guides/v2.0/cloud/live/stage-prod-parent.md
index f6d128b93de..0d954367591 100644
--- a/guides/v2.0/cloud/live/stage-prod-parent.md
+++ b/guides/v2.0/cloud/live/stage-prod-parent.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 40_live
+subgroup: 160_live
title: Migrate to staging and production
menu_title: Migrate to staging and production
menu_order: 100
diff --git a/guides/v2.0/cloud/live/stage-prod-test.md b/guides/v2.0/cloud/live/stage-prod-test.md
index 7ca3358a706..9cdc6cae84e 100644
--- a/guides/v2.0/cloud/live/stage-prod-test.md
+++ b/guides/v2.0/cloud/live/stage-prod-test.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 40_live
+subgroup: 160_live
title: Testing
menu_title: Testing
menu_order: 199
diff --git a/guides/v2.0/cloud/project/admin-git-push.md b/guides/v2.0/cloud/project/admin-git-push.md
index 8bd0e1740f2..29d3699165a 100644
--- a/guides/v2.0/cloud/project/admin-git-push.md
+++ b/guides/v2.0/cloud/project/admin-git-push.md
@@ -1,7 +1,7 @@
---
layout: default
group:
-subgroup: 10_project
+subgroup: 100_project
title: git push details
menu_title: git push details (remove or rewrite)
menu_order: 100
@@ -17,7 +17,7 @@ of the `git push` command might look like with Magento Enterprise Cloud Edition.
Magento Enterprise Cloud Edition is extremely versatile; for each project and depending
on the state of the project, the output can vary wildly.
-This topic discusses a sample PHP project with a lot of data backends; and that uses MySQL, Redis, and Elasticsearch. It has its PHP dependencies in a `composer.json` file and it uses the Ruby library `sass` to compile the SCSS
+This topic discusses a sample {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} project with a lot of data backends; and that uses MySQL, Redis, and Elasticsearch. It has its PHP dependencies in a `composer.json` file and it uses the Ruby library `sass` to compile the SCSS
during its build process.
In this example, a developer wants to work on a new feature so they created a new environment by
@@ -73,7 +73,7 @@ application a container with the correct configuration.
Installing build dependencies...
Installing ruby build dependencies: sass
-In this case we have a dependency on the Ruby `sass` library so it has installed
+In this case we have a dependency on the Ruby `sass` {% glossarytooltip 08968dbb-2eeb-45c7-ae95-ffca228a7575 %}library{% endglossarytooltip %} so it has installed
it. (Again, this comes from `.magento.app.yaml`.)
Found a `composer.json`, installing dependencies.
diff --git a/guides/v2.0/cloud/project/project-conf-files_magento-app.md b/guides/v2.0/cloud/project/project-conf-files_magento-app.md
index e3b688c910d..c338bbfee5a 100644
--- a/guides/v2.0/cloud/project/project-conf-files_magento-app.md
+++ b/guides/v2.0/cloud/project/project-conf-files_magento-app.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: .magento.app.yaml
menu_title: .magento.app.yaml
menu_order: 50
@@ -18,7 +18,7 @@ This file controls the application and the way it is built and deployed on Magen
[Sample `.magento.app.yaml`](https://github.com/magento/magento-cloud/blob/master/.magento.app.yaml){:target="_blank"}
-
Changes you make using .yaml files affect your integration environment only. For technical reasons, neither staging nor production environments use .yaml files. To make these changes in a staging or production environment, you must create a Support ticket.
+
Changes you make using .yaml files affect your integration environment only. For technical reasons, neither staging nor production environments use .yaml files. To make these changes in a staging or production environment, you must create a Support ticket.
The following sections discuss properties in `.magento.app.yaml`.
@@ -46,7 +46,7 @@ For example, if the value of `name` is `app`, you must use `app:php` in the upst
{% endcollapsible %}
## `type` and `build` {#cloud-yaml-platform-type}
-The `type` and `build` properties are used to build and run the project. The only supported `type` currently is PHP.
+The `type` and `build` properties are used to build and run the project. The only supported `type` currently is {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %}.
Supported versions:
diff --git a/guides/v2.0/cloud/project/project-conf-files_routes.md b/guides/v2.0/cloud/project/project-conf-files_routes.md
index 404d7ca33fb..d5e893940c1 100644
--- a/guides/v2.0/cloud/project/project-conf-files_routes.md
+++ b/guides/v2.0/cloud/project/project-conf-files_routes.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: routes.yaml
menu_title: routes.yaml
menu_order: 76
@@ -13,7 +13,7 @@ github_link: cloud/project/project-conf-files_routes.md
---
## `routes.yaml` overview {#cloud-yaml-routes-over}
-A *route* describes how an incoming URL is processed by
+A *route* describes how an incoming {% glossarytooltip a05c59d3-77b9-47d0-92a1-2cbffe3f8622 %}URL{% endglossarytooltip %} is processed by
Magento Enterprise Cloud Edition.
`routes.yaml` defines routes for development, integration, staging, and production
@@ -28,7 +28,7 @@ This file is located at `.magento/routes.yaml` in your project.
[Sample `routes.yaml`](https://github.com/magento/magento-cloud/blob/master/.magento/routes.yaml){:target="_blank"}
-
Changes you make using .yaml files affect your integration environment only. For technical reasons, neither staging nor production environments use .yaml files. To make these changes in a staging or production environment, you must create a Support issue.
+
Changes you make using .yaml files affect your integration environment only. For technical reasons, neither staging nor production environments use .yaml files. To make these changes in a staging or production environment, you must create a Support issue.
@@ -42,7 +42,7 @@ If you do not have a `routes.yaml` file, the following default is used:
## Route templates {#cloud-yaml-routes-temp}
`routes.yaml` is a list of templated routes and their
configurations. A route template can look like this: `http://www.{default}/` or
-`https://{default}/blog`, where `{default}` is the fully qualified domain
+`https://{default}/blog`, where `{default}` is the fully qualified {% glossarytooltip 41aee03b-a5d5-49c2-8839-894090ef4e86 %}domain{% endglossarytooltip %}
name configured for the project.
{% collapsible Click to show/hide content %}
@@ -117,7 +117,7 @@ but it will issue a 301 redirect for `http://www.example.com/mypath` (to
## Wildcard routes {#cloud-yaml-routes-sample-wild}
Magento Enterprise Cloud Edition supports wildcard routes, so you can map multiple subdomains to the
-same application. This works both for redirect and upstream routes. You can
+same application. This works both for {% glossarytooltip 510de766-1ebd-4546-bf38-c618c9c945d2 %}redirect{% endglossarytooltip %} and upstream routes. You can
simply prefix the route with a star (`*`), for example `*.example.com`, and
`www.example.com`, `blog.example.com`, and `us.example.com` all get routed to the
same application.
diff --git a/guides/v2.0/cloud/project/project-conf-files_services-elastic.md b/guides/v2.0/cloud/project/project-conf-files_services-elastic.md
index 1312bc48b73..3301b20f481 100644
--- a/guides/v2.0/cloud/project/project-conf-files_services-elastic.md
+++ b/guides/v2.0/cloud/project/project-conf-files_services-elastic.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: Set up the elasticsearch service
menu_title: Set up the elasticsearch service
menu_order: 85
@@ -14,7 +14,7 @@ github_link: cloud/project/project-conf-files_services-elastic.md
[Elasticsearch](https://www.elastic.co){:target="_blank"} is an open source product that enables you to take data from any source, any format, and search, and visualize it in real time.
-* Elasticsearch performs quick and advanced searches on products in the catalog
+* Elasticsearch performs quick and advanced searches on products in the {% glossarytooltip 8d40d668-4996-4856-9f81-b1386cf4b14f %}catalog{% endglossarytooltip %}
* Elasticsearch analyzers support multiple languages
* Supports stop words and synonyms
* Indexing does not impact customers until reindex is completed
diff --git a/guides/v2.0/cloud/project/project-conf-files_services-mysql.md b/guides/v2.0/cloud/project/project-conf-files_services-mysql.md
index e9d9027db3a..5867be5441b 100644
--- a/guides/v2.0/cloud/project/project-conf-files_services-mysql.md
+++ b/guides/v2.0/cloud/project/project-conf-files_services-mysql.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: Set up the mysql service
menu_title: Set up the mysql service
menu_order: 82
diff --git a/guides/v2.0/cloud/project/project-conf-files_services-rabbit.md b/guides/v2.0/cloud/project/project-conf-files_services-rabbit.md
index b6379456722..08e3c09d5b1 100644
--- a/guides/v2.0/cloud/project/project-conf-files_services-rabbit.md
+++ b/guides/v2.0/cloud/project/project-conf-files_services-rabbit.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: Set up the rabbitmq service
menu_title: Set up the rabbitmq service
menu_order: 86
@@ -12,7 +12,7 @@ version: 2.0
github_link: cloud/project/project-conf-files_services-rabbit.md
---
-The Message Queue Framework (MQF) is a system within Magento Enterprise Edition that allows a module to publish messages to queues. It also defines the consumers that will receive the messages asynchronously. The MQF uses [RabbitMQ](http://www.rabbitmq.com){:target="_blank"} as the messaging broker, which provides a scalable platform for sending and receiving messages. It also includes a mechanism for storing undelivered messages. RabbitMQ is based on the Advanced Message Queuing Protocol (AMQP) 0.9.1 specification.
+The Message Queue Framework (MQF) is a system within Magento Enterprise Edition that allows a {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} to publish messages to queues. It also defines the consumers that will receive the messages asynchronously. The MQF uses [RabbitMQ](http://www.rabbitmq.com){:target="_blank"} as the messaging broker, which provides a scalable platform for sending and receiving messages. It also includes a mechanism for storing undelivered messages. RabbitMQ is based on the Advanced Message Queuing Protocol (AMQP) 0.9.1 specification.
We support RabbitMQ version 3.5.
@@ -103,9 +103,9 @@ dependencies:
amqp-utils: "0.5.1"
{% endhighlight %}
-Then, when you SSH into your PHP container, you enter any `amqp-`
+Then, when you SSH into your {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} container, you enter any `amqp-`
command available to manage your queues.
### Connect from your PHP application {#cloud-rabbitmq-conn-php}
-To connect to RabbitMQ using your PHP application, add a PHP library (like
+To connect to RabbitMQ using your PHP application, add a PHP {% glossarytooltip 08968dbb-2eeb-45c7-ae95-ffca228a7575 %}library{% endglossarytooltip %} (like
[PHP AMQPlib](https://github.com/videlalvaro/php-amqplib){:target="_blank"}) to your source tree.
diff --git a/guides/v2.0/cloud/project/project-conf-files_services-redis.md b/guides/v2.0/cloud/project/project-conf-files_services-redis.md
index e806e944585..b0d39faf92f 100644
--- a/guides/v2.0/cloud/project/project-conf-files_services-redis.md
+++ b/guides/v2.0/cloud/project/project-conf-files_services-redis.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: Set up the redis service
menu_title: Set up the redis service
menu_order: 83
diff --git a/guides/v2.0/cloud/project/project-conf-files_services-solr.md b/guides/v2.0/cloud/project/project-conf-files_services-solr.md
index c0078708197..83c4d37b7d2 100644
--- a/guides/v2.0/cloud/project/project-conf-files_services-solr.md
+++ b/guides/v2.0/cloud/project/project-conf-files_services-solr.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: Set up the solr service
menu_title: Set up the solr service
menu_order: 84
@@ -16,7 +16,7 @@ Solr is highly reliable, scalable and fault tolerant, providing distributed
indexing, replication and load-balanced querying, automated failover and
recovery, centralized configuration, and more.
-Solr uses the Lucene Java search library for full-text indexing and search. Your applications interact with Solr using HTTP POST (in JSON, XML, CSV, or binary formats) to index documents and using HTTP GET to retrieve search results back as JSON, XML, or a variety of other formats (Python, Ruby, PHP, CSV, binary, and so on). If you're a programmer, try the Solr tutorial. Whether you're a programmer or not, read the Solr FAQ.
+Solr uses the Lucene Java search {% glossarytooltip 08968dbb-2eeb-45c7-ae95-ffca228a7575 %}library{% endglossarytooltip %} for full-text indexing and search. Your applications interact with Solr using HTTP POST (in JSON, XML, CSV, or binary formats) to index documents and using HTTP GET to retrieve search results back as JSON, XML, or a variety of other formats (Python, Ruby, PHP, CSV, binary, and so on). If you're a programmer, try the Solr tutorial. Whether you're a programmer or not, read the Solr FAQ.
[More information about Solr]({{page.baseurl}}config-guide/solr/solr-overview.html).
diff --git a/guides/v2.0/cloud/project/project-conf-files_services.md b/guides/v2.0/cloud/project/project-conf-files_services.md
index b8ea876da5b..fd211d551c3 100644
--- a/guides/v2.0/cloud/project/project-conf-files_services.md
+++ b/guides/v2.0/cloud/project/project-conf-files_services.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: services.yaml
menu_title: services.yaml
menu_order: 81
@@ -24,7 +24,7 @@ This file is located at `.magento/services.yaml` in your project.
[Sample `services.yaml` file](https://github.com/magento/magento-cloud/blob/master/.magento/services.yaml){:target="_blank"}
-
Changes you make using .yaml files affect your integration environment only. For technical reasons, neither staging nor production environments use .yaml files. To make these changes in a staging or production environment, you must create a Support issue.
+
Changes you make using .yaml files affect your integration environment only. For technical reasons, neither staging nor production environments use .yaml files. To make these changes in a staging or production environment, you must create a Support issue.
diff --git a/guides/v2.0/cloud/project/project-integrate-blackfire.md b/guides/v2.0/cloud/project/project-integrate-blackfire.md
index 77b5fb304c2..26c8a9bec77 100644
--- a/guides/v2.0/cloud/project/project-integrate-blackfire.md
+++ b/guides/v2.0/cloud/project/project-integrate-blackfire.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: Blackfire integration
menu_title: Blackfire integration
menu_order: 105
@@ -78,7 +78,7 @@ To verify Blackfire works, you can SSH to the environment and run a command as f
1. Log in to the Web UI.
2. In the right pane, click the name of your environment.
3. Hover the mouse pointer over **Access site**.
-4. Copy the **SSH access** URL to the clipboard as the following figure shows.
+4. Copy the **SSH access** {% glossarytooltip a05c59d3-77b9-47d0-92a1-2cbffe3f8622 %}URL{% endglossarytooltip %} to the clipboard as the following figure shows.
{:width="500px"}
5. Enter that command in your terminal window to log in using SSH.
@@ -115,7 +115,7 @@ To verify Blackfire works, you can SSH to the environment and run a command as f
## Profile your site {#cloud-int-black-profile}
To start profiling your site using Blackfire:
-1. Install the Blackfire.io Companion browser plug-in for your browser.
+1. Install the Blackfire.io Companion browser {% glossarytooltip 9fceecbe-31be-4e49-aac7-11d155a85382 %}plug-in{% endglossarytooltip %} for your browser.
For example, to install the Chrome Companion, see [Blackfire.io documentation](https://blackfire.io/docs/integrations/chrome){:target="_blank"}.
2. Use the Web UI to find the **Web access** URL for your environment as the following figure shows:
diff --git a/guides/v2.0/cloud/project/project-integrate-github.md b/guides/v2.0/cloud/project/project-integrate-github.md
index 308b0b7ec92..03a8995142b 100644
--- a/guides/v2.0/cloud/project/project-integrate-github.md
+++ b/guides/v2.0/cloud/project/project-integrate-github.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: GitHub integration
menu_title: GitHub integration
menu_order: 110
@@ -93,7 +93,7 @@ To enable the GitHub integration for your environment:
Fetch branches: yes
Payload URL: https://us.magento.cloud/api/projects/ov58dlacU2e/integrations/wO8a0eoamxwcg/hook
-5. Copy the Payload URL displayed by the command and continue with the next section.
+5. Copy the Payload {% glossarytooltip a05c59d3-77b9-47d0-92a1-2cbffe3f8622 %}URL{% endglossarytooltip %} displayed by the command and continue with the next section.
## Add the webhook {#cloud-int-gh-hook}
To add the webhook to your GitHub repository:
diff --git a/guides/v2.0/cloud/project/project-integrate-parent.md b/guides/v2.0/cloud/project/project-integrate-parent.md
index e12819c1a8a..56dc9af2cd4 100644
--- a/guides/v2.0/cloud/project/project-integrate-parent.md
+++ b/guides/v2.0/cloud/project/project-integrate-parent.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: Integrations
menu_title: Integrations
menu_order: 100
diff --git a/guides/v2.0/cloud/project/project-multi-sites.md b/guides/v2.0/cloud/project/project-multi-sites.md
index 9a7475674f8..dbc9fbecd21 100644
--- a/guides/v2.0/cloud/project/project-multi-sites.md
+++ b/guides/v2.0/cloud/project/project-multi-sites.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: Set up multiple Cloud websites or stores
menu_title: Set up multiple Cloud websites or stores
menu_order: 35
@@ -17,8 +17,8 @@ To set up multiple stores, you must:
1. [Configure your local installation]({{ page.baseurl }}config-guide/multi-site/ms_over.html) and test it locally.
2. Configure Magento Enterprise Cloud edition routes and variables.
-3. Push the changes to an [integration environment]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-int) and test it.
-4. To deploy multiple stores to a [staging]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-stage) or [production]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-prod) environment, create a support ticket.
+3. Push the changes to an [integration environment]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-int) and test it.
+4. To deploy multiple stores to a [staging]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-stage) or [production]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-prod) environment, create a support ticket.
## Configure your local installation
To configure your local installation to use multiple stores, see [Multiple websites or stores]({{ page.baseurl }}config-guide/multi-site/ms_over.html).
@@ -27,7 +27,7 @@ To configure your local installation to use multiple stores, see [Multiple websi
After successfully creating and testing multiple stores locally, you must:
1. [Configure routes](#cloud-multi-stores-routes), which specify how incoming URLs are handled by Magento Enterprise Cloud Edition.
-2. [Set up websites, stores, and store views](#cloud-multi-stores-admin) in your Magento Enterprise Cloud Edition server's Admin.
+2. [Set up websites, stores, and store views](#cloud-multi-stores-admin) in your Magento Enterprise Cloud Edition server's {% glossarytooltip 29ddb393-ca22-4df9-a8d4-0024d75739b1 %}Admin{% endglossarytooltip %}.
3. [Modify `magento-vars.php`](#cloud-multi-stores-magento-vars) to specify the values of the `MAGE_RUN_TYPE` and `MAGE_RUN_CODE` variables.
4. [Deploy](#cloud-multi-stores-deploy) to your integration branch and test.
@@ -35,7 +35,7 @@ After successfully creating and testing multiple stores locally, you must:
Magento Enterprise Edition *routes* define how incoming URLs are processed. The way you configure routes depends on how you want your site to operate. We suggest configuring routes for integration as follows. You can edit the values later if your needs change.
-
This section discusses how to configure your integration environment only. To set up routes in a staging or production environment, you must create a Support ticket.
+
This section discusses how to configure your integration environment only. To set up routes in a staging or production environment, you must create a Support ticket.
To configure routes in an integration environment:
@@ -102,7 +102,7 @@ Make sure you name your websites, stores, and store views in your Cloud Admin th
See [Set up multiple websites, stores, and store views in the Admin]({{ page.baseurl }}config-guide/multi-site/ms_websites.html).
### Modify `magento-vars.php` {#cloud-multi-stores-magento-vars}
-Instead of configuring an nginx virtual host, pass the `MAGE_RUN_CODE` and `MAGE_RUN_TYPE` variables using `magento-vars.php` which is located in your Magento root directory.
+Instead of configuring an {% glossarytooltip b14ef3d8-51fd-48fe-94df-ed069afb2cdc %}nginx{% endglossarytooltip %} virtual host, pass the `MAGE_RUN_CODE` and `MAGE_RUN_TYPE` variables using `magento-vars.php` which is located in your Magento root directory.
1. Open `magento-vars.php` in a text editor.
2. Uncomment everything after the first two lines.
@@ -166,9 +166,9 @@ To deploy and test:
git add -A && git commit -m "Implement multiple sites"
git push origin
2. Wait for deployment to complete.
-3. When deployment is done, in a web browser, go to your site's base URL.
+3. When deployment is done, in a web browser, go to your site's base {% glossarytooltip a05c59d3-77b9-47d0-92a1-2cbffe3f8622 %}URL{% endglossarytooltip %}.
The URL must be in the format: `http://---`
For example, `http://french---master-benrmky-dyrozemqbw72k.us.magentosite.cloud/`
-4. Make sure you test your site thoroughly.
\ No newline at end of file
+4. Make sure you test your site thoroughly.
diff --git a/guides/v2.0/cloud/project/project-patch.md b/guides/v2.0/cloud/project/project-patch.md
index 63e3bfa1266..a83762c76e0 100644
--- a/guides/v2.0/cloud/project/project-patch.md
+++ b/guides/v2.0/cloud/project/project-patch.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: Test a Magento patch
menu_title: Test a Magento patch
menu_order: 17
diff --git a/guides/v2.0/cloud/project/project-priv-repos.md b/guides/v2.0/cloud/project/project-priv-repos.md
index a254e638b8d..ea512349ec2 100644
--- a/guides/v2.0/cloud/project/project-priv-repos.md
+++ b/guides/v2.0/cloud/project/project-priv-repos.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: Pull code from a private Git repository
menu_title: Pull code from a private Git repository
menu_order: 600
@@ -10,7 +10,7 @@ version: 2.0
github_link: cloud/project/project-priv-repos.md
---
-Your Magento Enterprise Cloud Edition project can include code located in a private Git repository (for example, a module or theme). To do so, you must add your project's public SSH key to your private Git repository and update your project's `composer.json`.
+Your Magento Enterprise Cloud Edition project can include code located in a private Git repository (for example, a {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} or theme). To do so, you must add your project's public SSH key to your private Git repository and update your project's `composer.json`.
To add a deployment key to your private GitHub repository, you must be the administrator of that repository.
diff --git a/guides/v2.0/cloud/project/project-routes-more-cache.md b/guides/v2.0/cloud/project/project-routes-more-cache.md
index a00e3aa043c..b36243cb176 100644
--- a/guides/v2.0/cloud/project/project-routes-more-cache.md
+++ b/guides/v2.0/cloud/project/project-routes-more-cache.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: Caching
menu_title: Caching
menu_order: 77
@@ -73,7 +73,7 @@ header value. If no `Cache-Control` header is in the response, we use the
`default_ttl` key.
## Cache key {#cloud-cache-key}
-To decide how to cache a response, Magento Enterprise Cloud Edition builds a cache key
+To decide how to {% glossarytooltip 0bc9c8bc-de1a-4a06-9c99-a89a29c30645 %}cache{% endglossarytooltip %} a response, Magento Enterprise Cloud Edition builds a cache key
depending on several factors and store the response associated with this
key. When a request comes with the same cache key, the response is
reused. Its purpose is similar to the HTTP [`Vary` header](https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44){:target="_blank"}.
diff --git a/guides/v2.0/cloud/project/project-routes-more-redir.md b/guides/v2.0/cloud/project/project-routes-more-redir.md
index 247613dceb4..5500f7ee6ed 100644
--- a/guides/v2.0/cloud/project/project-routes-more-redir.md
+++ b/guides/v2.0/cloud/project/project-routes-more-redir.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: Redirects
menu_title: Redirects
menu_order: 78
@@ -28,7 +28,7 @@ Using whole-route redirects, you can define very basic routes in `routes.yaml`.
to: http://www.{default}/
## Partial redirects {#cloud-route-partial}
-In the [`.magento/routes.yaml`]({{page.baseurl}}cloud/project/project-conf-files_routes.html) file you can also add partial redirect rules
+In the [`.magento/routes.yaml`]({{page.baseurl}}cloud/project/project-conf-files_routes.html) file you can also add partial {% glossarytooltip 510de766-1ebd-4546-bf38-c618c9c945d2 %}redirect{% endglossarytooltip %} rules
to existing routes:
http://{default}/:
diff --git a/guides/v2.0/cloud/project/project-routes-more-ssi.md b/guides/v2.0/cloud/project/project-routes-more-ssi.md
index 2f5ed56ab3d..f2006f4cb01 100644
--- a/guides/v2.0/cloud/project/project-routes-more-ssi.md
+++ b/guides/v2.0/cloud/project/project-routes-more-ssi.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: Server side includes
menu_title: Server side includes
menu_order: 79
@@ -12,7 +12,7 @@ version: 2.0
github_link: cloud/project/project-routes-more-ssi.md
---
-[Server side includes](http://httpd.apache.org/docs/current/howto/ssi.html){:target="_site"} (SSI) are directives in HTML pages that get evaluated on the server while the pages are being rendered. Use of server side includes enables you to add dynamically generated content to an existing HTML page without having to serve the entire page.
+[Server side includes](http://httpd.apache.org/docs/current/howto/ssi.html){:target="_site"} (SSI) are directives in {% glossarytooltip a2aff425-07dd-4bd6-9671-29b7edefa871 %}HTML{% endglossarytooltip %} pages that get evaluated on the server while the pages are being rendered. Use of {% glossarytooltip ebe2cd14-d6d4-4d75-b3d7-a4f2384e5af9 %}server side{% endglossarytooltip %} includes enables you to add dynamically generated content to an existing HTML page without having to serve the entire page.
More information about [nginx SSI](http://nginx.org/en/docs/http/ngx_http_ssi_module.html){:target="_blank"}.
diff --git a/guides/v2.0/cloud/project/project-routes-parent.md b/guides/v2.0/cloud/project/project-routes-parent.md
index dc835d08057..188bb720188 100644
--- a/guides/v2.0/cloud/project/project-routes-parent.md
+++ b/guides/v2.0/cloud/project/project-routes-parent.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: Configure routes
menu_title: Configure routes
menu_order: 75
diff --git a/guides/v2.0/cloud/project/project-services-parent.md b/guides/v2.0/cloud/project/project-services-parent.md
index 237ae85f9fa..4530610dccc 100644
--- a/guides/v2.0/cloud/project/project-services-parent.md
+++ b/guides/v2.0/cloud/project/project-services-parent.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: Configure services
menu_title: Configure services
menu_order: 80
diff --git a/guides/v2.0/cloud/project/project-start.md b/guides/v2.0/cloud/project/project-start.md
index dc4db07ec56..73a4d37aebe 100644
--- a/guides/v2.0/cloud/project/project-start.md
+++ b/guides/v2.0/cloud/project/project-start.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: Get started with a project
menu_title: Get started with a project
menu_order: 2
@@ -33,7 +33,7 @@ All commands are shown with required options only. Get help for any `magento-clo
: Clone a project to a directory. To clone the `master` environment, omit `-e `.
`magento-cloud project:info -p `
-: List information about the project, including ID, name, region, URL, and Git URL.
+: List information about the project, including ID, name, region, URL, and Git {% glossarytooltip a05c59d3-77b9-47d0-92a1-2cbffe3f8622 %}URL{% endglossarytooltip %}.
#### Related topics
* [Get started with an environment]({{page.baseurl}}cloud/env/environments-start.html)
diff --git a/guides/v2.0/cloud/project/project-upgrade-parent.md b/guides/v2.0/cloud/project/project-upgrade-parent.md
index 77440b30396..51f89a2bf89 100644
--- a/guides/v2.0/cloud/project/project-upgrade-parent.md
+++ b/guides/v2.0/cloud/project/project-upgrade-parent.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: Test a Magento patch or upgrade
menu_title: Test a Magento patch or upgrade
menu_order: 15
diff --git a/guides/v2.0/cloud/project/project-upgrade.md b/guides/v2.0/cloud/project/project-upgrade.md
index 02715ad0fe8..a8c2dd0fc63 100644
--- a/guides/v2.0/cloud/project/project-upgrade.md
+++ b/guides/v2.0/cloud/project/project-upgrade.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: Test a Magento upgrade
menu_title: Test a Magento upgrade
menu_order: 16
diff --git a/guides/v2.0/cloud/project/project-webint-basic.md b/guides/v2.0/cloud/project/project-webint-basic.md
index 229925a4e25..67abb80473e 100644
--- a/guides/v2.0/cloud/project/project-webint-basic.md
+++ b/guides/v2.0/cloud/project/project-webint-basic.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: Basic project information
menu_title: Basic project information
menu_order: 21
@@ -13,7 +13,7 @@ github_link: cloud/project/project-webint-basic.md
---
## Log in to your project {#project-login}
-The Web Interface URL for your project is available in the following ways:
+The Web Interface {% glossarytooltip a05c59d3-77b9-47d0-92a1-2cbffe3f8622 %}URL{% endglossarytooltip %} for your project is available in the following ways:
* Your welcome e-mail
* The Magento Enterprise Cloud Edition command-line interface (CLI)
@@ -53,7 +53,7 @@ In a web browser, enter the project URL from your welcome e-mail or that you fou
## Access your project and environments {#project-access}
The Web Interface provides several ways to access your project and environments:
-* Your storefront URL (every environment, or branch, has a different URL)
+* Your {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %} URL (every environment, or branch, has a different URL)
* Secure Shell (SSH), a way to interact with services using a command terminal
* Clone the project using the Magento Enterprise Cloud Edition CLI
* Clone the project using Git
@@ -89,7 +89,7 @@ Configuring a project means:
2. Click  (Configure project) next to the project name.
3. See one of the following for more information:
- * [Manage users]({{page.baseurl}}cloud/admin/admin-user-admin.html)
+ * [Manage users]({{page.baseurl}}cloud/project/user-admin.html)
* [Pull code from a private Git repository]({{page.baseurl}}cloud/project/project-priv-repos.html)
{% endcollapsible %}
@@ -113,7 +113,7 @@ Configuring an environment means:
* [Environment settings](#project-conf-env-set)
* [Set environment variables](#project-conf-env-var)
* [Configure routes](#project-conf-env-route)
- * [Manage users]({{page.baseurl}}cloud/admin/admin-user-admin.html)
+ * [Manage users]({{page.baseurl}}cloud/project/user-admin.html)
### Environment settings {#project-conf-env-set}
The following table shows available environment settings.
@@ -141,7 +141,7 @@ The following table shows available environment settings.
### Set environment variables {#project-conf-env-var}
As discussed in [Overview of environment variables]({{page.baseurl}}cloud/env/environment-vars_over.html), environment variables are settings specific to an environment. Variables can be either text or JSON format.
-To view or edit environment variables, you must have at minimum the project reader role with [environment admin]({{ page.baseurl }}cloud/admin/admin-user-admin.html#cloud-role-env) privileges.
+To view or edit environment variables, you must have at minimum the project reader role with [environment admin]({{ page.baseurl }}cloud/project/user-admin.html#cloud-role-env) privileges.
For example, you can change the Magento Admin administrative password using environment variables as follows:
diff --git a/guides/v2.0/cloud/project/project-webint-branch.md b/guides/v2.0/cloud/project/project-webint-branch.md
index 12abefa9a79..29c1e460c6c 100644
--- a/guides/v2.0/cloud/project/project-webint-branch.md
+++ b/guides/v2.0/cloud/project/project-webint-branch.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: Manage environments (branches)
menu_title: Manage environments (branches)
menu_order: 23
diff --git a/guides/v2.0/cloud/project/project-webint-parent.md b/guides/v2.0/cloud/project/project-webint-parent.md
index 6e342ea0a3c..a93bfc6de01 100644
--- a/guides/v2.0/cloud/project/project-webint-parent.md
+++ b/guides/v2.0/cloud/project/project-webint-parent.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: Use the project Web Interface
menu_title: Use the project Web Interface
menu_order: 20
diff --git a/guides/v2.0/cloud/project/project-webint-snap.md b/guides/v2.0/cloud/project/project-webint-snap.md
index c39a699b344..1d96511a8df 100644
--- a/guides/v2.0/cloud/project/project-webint-snap.md
+++ b/guides/v2.0/cloud/project/project-webint-snap.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: Backup and restore (snapshot)
menu_title: Backup and restore (snapshot)
menu_order: 25
diff --git a/guides/v2.0/cloud/project/projects.md b/guides/v2.0/cloud/project/projects.md
index fd702cbc0df..8ddba1f6925 100644
--- a/guides/v2.0/cloud/project/projects.md
+++ b/guides/v2.0/cloud/project/projects.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: Manage your project
menu_title: Manage your project
menu_order: 1
@@ -27,7 +27,7 @@ Log in to your project using Bitbucket, GitHub, Google, or a e-mail address and
{:width="450px"}
### Access the project
-Hovering the mouse pointer over **Access Site** shows how to access your site using a URL or SSH.
+Hovering the mouse pointer over **Access Site** shows how to access your site using a {% glossarytooltip a05c59d3-77b9-47d0-92a1-2cbffe3f8622 %}URL{% endglossarytooltip %} or SSH.
{:width="450px"}
@@ -36,17 +36,17 @@ Click **Configure environment** to create and manage [*environments*]({{page.bas
{:width="450px"}
-This displays the following page, which enables you to configure settings, [variables]({{page.baseurl}}cloud/project/project-conf-files_magento-app.html#cloud-yaml-platform-rel), [routes]({{page.baseurl}}cloud/project/project-conf-files_routes.html), and [users]({{page.baseurl}}cloud/admin/admin-user-admin.html).
+This displays the following page, which enables you to configure settings, [variables]({{page.baseurl}}cloud/project/project-conf-files_magento-app.html#cloud-yaml-platform-rel), [routes]({{page.baseurl}}cloud/project/project-conf-files_routes.html), and [users]({{page.baseurl}}cloud/project/user-admin.html).
{:width="450px"}
### Configure the project
-Click  (edit) to display [users]({{page.baseurl}}cloud/admin/admin-user-admin.html), and [deploy keys]({{page.baseurl}}cloud/project/project-priv-repos.html) associated with the project.
+Click  (edit) to display [users]({{page.baseurl}}cloud/project/user-admin.html), and [deploy keys]({{page.baseurl}}cloud/project/project-priv-repos.html) associated with the project.
{:width="450px"}
### Manage users
-The **Users** tab page enables you to add users to the project and to give them [privileges to access the project and environments]({{page.baseurl}}cloud/admin/admin-user-admin.html).
+The **Users** tab page enables you to add users to the project and to give them [privileges to access the project and environments]({{page.baseurl}}cloud/project/user-admin.html).
{:width="450px"}
diff --git a/guides/v2.0/cloud/project/user-admin.md b/guides/v2.0/cloud/project/user-admin.md
index 1ee44d27576..0d7075eba0d 100644
--- a/guides/v2.0/cloud/project/user-admin.md
+++ b/guides/v2.0/cloud/project/user-admin.md
@@ -1,14 +1,14 @@
---
layout: default
group: cloud
-subgroup: 10_project
+subgroup: 100_project
title: Manage users
menu_title: Manage users
menu_order: 5
menu_node:
version: 2.0
github_link: cloud/project/user-admin.md
-redirect_from: guides/v2.0/cloud/admin/admin-user-admin.html
+redirect_from: guides/v2.0/cloud/project/user-admin.html
---
Magento Enterprise Cloud Edition enables you to administer users by assigning them one or more roles. A *role* provides access and
diff --git a/guides/v2.0/cloud/cli-ref/cli-ref-topic.md b/guides/v2.0/cloud/reference/cli-ref-topic.md
similarity index 96%
rename from guides/v2.0/cloud/cli-ref/cli-ref-topic.md
rename to guides/v2.0/cloud/reference/cli-ref-topic.md
index 1b4a5df7888..e82bc3b1f6c 100644
--- a/guides/v2.0/cloud/cli-ref/cli-ref-topic.md
+++ b/guides/v2.0/cloud/reference/cli-ref-topic.md
@@ -1,13 +1,13 @@
---
layout: default
group: cli
-subgroup: 15_cli
+subgroup: 15_reference
title: CLI command reference
menu_title: CLI command reference
-menu_order: 1
-menu_node: parent
+menu_order: 2
+menu_node:
version: 2.0
-github_link: cloud/cli-ref/cli-ref-topic.md
+github_link: cloud/reference/cli-ref-topic.md
---
## CLI command reference {#cloud-cli-ref}
diff --git a/guides/v2.0/cloud/cloud-composer.md b/guides/v2.0/cloud/reference/cloud-composer.md
similarity index 88%
rename from guides/v2.0/cloud/cloud-composer.md
rename to guides/v2.0/cloud/reference/cloud-composer.md
index 30afcadf38a..93bd90db778 100644
--- a/guides/v2.0/cloud/cloud-composer.md
+++ b/guides/v2.0/cloud/reference/cloud-composer.md
@@ -1,13 +1,13 @@
---
layout: default
group: cloud
-subgroup: 01_welcome
+subgroup: 15_reference
title: How Cloud Uses Composer
menu_title: How Cloud Uses Composer
menu_node:
menu_order: 49
version: 2.0
-github_link: cloud/cloud-composer.md
+github_link: cloud/reference/cloud-composer.md
---
This topic discusses how we use [Composer](https://getcomposer.org/doc){:target="_blank"} to manage dependencies and upgrades in Magento Enterprise Cloud Edition, and provides context about the packages that comprise Cloud, what the packages do, and how they fit together.
@@ -36,10 +36,10 @@ The workflow is as follows:
3. Add `composer.lock` to or update it in your Cloud Git repository.
4. Push the changes to the Cloud environment, which causes Cloud to build and deploy the environment.
-During the [build phase]({{ page.baseurl }}cloud/discover-deploy.html), the Cloud environment runs `composer install` on a fresh clone of your Git branch to retrieve the latest dependencies.
+During the [build phase]({{ page.baseurl }}cloud/reference/discover-deploy.html), the Cloud environment runs `composer install` on a fresh clone of your Git branch to retrieve the latest dependencies.
## Magento Enterprise Cloud Edition packages
-The following sections discuss the Composer packages used by Magento Enterprise Cloud Edition:
+The following sections discuss the {% glossarytooltip d85e2d0a-221f-4d03-aa43-0cda9f50809e %}Composer{% endglossarytooltip %} packages used by Magento Enterprise Cloud Edition:
* [`magento/magento-cloud-metapackage`](#cloud-composer-cloudmeta)
* [`magento/magento-cloud-configuration`](#cloud-composer-cloudconfig)
@@ -70,10 +70,10 @@ MCC versions are specified as: `<100 + x>..*`. For example, Magento EE 2.1.4
We release updated MCC code to add a new patch or to improve the build and deploy hooks.
### `magento/product-enterprise-edition` {#cloud-composer-prodee}
-This metapackage requires Magento application components, including modules, frameworks, themes, and so on.
+This {% glossarytooltip 7490850a-0654-4ce1-83ff-d88c1d7d07fa %}metapackage{% endglossarytooltip %} requires Magento application components, including modules, frameworks, themes, and so on.
## Base packages and file marshaling
-Magento contains two base packages, `magento/magento2-base` and `magento/magento2-ee-base`. These packages contain interstitial files that cannot be classified as extensions, themes, frameworks, or language packages; for example, sample server configuration files, PHP entry points, and so on.
+Magento contains two base packages, `magento/magento2-base` and `magento/magento2-ee-base`. These packages contain interstitial files that cannot be classified as extensions, themes, frameworks, or language packages; for example, sample server configuration files, {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} entry points, and so on.
These files are location-dependent, and cannot reside in the `vendor` directory. They are distributed as part of the base packages, and they rely on hooks located in the `magento/magento-composer-installer` package, which marshals them to the appropriate locations.
diff --git a/guides/v2.0/cloud/discover-arch.md b/guides/v2.0/cloud/reference/discover-arch.md
similarity index 82%
rename from guides/v2.0/cloud/discover-arch.md
rename to guides/v2.0/cloud/reference/discover-arch.md
index e70dc96f09f..78996c180ab 100644
--- a/guides/v2.0/cloud/discover-arch.md
+++ b/guides/v2.0/cloud/reference/discover-arch.md
@@ -1,13 +1,13 @@
---
layout: default
group: cloud
-subgroup: 01_welcome
+subgroup: 15_reference
title: Architecture
menu_title: Architecture
-menu_order: 2
-menu_node:
+menu_order: 1
+menu_node: parent
version: 2.0
-github_link: cloud/discover-arch.md
+github_link: cloud/reference/discover-arch.md
---
Magento Enterprise Cloud Edition enables you to use the following three types of systems.
@@ -30,14 +30,14 @@ This system runs your public-facing store on triple-redundant hardware.
#### Advantage of redundant hardware
Rather than running a traditional active-passive master or master-slave setup, Magento Enterprise Cloud Edition runs a triple-redundant multimaster where all three instances accept reads and writes. This architecture offers zero downtime when scaling, and also provides guaranteed transactional integrity.
-Because of our unique triple-redundant hardware, we can provide you with a set of three gateway servers. Most external services enable you to whitelist multiple IPs, so having more than one fixed IP isn't usually a problem.
+Because of our unique triple-redundant hardware, we can provide you with a set of three gateway servers. Most external services enable you to {% glossarytooltip 34f8f61d-2b48-4628-be06-aaa6e32ddc1f %}whitelist{% endglossarytooltip %} multiple IPs, so having more than one fixed IP isn't usually a problem.
These three gateways map to the three servers in your Magento Enterprise Cloud Edition cluster and retain permanent addresses.
Furthermore, Magento Enterprise Cloud Edition is fully redundant and highly available at every level:
* DNS
-* Content Delivery Network (CDN)
+* {% glossarytooltip f83f1fa7-7a64-467b-b629-c2d0c25d2e7f %}Content Delivery Network{% endglossarytooltip %} (CDN)
* Elastic load balancer (ELB)
* Three-server cluster comprising all Magento services, including the database and web server.
@@ -53,7 +53,7 @@ The following figure shows the technology used in a Magento Enterprise Cloud Edi
Magento Enterprise Cloud Edition seamlessly scales from the smallest six CPU cluster with 11.25GB of RAM to the largest 96 CPU cluster with 180GB of RAM. Our triple-redundant architecture means that upscaling can be conducted swiftly and without downtime: each of the three instances in the cluster is taken out of rotation in turn, upgraded to the new size and returned to rotation.
-In addition, extra web servers can be added to an existing cluster should the constriction be at the PHP level rather than the database level. This provides [*horizontal scaling*](https://en.wikipedia.org/wiki/Scalability#Horizontal_and_vertical_scaling){:target="_blank"} to complement the vertical scaling provided by extra CPUs on the database level.
+In addition, extra web servers can be added to an existing cluster should the constriction be at the {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} level rather than the database level. This provides [*horizontal scaling*](https://en.wikipedia.org/wiki/Scalability#Horizontal_and_vertical_scaling){:target="_blank"} to complement the vertical scaling provided by extra CPUs on the database level.
## Projects {#cloud-arch-projects}
The container for your Magento application is a *project*. The project is your Magento store. Each project has one or more *environments*, which are Git branches that enable developers to work on new features or perform testing. Each environment is comprised of *services*, which are deployed inside highly restricted containers on a grid of servers.
@@ -81,14 +81,13 @@ as easy as managing a monolithic application.
Magento Enterprise Cloud Edition uses:
* Operating system: Debian GNU/Linux 8 (jessie)
-* Web server: nginx 1.8
+* Web server: {% glossarytooltip b14ef3d8-51fd-48fe-94df-ed069afb2cdc %}nginx{% endglossarytooltip %} 1.8
The preceding software is *not* upgradable but versions of [PHP]({{page.baseurl}}cloud/project/project-conf-files_magento-app.html), [MySQL]({{page.baseurl}}cloud/project/project-conf-files_services-mysql.html), [Solr]({{page.baseurl}}cloud/project/project-conf-files_services-solr.html), [Redis]({{page.baseurl}}cloud/project/project-conf-files_services-redis.html), [RabbitMQ]({{page.baseurl}}cloud/project/project-conf-files_services-rabbit.html), and [Elasticsearch]({{page.baseurl}}cloud/project/project-conf-files_services-elastic.html) are configurable.
#### Related topics
-* [Workflow]({{page.baseurl}}cloud/discover-workflow.html)
-* [Deployment process]({{page.baseurl}}cloud/discover-deploy.html)
-* [Tooling]({{page.baseurl}}cloud/discover-tools.html)
-* [Magento Enterprise Cloud Edition requirements]({{page.baseurl}}cloud/cloud-requirements.html)
+* [Workflow]({{page.baseurl}}cloud/welcome/discover-workflow.html)
+* [Deployment process]({{page.baseurl}}cloud/reference/discover-deploy.html)
+* [Magento Enterprise Cloud Edition requirements]({{page.baseurl}}cloud/requirements/cloud-requirements.html)
diff --git a/guides/v2.0/cloud/discover-deploy.md b/guides/v2.0/cloud/reference/discover-deploy.md
similarity index 90%
rename from guides/v2.0/cloud/discover-deploy.md
rename to guides/v2.0/cloud/reference/discover-deploy.md
index 475e0a4f4e9..411e21aa8dc 100644
--- a/guides/v2.0/cloud/discover-deploy.md
+++ b/guides/v2.0/cloud/reference/discover-deploy.md
@@ -1,13 +1,13 @@
---
layout: default
group: cloud
-subgroup: 01_welcome
+subgroup: 15_reference
title: Deployment process
menu_title: Deployment process
menu_order: 4
menu_node:
version: 2.0
-github_link: cloud/discover-deploy.md
+github_link: cloud/reference/discover-deploy.md
---
Deploying Magento means simply pushing the source code to your Git repository. The Git repository is part of your projects cluster so it is totally isolated from
@@ -24,7 +24,7 @@ of the operations does not display in the GitHub session. You can still follow w
## Project configuration {#cloud-deploy-conf}
What makes it all work is a set of YAML configuration files located in the project root directory. These files define your Magento installation and describe its dependencies. Configuration files specify, for
-example, that Magento uses MySQL, some PHP extensions, and Elasticsearch. (These are referred to as *services*.)
+example, that Magento uses MySQL, some {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} extensions, and Elasticsearch. (These are referred to as *services*.)
## Five phases of deployment {#cloud-deploy-over-phases}
Deployment consists of the following phases:
@@ -55,7 +55,7 @@ The default Magento build hook is a CLI command called `magento-cloud:build`. It
* Applies patches located in `vendor/magento/magento-cloud-configuration/patches`, as well as optional project-specific patches in `m2-hotfixes`
* Enables all extensions
-* Regenerates code and the dependency injection configuration (that is, the Magento `var/generation` and `var/di` directories) using `bin/magento setup:di:compile`.
+* Regenerates code and the {% glossarytooltip 2be50595-c5c7-4b9d-911c-3bf2cd3f7beb %}dependency injection{% endglossarytooltip %} configuration (that is, the Magento `var/generation` and `var/di` directories) using `bin/magento setup:di:compile`.
It is important to note that at this point the cluster has not been
created yet. So you should not try to connect to a database or imagine
@@ -75,7 +75,7 @@ It also means that reverting a deployment is basically
instantaneous.
### Phase 4: Deploy slugs and cluster {#cloud-deploy-over-phases-slugclus}
-Now we provision your applications and all the backend services you
+Now we provision your applications and all the {% glossarytooltip 74d6d228-34bd-4475-a6f8-0c0f4d6d0d61 %}backend{% endglossarytooltip %} services you
need:
* Mounts each service in its own container
@@ -95,7 +95,7 @@ When this script runs, you have access to all the services in your environment (
There are two default deploy hooks. One is `pre-deploy.php`, which does some necessary cleanup and retrieval of
resources that were generated in the build hook. The second is `bin/magento magento-cloud:deploy`, which does the following
-* If Magento is not installed, it installs Magento with `bin/magento setup:install`, updates the deployment configuration, `app/etc/env.php`, and the database for your specified environment (for example, Redis and website URLs).
+* If Magento is not installed, it installs Magento with `bin/magento setup:install`, updates the deployment configuration, `app/etc/env.php`, and the database for your specified environment (for example, Redis and {% glossarytooltip a3c8f20f-b067-414e-9781-06378c193155 %}website{% endglossarytooltip %} URLs).
* If Magento is installed, performs any necessary upgrades.
diff --git a/guides/v2.0/cloud/reference/git-integration.md b/guides/v2.0/cloud/reference/git-integration.md
new file mode 100644
index 00000000000..a3839f6e903
--- /dev/null
+++ b/guides/v2.0/cloud/reference/git-integration.md
@@ -0,0 +1,28 @@
+---
+layout: default
+group: cloud
+subgroup: 15_reference
+title: How Cloud Uses Composer
+menu_title: How Cloud Uses Composer
+menu_node:
+menu_order: 48
+version: 2.0
+github_link: cloud/reference/cloud-composer.md
+---
+### Git knowledge
+We assume you have a good working knowledge of Git. If not, consult the following resources:
+
+* [Git documentation](https://git-scm.com/documentation){:target="_blank"}
+* [Git reference](https://git-scm.com/docs){:target="_blank"}
+* [Git tutorial](http://git-scm.com/docs/gittutorial){:target="_blank"}
+
+Before getting started, make sure you have a Git client installed on your computer
+to be able to interact with Magento Enterprise Cloud Edition.
+
+
+
In addition to Git's requirements for valid branch names, Magento Enterprise Cloud Edition adds two additional requirements:
+
The / character isn't allowed.
+
Branch names must be case-insensitively unique. In other words, if you have a branch named _CaSe_, you cannot create another branch named _case_.
+
+
+You must use Secure Shell (SSH) and not HTTPS to connect to the Git repository. For more information, see GitHub documentation.
diff --git a/guides/v2.0/cloud/release-notes/CloudReleaseNotes.md b/guides/v2.0/cloud/release-notes/CloudReleaseNotes.md
index e8a2172ff32..0ac22d4b450 100644
--- a/guides/v2.0/cloud/release-notes/CloudReleaseNotes.md
+++ b/guides/v2.0/cloud/release-notes/CloudReleaseNotes.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 03_ReleaseNotes
+subgroup: 030_ReleaseNotes
title: Magento Enterprise Cloud Edition Release Notes
menu_title: Magento Enterprise Cloud Edition Release Notes
menu_order: 1
diff --git a/guides/v2.0/cloud/release-notes/CloudReleaseNotes101.4.md b/guides/v2.0/cloud/release-notes/CloudReleaseNotes101.4.md
index 1131f9e826c..224e8dd9849 100644
--- a/guides/v2.0/cloud/release-notes/CloudReleaseNotes101.4.md
+++ b/guides/v2.0/cloud/release-notes/CloudReleaseNotes101.4.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 03_ReleaseNotes
+subgroup: 030_ReleaseNotes
title: magento-cloud-configuration release 101.4.1 Release Notes
menu_title: magento-cloud-configuration release 101.4.1 Release Notes
menu_order: 47
diff --git a/guides/v2.0/cloud/release-notes/CloudReleaseNotes2.1.2.md b/guides/v2.0/cloud/release-notes/CloudReleaseNotes2.1.2.md
index f998d5684f0..56df52c5fde 100644
--- a/guides/v2.0/cloud/release-notes/CloudReleaseNotes2.1.2.md
+++ b/guides/v2.0/cloud/release-notes/CloudReleaseNotes2.1.2.md
@@ -1,7 +1,7 @@
----
+/---
layout: default
group: cloud
-subgroup: 03_ReleaseNotes
+subgroup: 030_ReleaseNotes
title: Magento Enterprise Cloud Edition 2.1.2 and 2.0.10 Release Notes
menu_title: Magento Enterprise Cloud Edition 2.1.2 and 2.0.10 Release Notes
menu_order: 99
@@ -43,9 +43,9 @@ This is a known issue with Magento core software; we're actively working to addr
3. Follow the prompts to open an issue with Support.
-
This issue affects staging and production environments only. There are no issues in an integration environment. For a discussion of these terms, see Architecture.
+
This issue affects staging and production environments only. There are no issues in an integration environment. For a discussion of these terms, see Architecture.
### Magento EE Release Notes
* [Magento EE 2.0.10 Release Notes]({{ site.gdeurl }}release-notes/ReleaseNotes2.0.10EE.html)
-* [Magento EE 2.1.2 Release Notes]({{ site.gdeurl21 }}release-notes/ReleaseNotes2.1.2EE.html)
\ No newline at end of file
+* [Magento EE 2.1.2 Release Notes]({{ site.gdeurl21 }}release-notes/ReleaseNotes2.1.2EE.html)
diff --git a/guides/v2.0/cloud/release-notes/CloudReleaseNotes2.1.3.md b/guides/v2.0/cloud/release-notes/CloudReleaseNotes2.1.3.md
index 0484c2386bc..42c06975bfb 100644
--- a/guides/v2.0/cloud/release-notes/CloudReleaseNotes2.1.3.md
+++ b/guides/v2.0/cloud/release-notes/CloudReleaseNotes2.1.3.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 03_ReleaseNotes
+subgroup: 030_ReleaseNotes
title: Magento Enterprise Cloud Edition 2.1.3 and 2.0.11 Release Notes
menu_title: Magento Enterprise Cloud Edition 2.1.3 and 2.0.11 Release Notes
menu_order: 50
@@ -14,7 +14,7 @@ These Release Notes provide up-to-date information about changes, additions, and
## Required update to `.magento.app.yaml`
-Before you [upgrade]({{ page.baseurl }}cloud/howtos/upgrade-magento.html) to version 2.1.3 or 2.0.11, you must add a rule to the `web` section of your `.magento.app.yaml` file. You must make the change in your local system, push it to your [integration server]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-int), then, after upgrading, push the changes to [staging]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-stage) and [production]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-prod).
+Before you [upgrade]({{ page.baseurl }}cloud/howtos/upgrade-magento.html) to version 2.1.3 or 2.0.11, you must add a rule to the `web` section of your `.magento.app.yaml` file. You must make the change in your local system, push it to your [integration server]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-int), then, after upgrading, push the changes to [staging]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-stage) and [production]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-prod).
### Get started
@@ -54,13 +54,20 @@ Before you [upgrade]({{ page.baseurl }}cloud/howtos/upgrade-magento.html) to ver
{% endcollapsible %}
## Update your Elasticsearch configuration {#cloud-rn-213-es}
-This section discusses how to update your [integration]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-int) system to replace Solr with Elasticsearch. Currently, all Magento Enterprise Cloud Edition upgrades to 2.1.3 must perform these tasks.
+This section discusses how to update your [integration]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-int) system to replace Solr with Elasticsearch. Currently, all Magento Enterprise Cloud Edition upgrades to 2.1.3 must perform these tasks.
Elasticsearch is supported by Magento Cloud Enterprise Edition 2.1.x only.
If you installed Magento Enterprise Cloud Edition 2.1.3 for the first time, you don't need to do this because Elasticsearch is already the default search engine.
-To use Elasticsearch on a [staging]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-stage) or [production]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-prod) system, open a [Support ticket]({{ page.baseurl }}cloud/get-help.html) and request Elasticsearch.
+To use Elasticsearch on a [staging]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-stage) or [production]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-prod) system, open a [Support ticket]({{ page.baseurl }}cloud/welcome/get-help.html) and request Elasticsearch.
+
+
+After installing Elasticsearch, you must do a full index of your fulltext index.
+This process can take a while if the index is large.
+
+The search functionality will be unavailable until the process completes.
+
To use Elasticsearch, you must perform all the tasks discussed in this section.
@@ -176,11 +183,7 @@ This section discusses how to get connection information for Elasticsearch so yo
### Step 5: Configure the Magento application to use Elasticsearch
-{% collapsible To configure the Magento application: %}
-
-{% include config/es-elasticsearch-magento.md %}
-
-{% endcollapsible %}
+Configure Magento using the instructions in the [Magento configuration for Elasticsearch]({{page.baseurl}}config-guide/elasticsearch/configure-magento.html) guide.
## Fixed issue
@@ -190,4 +193,4 @@ The `magento setup:install` command (used for deployment) succeeds in either a s
### Magento EE Release Notes
* [Magento EE 2.0.11 Release Notes]({{ site.gdeurl }}release-notes/ReleaseNotes2.0.11EE.html)
-* [Magento EE 2.1.3 Release Notes]({{ site.gdeurl21 }}release-notes/ReleaseNotes2.1.3EE.html)
\ No newline at end of file
+* [Magento EE 2.1.3 Release Notes]({{ site.gdeurl21 }}release-notes/ReleaseNotes2.1.3EE.html)
diff --git a/guides/v2.0/cloud/release-notes/CloudReleaseNotes2.1.4.md b/guides/v2.0/cloud/release-notes/CloudReleaseNotes2.1.4.md
index e25d5533a26..a7c7aba8550 100644
--- a/guides/v2.0/cloud/release-notes/CloudReleaseNotes2.1.4.md
+++ b/guides/v2.0/cloud/release-notes/CloudReleaseNotes2.1.4.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 03_ReleaseNotes
+subgroup: 030_ReleaseNotes
title: Magento Enterprise Cloud Edition 2.1.4 and 2.0.12 Release Notes
menu_title: Magento Enterprise Cloud Edition 2.1.4 and 2.0.12 Release Notes
menu_order: 49
@@ -17,7 +17,7 @@ These Release Notes provide up-to-date information about changes, additions, and
Removed the MDVA-913 patch because the issue is now fixed in Magento Enterprise Edition 2.1.4.
## Fixes in this release
-* When you disable a module and deploy it to the remote Cloud server, the module stays disabled.
+* When you disable a {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} and deploy it to the remote Cloud server, the module stays disabled.
* You can now successfully upgrade from Magento Enterprise Cloud Edition 2.0.x to 2.1.x.
### Magento EE Release Notes
diff --git a/guides/v2.0/cloud/release-notes/CloudReleaseNotes2.1.5.md b/guides/v2.0/cloud/release-notes/CloudReleaseNotes2.1.5.md
index 3fb88856bb1..8c3a17c5400 100644
--- a/guides/v2.0/cloud/release-notes/CloudReleaseNotes2.1.5.md
+++ b/guides/v2.0/cloud/release-notes/CloudReleaseNotes2.1.5.md
@@ -1,7 +1,7 @@
---
layout: default
group:
-subgroup: 03_ReleaseNotes
+subgroup: 030_ReleaseNotes
title: Magento Enterprise Cloud Edition 2.1.5 and 2.0.13 Release Notes
menu_title: Magento Enterprise Cloud Edition 2.1.5 and 2.0.13 Release Notes
menu_order: 48
diff --git a/guides/v2.0/cloud/cloud-requirements-git.md b/guides/v2.0/cloud/requirements/cloud-requirements-git.md
similarity index 90%
rename from guides/v2.0/cloud/cloud-requirements-git.md
rename to guides/v2.0/cloud/requirements/cloud-requirements-git.md
index c55922c0e86..5694577f49c 100644
--- a/guides/v2.0/cloud/cloud-requirements-git.md
+++ b/guides/v2.0/cloud/requirements/cloud-requirements-git.md
@@ -1,19 +1,19 @@
---
layout: default
group: cloud
-subgroup: 02_requirements
+subgroup: 020_requirements
title: Git requirements
menu_title: Git requirements
menu_order: 3
-menu_node:
+menu_node:
version: 2.0
-github_link: cloud/cloud-requirements-git.md
+github_link: cloud/requirements/cloud-requirements-git.md
---
This page lists detailed requirements for using Git with Magento Enterprise Cloud Edition.
### Source control with Git {#cloud-require-git}
-Any change you make to your Magento Enterprise Cloud Edition project must be committed to a Git repository. You can use either the repository provided with your account or you can use your own private account on GitHub. For more information, see [Magento Enterprise Cloud Edition repositories]({{page.baseurl}}cloud/before/before-repos.html).
+Any change you make to your Magento Enterprise Cloud Edition project must be committed to a Git repository. You can use either the repository provided with your account or you can use your own private account on GitHub.
If you don't already have an account, we'll create one for you. However, if you have a GitHub account and you're already using it in a development workflow, we recommend you use it.
diff --git a/guides/v2.0/cloud/cloud-requirements-license.md b/guides/v2.0/cloud/requirements/cloud-requirements-license.md
similarity index 96%
rename from guides/v2.0/cloud/cloud-requirements-license.md
rename to guides/v2.0/cloud/requirements/cloud-requirements-license.md
index 4626e90d8c2..6d4a7a62a03 100644
--- a/guides/v2.0/cloud/cloud-requirements-license.md
+++ b/guides/v2.0/cloud/requirements/cloud-requirements-license.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 02_requirements
+subgroup: 020_requirements
title: License and authentication requirements
menu_title: License and authentication requirements
menu_order: 2
diff --git a/guides/v2.0/cloud/cloud-requirements.md b/guides/v2.0/cloud/requirements/cloud-requirements.md
similarity index 81%
rename from guides/v2.0/cloud/cloud-requirements.md
rename to guides/v2.0/cloud/requirements/cloud-requirements.md
index 0256f91388f..713d980cf34 100644
--- a/guides/v2.0/cloud/cloud-requirements.md
+++ b/guides/v2.0/cloud/requirements/cloud-requirements.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 02_requirements
+subgroup: 020_requirements
title: Magento Enterprise Cloud Edition requirements
menu_title: Magento Enterprise Cloud Edition requirements
menu_order: 1
@@ -20,8 +20,8 @@ Following are requirements you should already have:
* Must know how to use [Composer](https://getcomposer.org/doc){:target="_blank"}
* Must be familiar with Magento 2
* Must have familiarity with [Continuous Integration Best Practices](https://www.google.com/search?q=Continuous+Integration+Best+Practices){:target="_blank"}
-* Understand the three types of systems and how they’re used: [integration]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-int), [staging]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-stage), [production]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-prod)
-* Must set up a [local development environment]({{ page.baseurl }}cloud/before/before-setup-env-1_get-started.html)
+* Understand the three types of systems and how they’re used: [integration]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-int), [staging]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-stage), [production]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-prod)
+* Must set up a [local development environment]({{ page.baseurl }}cloud/before/before-setup-env-1_get-start.html)
The integration environment (sometimes referred to as _Platform as a Service (PaaS))_ can help with integration testing but is not for developing for a production server. Among the differences are that, in integration, Magento is set for developer mode and not all directories are read-only.
* Must have working [`repo.magento.com` credentials]({{ page.baseurl }}install-gde/prereq/connect-auth.html) in your account
@@ -36,10 +36,10 @@ Before you test any custom code in your local Magento Enterprise Cloud Edition e
* Must test with the correct file permissions in production mode
Correct permissions include no write access outside of `var`, `pub/static, pub/media`, and `app/etc`
-* Test with minification for HTML, JavaScript, and CSS enabled
+* Test with minification for HTML, JavaScript, and {% glossarytooltip 6c5cb4e9-9197-46f2-ba79-6147d9bfe66d %}CSS{% endglossarytooltip %} enabled
* Test with [Redis enabled for page cache and session cache]({{ page.baseurl }}config-guide/redis/config-redis.html)
-* Install the [Fastly]({{ page.baseurl }}cloud/access-acct/fastly.html) extension
-* Test using [Varnish]({{ page.baseurl }}config-guide/varnish/config-varnish.html) for the page cache
+* Install the [Fastly]({{ page.baseurl }}cloud/access-acct/fastly.html) {% glossarytooltip 55774db9-bf9d-40f3-83db-b10cc5ae3b68 %}extension{% endglossarytooltip %}
+* Test using [Varnish]({{ page.baseurl }}config-guide/varnish/config-varnish.html) for the page {% glossarytooltip 0bc9c8bc-de1a-4a06-9c99-a89a29c30645 %}cache{% endglossarytooltip %}
### Development and testing {#cloud-req-devtest}
For development and testing, we require the following:
@@ -63,7 +63,7 @@ Before you go live, you must:
* Review [our documentation]({{ page.baseurl }}cloud/live/live.html) about going live
* Schedule the Go Live Preparation call with the support team
* Adjust DNS TTL in advance
-* Change the default Magento Admin password
+* Change the default {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %} password
* Optimize all images for the web
* Enable minification for JS, CSS, and HTTP
* Make sure that pages are being correctly cached in the page cache and Fastly
@@ -73,7 +73,7 @@ Before you go live, you must:
* Make sure that the Fastly SSL certificate is setup for your domain(s)
#### Related topics
-* [Git requirements]({{ page.baseurl }}cloud/cloud-requirements-git.html)
-* [License and authentication requirements]({{ page.baseurl }}cloud/cloud-requirements-license.html)
+* [Git requirements]({{ page.baseurl }}cloud/requirements/cloud-requirements-git.html)
+* [License and authentication requirements]({{ page.baseurl }}cloud/requirements/cloud-requirements-license.html)
diff --git a/guides/v2.0/cloud/trouble/environments-logs.md b/guides/v2.0/cloud/trouble/environments-logs.md
index ca181cbda85..74f01aedabe 100644
--- a/guides/v2.0/cloud/trouble/environments-logs.md
+++ b/guides/v2.0/cloud/trouble/environments-logs.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 50_trouble
+subgroup: 170_trouble
title: Use logs for troubleshooting
menu_title: Use logs for troubleshooting
menu_order: 2
@@ -10,7 +10,7 @@ version: 2.0
github_link: cloud/trouble/environments-logs.md
---
-This topic discusses how you can use logs to troubleshoot problems related to Magento Enterprise Cloud Edition [build hooks]({{page.baseurl}}cloud/discover-deploy.html#cloud-deploy-over-phases-build) and [deploy hooks]({{page.baseurl}}cloud/discover-deploy.html#cloud-deploy-over-phases-hook).
+This topic discusses how you can use logs to troubleshoot problems related to Magento Enterprise Cloud Edition [build hooks]({{page.baseurl}}cloud/reference/discover-deploy.html#cloud-deploy-over-phases-build) and [deploy hooks]({{page.baseurl}}cloud/reference/discover-deploy.html#cloud-deploy-over-phases-hook).
## Build logs
After pushing to your environment, you can see the results of the both hooks. Logs from the build hook are redirected to the output stream of `git push`, so you can observe them in the terminal or capture them (along with error messages) with
@@ -19,8 +19,8 @@ After pushing to your environment, you can see the results of the both hooks. Lo
## Deploy logs {#log-deploy-log}
Logs from the deploy hook are located on the server in the following locations:
-* [Integration system]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-int): `/tmp/log/deploy.log`
-* [Staging]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-stage) or [production]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-prod) systems: `/var/log/platform//post_deploy.log`
+* [Integration system]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-int): `/tmp/log/deploy.log`
+* [Staging]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-stage) or [production]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-prod) systems: `/var/log/platform//post_deploy.log`
The value of `` depends on the project ID and whether the environment is staging or production. For example, with a project ID of `yw1unoukjcawe`, the staging environment user is `yw1unoukjcawe_stg` and the production environment user is `yw1unoukjcawe`.
@@ -45,4 +45,4 @@ The actual log output is highly verbose to allow troubleshooting. Following is a
{% endhighlight %}
The deploy log contains start and stop messages for each of the two hooks:
-`Starting pre-deploy`, `Pre-deploy complete.`, `Start deploy.`, and `Deployment complete.`.
\ No newline at end of file
+`Starting pre-deploy`, `Pre-deploy complete.`, `Start deploy.`, and `Deployment complete.`.
diff --git a/guides/v2.0/cloud/trouble/trouble.md b/guides/v2.0/cloud/trouble/trouble.md
index 1da40f8f58c..5b4d6a74368 100644
--- a/guides/v2.0/cloud/trouble/trouble.md
+++ b/guides/v2.0/cloud/trouble/trouble.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 50_trouble
+subgroup: 170_trouble
title: Troubleshooting
menu_title: Troubleshooting
menu_order: 1
diff --git a/guides/v2.0/cloud/trouble/trouble_ce-creds.md b/guides/v2.0/cloud/trouble/trouble_ce-creds.md
index b18b70424df..6c9e33d1a3a 100644
--- a/guides/v2.0/cloud/trouble/trouble_ce-creds.md
+++ b/guides/v2.0/cloud/trouble/trouble_ce-creds.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 50_trouble
+subgroup: 170_trouble
title: Incorrect credentials
menu_title: Incorrect credentials
menu_order: 5
diff --git a/guides/v2.0/cloud/trouble/trouble_comp-deploy-fail.md b/guides/v2.0/cloud/trouble/trouble_comp-deploy-fail.md
index 465d4a3cad7..20f5fae57ec 100644
--- a/guides/v2.0/cloud/trouble/trouble_comp-deploy-fail.md
+++ b/guides/v2.0/cloud/trouble/trouble_comp-deploy-fail.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 50_trouble
+subgroup: 170_trouble
title: Component deployment failure
menu_title: Component deployment failure
menu_order: 50
@@ -10,7 +10,7 @@ version: 2.0
github_link: cloud/trouble/trouble_comp-deploy-fail.md
---
-This topic discusses how to recover from a failed component deployment. Typical examples are components that have dependencies that are not met by your environment; for example, incompatible PHP versions.
+This topic discusses how to recover from a failed component deployment. Typical examples are components that have dependencies that are not met by your environment; for example, incompatible {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} versions.
You can recover from a failed deployment in any of the following ways:
diff --git a/guides/v2.0/cloud/trouble/trouble_fastly.md b/guides/v2.0/cloud/trouble/trouble_fastly.md
index 44f547c4fe1..0ddf0b81821 100644
--- a/guides/v2.0/cloud/trouble/trouble_fastly.md
+++ b/guides/v2.0/cloud/trouble/trouble_fastly.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 50_trouble
+subgroup: 170_trouble
title: Troubleshoot Fastly
menu_title: Troubleshoot Fastly
menu_order: 20
@@ -11,7 +11,7 @@ github_link: cloud/trouble/trouble_fastly.md
---
## Overview of troubleshooting Fastly
-To verify the Fastly extension is working or to debug the Fastly extension, you can use the `curl` command to display certain response headers. The values of these response headers indicate whether or not Fastly is enabled and functioning properly.
+To verify the Fastly {% glossarytooltip 55774db9-bf9d-40f3-83db-b10cc5ae3b68 %}extension{% endglossarytooltip %} is working or to debug the Fastly extension, you can use the `curl` command to display certain response headers. The values of these response headers indicate whether or not Fastly is enabled and functioning properly.
Response headers and values:
@@ -24,14 +24,14 @@ Response headers and values:
To get values for these headers, you must run the following `curl` commands:
-* Staging or production URL (also referred to as the [*origin server*](https://www.w3.org/Protocols/rfc2616/rfc2616-sec1.html#sec1.3){:target="_blank"})
+* Staging or production {% glossarytooltip a05c59d3-77b9-47d0-92a1-2cbffe3f8622 %}URL{% endglossarytooltip %} (also referred to as the [*origin server*](https://www.w3.org/Protocols/rfc2616/rfc2616-sec1.html#sec1.3){:target="_blank"})
This command goes directly to the origin server, bypassing the Fastly extension; it returns the headers `Fastly-Module-Enabled`, `Cache-Control: max-age`, and `Pragma`
* Live site URL
This command goes through the Fastly extension and returns the `Fastly-Magento-VCL-Uploaded` and `X-Cache` headers
-You should perform the test on your [staging]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-stage) or [production]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-prod) site. The Fastly extension isn't necessary on your [integration]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-int) site, so there's no point in testing it there.
+You should perform the test on your [staging]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-stage) or [production]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-prod) site. The Fastly extension isn't necessary on your [integration]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-int) site, so there's no point in testing it there.
## Test your staging or production site {#cloud-test-stage}
@@ -147,7 +147,7 @@ Do the following:
[Upload the Fastly VCL]({{ page.baseurl }}cloud/live/stage-prod-migrate-prereq.html#cloud-live-migrate-fastly)
### `X-Cache` includes `MISS`
-If `X-Cache` is either `HIT, MISS` or `MISS, MISS`, enter the same `curl` command again to make sure the page wasn't recently evicted from the cache.
+If `X-Cache` is either `HIT, MISS` or `MISS, MISS`, enter the same `curl` command again to make sure the page wasn't recently evicted from the {% glossarytooltip 0bc9c8bc-de1a-4a06-9c99-a89a29c30645 %}cache{% endglossarytooltip %}.
If you get the same result, use the [first `curl` command](#cloud-test-stage) discussed in this topic to verify that:
@@ -157,7 +157,7 @@ If you get the same result, use the [first `curl` command](#cloud-test-stage) di
If the issue persists, another extension is likely resetting these headers. Repeat the following procedure as many times as necessary to identify which extension is resetting the headers:
-1. Log in to the Magento Admin as an administrator.
+1. Log in to the {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %} as an administrator.
2. Click **Stores** > Settings > **Configuration** > **Advanced** > **Advanced**.
3. In the Disable Modules Output section in the right pane, locate an extension.
4. From the list next to the extension name, click **Disable**.
diff --git a/guides/v2.0/cloud/trouble/trouble_proj-startover.md b/guides/v2.0/cloud/trouble/trouble_proj-startover.md
index e932975d28a..cf9e64a843a 100644
--- a/guides/v2.0/cloud/trouble/trouble_proj-startover.md
+++ b/guides/v2.0/cloud/trouble/trouble_proj-startover.md
@@ -1,7 +1,7 @@
---
layout: default
group: cloud
-subgroup: 50_trouble
+subgroup: 170_trouble
title: Resolve issues with a new project
menu_title: Resolve issues with a new project
menu_order: 2
diff --git a/guides/v2.0/cloud/welcome/10000-ft-overview.md b/guides/v2.0/cloud/welcome/10000-ft-overview.md
new file mode 100644
index 00000000000..3281ed8d4b7
--- /dev/null
+++ b/guides/v2.0/cloud/welcome/10000-ft-overview.md
@@ -0,0 +1,81 @@
+---
+layout: default
+group: cloud
+subgroup: 010_welcome
+title: The 10,000 ft overview
+menu_title: 10,000 ft overview
+menu_order: 20
+menu_node:
+version: 2.0
+github_link: cloud/welcome/10000-ft-overview.md
+---
+
+## What's this?
+
+The goal of this page is to give you a high-level map of the cloud offering: what are the moving parts, how do they work, and what are your modes of interacting with them. On other pages, you'll find more in-depth discussion into specifics: right now, we just want to get you oriented.
+
+## What should I know about before reading this article? Or using ECE?
+
+* Git
+* {% glossarytooltip d85e2d0a-221f-4d03-aa43-0cda9f50809e %}Composer{% endglossarytooltip %}
+* SSH
+* MySQL (including command-line interation)
+* Basic linux shell usage
+
+## What kinds of ECE are there?
+
+When you sign up for ECE you will get access to two kinds of environments: one is termed the "integration environment" and the other is the "enterprise environment". Your staging and production servers will be enterprise environments, while you can have up to six different integration environments. The integration environments are designed for experimentation and user acceptance testing - they are lightweight servers that are easy to manage by `magento-cloud`, [a custom command-line tool]({{page.baseurl}}cloud/before/before-workspace-cli.html), as well as a web-based GUI. The enterprise environments are heavy-duty but can only be managed directly through the regular command-line tools like `git` and `ssh` -- not the `magento-cloud` tool.
+
+## What are the moving parts?
+
+### Git repo
+
+Enterprise Cloud Edition is a solution for hosting your Magento code on the Cloud. The source code for your site is stored in a private git repository, and that's how you make changes to your site's codebase. When you push commits to this repository, a set of hooks get called that handle deployment activities.
+
+On your integration environment, there is just one repository: every branch of that repository corresponds to an actual running container for a Magento instance based on the codebase in that branch. The name of the branch matches the name of the environment.
+
+For your two enterprise environments, staging and production, you have one repository each and the `master` branch corresponds to the running environment: that is, every node of the VM cluster will have the codebase contained in the `master` branch. Other branches on these repos will not correspond to running environments.
+
+### Where does the code first come from?
+
+You can start off with ECE in two ways - start your project based on a code template and make new commits on top of that with whatever changes you need, or import your existing project (as long as it is structured properly -- more on that below). Either way involves basic `git` operations to pull code from _some_ remote repository into your dedicated ECE repository.
+
+#### Pull from template
+
+We keep a template of an ECE project [on github](https://github.com/magento/magento-cloud/). This template contains the latest version of Magento, retrieved via composer. Since the official way to download Magento for use in actual websites is to download the code with composer, the template comes with a ready-made `composer.json` file and up-to-date `composer.lock` file, and these establish the dependencies to download the Magento source code as well as a few other packages that are required for ECE specifically.
+
+When your project is created for the first time you will have the option to create it from a template, and choosing this option will pull from our template repo into your branch.
+
+#### Import your own project
+
+You can at any time import your existing codebase using git. [See the project import article]({{page.baseurl}}cloud/access-acct/first-time-setup_import-import.html) for information on importing your existing codebase, and how to make sure it's well-structured.
+
+### What about Composer?
+
+You can add dependencies on Magento extensions and other {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} libraries using composer. You must also depend on a package called `magento/magento-cloud-metapackage` in order to download both the Magento codebase and also other packages that are specific to ECE (like deployment scripts).
+
+### How do things get deployed?
+
+When you push to the git repository for your project, the environment will get deployed or re-deployed to accomodate the new changes. For instance, say you added a new module: in order for the site to work, `bin/magento setup:upgrade` will need to be run. Or, if this is the first deployment, then `bin/magento setup:install` will need to be run. There are several other commands that go into the deployment flow, but _you don't need to run them manually_, because the build and deploy hooks will take care of that automatically. For more information about the composer packages that contain those hooks, see [this article on Composer Integration]({{page.baseurl}}cloud/reference/cloud-composer.html).
+
+#### Default hooks
+
+There are two kinds of hooks that run at different points in time: `build` and `deploy` hooks.
+
+`build` hooks run while the raw codebase is being formed: there is no access to a database or a redis {% glossarytooltip 0bc9c8bc-de1a-4a06-9c99-a89a29c30645 %}cache{% endglossarytooltip %} while these hooks run. These hooks run on a machine that is separate from your webserver: once the codebase is prepared by running all of the build hooks, the entire folder gets copied onto the machine that your site is served from, in read-only form.
+
+`deploy` hooks run after the read-only code slug is prepared, and this hook runs on the actual machine where the {% glossarytooltip b14ef3d8-51fd-48fe-94df-ed069afb2cdc %}nginx{% endglossarytooltip %} web server will serve your site. These hooks can access the database, redis, etc., and so are used for making non-code-related changes to the application.
+
+The default hooks are as follows:
+
+ * `php bin/magento magento-cloud:build` - this is a build hook. It handles applying any patches you might have provided
+ * `php vendor/magento/magento-cloud-configuration/pre-deploy.php` - this is a deploy hook that clears the cache and marshals files around to enable the next deploy hook, which depends on Magento's console frmaework, to be able to run correctly.
+ * `php bin/magento magento-cloud:deploy` - this deploy hook installs or updates the application, and updates config values whenever they change (such as DB connection details).
+
+#### Adding more hooks
+
+Above are the three hooks that run by default, but you can add your own. In integration environments, you can declaratively change them by editing `.magento.app.yaml` in the project root and committing the change to git. Just add the command you want to run to `hooks->build` or `hooks->deploy`. For the enterprise environment, submit a support ticket describing the command you want to run as the hook, and whether it is for the build or deploy hook phase.
+
+### How do I SSH into the environment?
+
+[Here is the SSH guide.]({{page.baseurl}}cloud/env/environments-ssh.html).
diff --git a/guides/v2.0/cloud/discover-workflow.md b/guides/v2.0/cloud/welcome/discover-workflow.md
similarity index 80%
rename from guides/v2.0/cloud/discover-workflow.md
rename to guides/v2.0/cloud/welcome/discover-workflow.md
index bcb0097ec74..ee5221a339b 100644
--- a/guides/v2.0/cloud/discover-workflow.md
+++ b/guides/v2.0/cloud/welcome/discover-workflow.md
@@ -1,10 +1,10 @@
---
layout: default
group: cloud
-subgroup: 01_welcome
+subgroup: 010_welcome
title: Workflow
menu_title: Workflow
-menu_order: 3
+menu_order: 30
menu_node:
version: 2.0
github_link: cloud/discover-workflow.md
@@ -22,7 +22,7 @@ The following figure shows how it works at a high level.
-You get Magento code from our repository, create a [_project_]({{ page.baseurl }}cloud/project/projects.html) which is based in Git, then do your customization in an [integration system]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-int). You can use the Magento Cloud command line to configure your project and use an [automated deployment process]({{ page.baseurl }}cloud/discover-deploy.html) to push code from integration to [staging]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-stage) and finally to [production]({{ page.baseurl }}cloud/discover-arch.html#cloud-arch-prod).
+You get Magento code from our repository, create a [_project_]({{ page.baseurl }}cloud/project/projects.html) which is based in Git, then do your customization in an [integration system]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-int). You can use the Magento Cloud command line to configure your project and use an [automated deployment process]({{ page.baseurl }}cloud/reference/discover-deploy.html) to push code from integration to [staging]({{ page.baseurl }}cloud/reference/discover-arch.html#cloud-arch-stage) and finally to [production]({{ page.baseurl }}cloud/reference/iscover-arch.html#cloud-arch-prod).
### Use any methodology
You can use any methodology you already have or you can invent new ones. For example, you can use a Development -> Staging -> Production workflow.
diff --git a/guides/v2.0/cloud/get-help.md b/guides/v2.0/cloud/welcome/get-help.md
similarity index 92%
rename from guides/v2.0/cloud/get-help.md
rename to guides/v2.0/cloud/welcome/get-help.md
index 12d489555f3..19f32ed0499 100644
--- a/guides/v2.0/cloud/get-help.md
+++ b/guides/v2.0/cloud/welcome/get-help.md
@@ -1,10 +1,10 @@
---
layout: default
group: cloud
-subgroup: 01_welcome
+subgroup: 010_welcome
title: Get help with your deployment
menu_title: Get help with your deployment
-menu_order: 50
+menu_order: 40
menu_node:
version: 2.0
github_link: cloud/get-help.md
diff --git a/guides/v2.0/coding-standards/bk-coding-standards.md b/guides/v2.0/coding-standards/bk-coding-standards.md
index 526acc5b392..eb261fe6425 100644
--- a/guides/v2.0/coding-standards/bk-coding-standards.md
+++ b/guides/v2.0/coding-standards/bk-coding-standards.md
@@ -11,7 +11,7 @@ version: 2.0
github_link: coding-standards/bk-coding-standards.md
redirect_from: /guides/v1.0/coding-standards/bk-coding-standards.html
---
-
+
diff --git a/guides/v2.0/coding-standards/code-standard-demarcation.md b/guides/v2.0/coding-standards/code-standard-demarcation.md
index f6fd336511e..d4bcf92c2a1 100644
--- a/guides/v2.0/coding-standards/code-standard-demarcation.md
+++ b/guides/v2.0/coding-standards/code-standard-demarcation.md
@@ -12,14 +12,14 @@ redirect_from: /guides/v1.0/coding-standards/code-standard-demarcation.html
---
Magento core developers must follow the Magento code demarcation standard.
-
This standard is recommended for third-party extension developers.
+
This standard is recommended for third-party {% glossarytooltip 55774db9-bf9d-40f3-83db-b10cc5ae3b68 %}extension{% endglossarytooltip %} developers.
Some parts of Magento code might not comply with the standard, but we are working to gradually improve this.
The standard was developed in the scope of our efforts to ensure the following:
Decouple visual (CSS) layer from the functional (JavaScript) layer.
-
Decouple functional (JavaScript) layer from the markup (HTML).
-
Reinstate emphasis on using of jQuery templates.
-
Reinstate emphasis on decoupling HTML, CSS and JS from PHP classes.
+
Decouple functional (JavaScript) layer from the {% glossarytooltip 8f407f13-4350-449b-9dc5-217dcf01bc42 %}markup{% endglossarytooltip %} (HTML).
+
Reinstate emphasis on using of {% glossarytooltip 5bfa8a8e-6f3e-4fed-a43e-62339916f02e %}jQuery{% endglossarytooltip %} templates.
+
Reinstate emphasis on decoupling HTML, {% glossarytooltip 6c5cb4e9-9197-46f2-ba79-6147d9bfe66d %}CSS{% endglossarytooltip %} and JS from {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} classes.
Use RFC 2119 to interpret the "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" keywords.
The following acceptable example is terse and uses an Accessible Rich Internet Applications (ARIA) approach.
{% highlight html %}
@@ -142,11 +142,11 @@ The following list will help you make a distinction between the actual meaning o
### Visual representation must rely only on HTML `class` attributes, CSS pseudo-classes and pseudo-elements, HTML tags, and form element's type attribute and form elements state attributes (example: `disabled`, `checked`).
-As the first option, you are required to use HTML class attributes. In case this option is not applicable then it is recommended to use HTML tags and form element's type attribute.
+As the first option, you are required to use {% glossarytooltip a2aff425-07dd-4bd6-9671-29b7edefa871 %}HTML{% endglossarytooltip %} class attributes. In case this option is not applicable then it is recommended to use HTML tags and form element's type attribute.
Enforces clean, strict separation between visual and business logic layers.
-
Allows frontend and backend teams to work independently.
+
Allows {% glossarytooltip b00459e5-a793-44dd-98d5-852ab33fc344 %}frontend{% endglossarytooltip %} and {% glossarytooltip 74d6d228-34bd-4475-a6f8-0c0f4d6d0d61 %}backend{% endglossarytooltip %} teams to work independently.
Allows changing look and feel without affecting business functionality, and vice versa.
Enables frontend teams to clean up old styles quickly and easily when refactoring.
@@ -186,7 +186,7 @@ section[role="main"] { ... }
Reduces long-term maintenance efforts by containing CSS styles in a single place.
-**Acceptable JavaScript widget file**
+**Acceptable {% glossarytooltip 312b4baf-15f7-4968-944e-c814d53de218 %}JavaScript{% endglossarytooltip %} {% glossarytooltip f0dcf847-ce21-4b88-8b45-83e1cbf08100 %}widget{% endglossarytooltip %} file**
{% highlight javascript %}
...
options: {
diff --git a/guides/v2.0/coding-standards/code-standard-html.md b/guides/v2.0/coding-standards/code-standard-html.md
index d20ce70f19f..3bf655f0e66 100644
--- a/guides/v2.0/coding-standards/code-standard-html.md
+++ b/guides/v2.0/coding-standards/code-standard-html.md
@@ -10,7 +10,7 @@ version: 2.0
github_link: coding-standards/code-standard-html.md
---
-This style guide defines Magento internal requirements for HTML code style for teams that develop LESS and CSS code. We recommend that developers who create Magento extensions and customizations also use these standards.
+This style guide defines Magento internal requirements for {% glossarytooltip a2aff425-07dd-4bd6-9671-29b7edefa871 %}HTML{% endglossarytooltip %} code style for teams that develop LESS and {% glossarytooltip 6c5cb4e9-9197-46f2-ba79-6147d9bfe66d %}CSS{% endglossarytooltip %} code. We recommend that developers who create Magento extensions and customizations also use these standards.
The guide is based on the [Google HTML/CSS Style Guide](https://google.github.io/styleguide/htmlcssguide.xml) with certain modifications that are described further.
diff --git a/guides/v2.0/coding-standards/code-standard-javascript.md b/guides/v2.0/coding-standards/code-standard-javascript.md
index 02e02afe5f5..2fe2a7cffd9 100644
--- a/guides/v2.0/coding-standards/code-standard-javascript.md
+++ b/guides/v2.0/coding-standards/code-standard-javascript.md
@@ -11,698 +11,338 @@ github_link: coding-standards/code-standard-javascript.md
redirect_from: /guides/v1.0/coding-standards/code-standard-javascript.html
---
-The JavaScript coding standard, based on the Google JavaScript Style Guide, defines Magento requirements for code formatting and style for teams that develop Magento JavaScript and jQuery code.
+Magento's JavaScript coding standard is based on the [Google JavaScript Style Guide][js-guide].
+Developers writing {% glossarytooltip 312b4baf-15f7-4968-944e-c814d53de218 %}JavaScript{% endglossarytooltip %} and {% glossarytooltip 5bfa8a8e-6f3e-4fed-a43e-62339916f02e %}jQuery{% endglossarytooltip %} code for Magento must follow this guide along with the additional, Magento-specific standards listed in this document.
-Use RFC 2119 to interpret the "must," "must not," "required," "shall," "shall not," "should," "should not," "recommended," "may," and "optional" keywords.
+Use [RFC 2119](http://www.ietf.org/rfc/rfc2119.txt) to interpret the "must," "must not," "required," "shall," "shall not," "should," "should not," "recommended," "may," and "optional" keywords.
-The Magento system uses the jQuery library including the standard and custom jQuery widgets. For the jQuery widget coding standard, see jQuery widget coding standard.
+Magento uses the [jQuery library][jquery] including standard and custom [jQuery widgets][jquery-widgets].
+For the jQuery widget coding standard, see [jQuery widget coding standard][jquery-widget-coding-standard].
-Some parts of Magento code might not comply with this coding standard.
+## JSHint tool
+Use [JSHint][jshint] to ensure the quality of your JavaScript code.
-This coding standard is recommended for third-party Magento developers.
+JSHint is a community-driven tool that detects errors and potential problems in JavaScript code.
+Its flexibility enables you to customize it to for specific coding standards and expected code execution environment.
-## JSHint tool {#fedg_js-coding_JSHint}
-Use JSHint to ensure the quality of your JavaScript code.
+## Additional formatting standards
-JSHint is a community-driven tool that detects errors and potential problems in JavaScript code. Its flexibility enables you to customize it to your coding standard and expected code execution environment. jQuery core passes JSHint.
+### Anonymous function calls
-## Formatting {#fedg_js-coding-format}
-See one of the following sections:
+When you declare an anonymous function as an argument in a function call, indent the body of the function by *four* spaces from the left edge of the statement or function {% glossarytooltip caa46cea-25d7-4e4f-bce1-11430ada59dc %}keyword{% endglossarytooltip %} to increase readability.
-* [Anonymous functions](#fedg_js-coding_codestyle_anon)
-* [End of file](#fedg_js-coding-format_eof)
-* [Function arguments](#fedg_js-coding_codestyle_funcargs)
-* [Indentation](#fedg_js-coding-format_indent)
-* [Indent wrapped lines](#fedg_js-coding_codestyle_indent)
-* [Line length](#fedg_js-coding-format_length)
-* [Line termination](#fedg_js-coding-format_terminate)
-* [Multiline string literals](#fedg_js-coding-format_multilit)
-* [Parentheses](#fedg_js-coding-format_multilit)
-* [Statements and conditions](#fedg_js-coding_codestyle_stmt)
-* [Strings](#strings)
+{% highlight javascript %}
-### Anonymous functions {#fedg_js-coding_codestyle_anon}
-When you declare an anonymous function in the list of arguments for a function call, indent the body of the function four spaces from the left edge of the statement, or four spaces from the left edge of the function keyword.
+myObject.myFunction(param1, function (a,b) {
+ //Function logic
+ return a > b;
+});
-This makes the body of the anonymous function easier to read.
+{% endhighlight%}
-
+### End of file
-### End of file {#fedg_js-coding-format_eof}
-The last line in a file also must end with a single linefeed (LF) character.
+The last line in a file must end with a single linefeed(LF) character(i.e. an empty line).
-In other words, a file always ends with an empty line. This reduces quantity of the changed lines in a diff and makes code safer in files concatenation process.
+This reduces the quantity of the changed lines in a diff and makes code safer in file concatenation processes.
-### Function arguments {#fedg_js-coding_codestyle_funcargs}
-When possible, list all function arguments on the same line.
+### Indentation
-If doing so exceeds the 120-column limit, you must line-wrap the arguments in a readable way.
+Indentation in Magento code uses four spaces.
-To save space, try to wrap as close to 80 columns as possible (remember 120-column limit), or put each argument on its own line to enhance readability.
+Tabs are not allowed as indentation.
-The indentation should be four spaces.
+#### Wrapped lines
-The following patterns are the most common patterns for argument wrapping:
+Indent wrapped lines four spaces or left-aligned to the expression above.
-
+### Max line length
-### Indentation {#fedg_js-coding-format_indent}
-Indentation should consist of four spaces.
+The recommended max line length is 80 characters.
-Tabs are not allowed.
+Source code lines must not exceed 120 characters.
-### Indent wrapped lines {#fedg_js-coding_codestyle_indent}
-You should indent all wrapped lines to be left-aligned to the expression above, or indented four spaces.
+Comment lines that contain an example command or a literal {% glossarytooltip a05c59d3-77b9-47d0-92a1-2cbffe3f8622 %}URL{% endglossarytooltip %} longer than 120 characters may exceed the 120 character limit for ease of cutting and pasting.
-
+Do not be concerned about header guards that exceed 120 characters.
-### Line length {#fedg_js-coding-format_length}
-Source code line length must not exceed 120 characters.
+### Line termination
-Recommended line length is 80 characters.
-
-
-
-
If a comment line contains an example command or a literal URL longer than 120 characters, that line can be longer than 120 characters for ease of cutting and pasting.
-
Do not be concerned about header guards that exceed 120 characters.
-
-
-
-### Line termination {#fedg_js-coding-format_terminate}
Line termination follows the UNIX text file convention.
-Lines must end with a single linefeed (LF) character.
+Lines must end with a single linefeed(LF) character represented as ordinal 10 or hexadecimal (`0x0A`).
-Linefeed characters are represented as ordinal 10, or hexadecimal (0x0A).
+*Do not* use carriage the Mac OS convention of carriage returns(CR or `0x0D`) or the carriage return-linefeed combination(CRLF or `0x0D` and `0x0A`) standard for Windows OS.
-
-
Do not use carriage returns (CR) as is the convention in Mac OS (0x0D) or the carriage return–linefeed combination (CRLF) as is standard in Windows OS (0x0D, 0x0A).
+### Multi-line string literals
-
+Use string concaternation for multi-line string literals:
-### Multiline string literals {#fedg_js-coding-format_multilit}
-Use string concatenation:
+{% highlight javascript %}
+var myString = 'JavaScript was originally developed in Netscape, by Brendan Eich. ' +
+ 'Battling with Microsoft over the Internet, Netscape considered their client-server solution ' +
+ 'as a distributed OS, running a portable version of Sun Microsystem’s Java. ' +
+ 'Because Java was a competitor of C++ and aimed at professional programmers, ' +
+ 'Netscape also wanted a lightweight interpreted language that would complement Java ' +
+ 'by appealing to nonprofessional programmers, like Microsoft’s VB.[9] (see JavaScript and Java)';
+{% endhighlight %}
- var myString = 'JavaScript was originally developed in Netscape, by Brendan Eich. ' +
- 'Battling with Microsoft over the Internet, Netscape considered their client-server solution ' +
- 'as a distributed OS, running a portable version of Sun Microsystem’s Java. ' +
- 'Because Java was a competitor of C++ and aimed at professional programmers, ' +
- 'Netscape also wanted a lightweight interpreted language that would complement Java ' +
- 'by appealing to nonprofessional programmers, like Microsoft’s VB.[9] (see JavaScript and Java)';
+### Parentheses
-### Parentheses {#fedg_js-coding_codestyle_parens}
-Use sparingly and in general only where required by the syntax and semantics.
+Use sparingly and in general where required by the syntax and semantics.
Never use parentheses for:
-* Unary operators such as `delete`, `typeof`, and `void`
+* Unary operators (e.g. `delete`, `typeof`, and `void`)
* After keywords such as `return`, `throw`
-* For `case`, `in`, or `new`, and others like them
-
-### Semicolons {#semicolons}
-Always put semicolons as statement terminators.
-The following example shows how missing semicolons can be particularly dangerous:
-
- // 1.
- MyClass.prototype.myMethod = function() {
- return 42;
- } // No semicolon here.
-
- (function() {
- // Some initialization code wrapped in a function to create a scope for locals.
- })();
-
- // 2. Trying to do one thing on Internet Explorer and another on Firefox.
- var x = {
- 'i': 1,
- 'j': 2
- } // No semicolon here.
-
- // I know you'd never write code like this, but throw me a bone.
- [normalVersion, ffVersion][isIE]();
-
- // 3. conditional execution a la bash
- var THINGS_TO_EAT = [apples, oysters, sprayOnCheese] // No semicolon here.
+* For `case`, `in`, or `new`, and others keywords like them
- -1 == resultOfOperation() || die();
+### Statements and conditions
-**So what happens?**
-
-1. JavaScript error—first the function returning 42 is called with the second function as a parameter, then the number 42 is "called" resulting in an error.
-2. The 'no such property in undefined' error is likely to appear at runtime as it tries to call `x[ffVersion][isIE]()`.
-3. `die` is called unless `resultOfOperation()` is `NaN` and `THINGS_TO_EAT` gets assigned the result of `die()`.
-
-**Why?**
-JavaScript requires statements to end with a semicolon, except when it thinks it can safely infer their existence.
-
-In each of the examples above, a function declaration, or an object, or an array literal is used inside a statement.
-
-The closing brackets are not enough to indicate the end of the statement. JavaScript never ends a statement if the next token is an infix or bracket operator.
-
-
Statements and conditions
Do not put statements on the same line as conditions.
-**Incorrect:**
-
- if (true) return;
- if (true) blah();
-
-**Correct:**
-
- if (true) {
- return;
- }
-
- if (true) {
- blah();
- }
-
-### Strings {#strings}
-For consistency, single-quotes are preferred to double quotes. This is helpful when creating strings that include HTML:
-
- var msg = '<span class="text">Hello World!</div>';
-
-## Naming conventions {#fedg_js-coding_naming}
-See one of the following sections:
-
-* Constants
-* File names
-
-
-### Constants {#fedg_js-coding_naming_const}
-Constants may contain both alphanumeric characters and underscores (`_`).
-
-All letters used in a constant name must be capitalized, while all words in a constant name must be separated by an underscore.
-
-For example, `EMBED_SUPPRESS_EMBED_EXCEPTION` is an acceptable name, but `EMBED_SUPPRESSEMBEDEXCEPTION` is not.
-
-Constants must be defined as class members with the `const` modifier.
-
-In JavaScript constants are declared using the `@const` annotation. But Internet Explorer does not parse the `@const` keyword, so omit it, if possible.
-
-For example, variables can be used instead of constants for storing simple values. Applying the naming convention used for constants (ALL CAPS) in naming these variables would indicate that their value is not supposed to be changed.
-
-Example:
-
- /**
- * The number of seconds in a minute.
- * @type {number}
- */
- obj.example.SECONDS_IN_A_MINUTE = 60;
-
-For non-primitives, use the `@const` annotation.
+{% highlight javascript %}
+// Incorrect
+if (true) return;
+if (true) blah();
- /**
- * The number of seconds in each of the given units.
- * @type {Object.<number>}
- * @const
- */
- obj.example.SECONDS_TABLE = {
- minute: 60,
- hour: 60 * 60
- day: 60 * 60 * 24
+// Correct
+if (true) {
+ return;
+}
-### File names {#fedg_js-coding_naming_files}
-File names should be all lowercase to avoid confusion on case-sensitive platforms.
+if (true) {
+ blah();
+}
+{% endhighlight %}
-File names should contain only alphanumeric characters, and dash character (`-`) as words separator, end with `.js`:
+### Semicolons
+Always put semicolons as statement terminators.
-* **Correct**: `dialog-popup-base-features.js`
-* **Incorrect**: `dialog_popup_base_features.js`
+The following code examples show the dangers of missing semicolons:
-## Code style {#fedg_js-coding_codestyle}
-See one of the following sections:
+{% highlight javascript %}
+// Example 1: JavaScript Error
+MyClass.prototype.myMethod = function() {
+ return 42;
+} // <-- Missing semicolon
-* [Curly braces](#fedg_js-coding_codestyle_curl)
-* [Functions and methods](##fedg_js-coding_naming_fns)
-* [Variables and properties](##fedg_js-coding_naming_vars)
+(function() {
+ // Some initialization code wrapped in a function to create a scope for locals.
+})();
+{% endhighlight %}
-### Curly braces {#fedg_js-coding_codestyle_curl}
-Because of implicit semicolon insertion, always start your curly braces on the same line as whatever they are opening.
+Since there is semicolon to end the first statement, the first function returns 42 and the script interprets 42 as a function.
+When the script tries to call 42 as a function with the second function as a parameter, an error occurs.
-For example:
+{% highlight javascript %}
+// Example 2: Trying to do one thing on Internet Explorer and another on Firefox.
+var x = {
+ 'i': 1,
+ 'j': 2
+ } // <-- Missing semicolon
- if (something) {
- // ...
- } else {
- // ...
- }
+[normalVersion, ffVersion][isIE]();
+{% endhighlight %}
-### Functions and methods {#fedg_js-coding_naming_fns}
-Function names may contain only alphanumeric characters.
+A 'no such property in undefined' error appears during runtime when the script tries to call `x[ffVersion][isIE]()`.
-Underscores are not permitted.
+{% highlight javascript %}
-Numbers are permitted in function names, but are discouraged in most cases.
+// Example 3: Conditional execution a la bash
+var THINGS_TO_EAT = [apples, oysters, sprayOnCheese] // <-- Missing semicolon
-Function names must always start with a lowercase letter.
+-1 == resultOfOperation() || die();
-When a function name consists of more than one word, use *camelCase* formatting, which capitalizes the first letter of each word.
+{% endhighlight %}
-Class method names should start with an English verb in infinitive form that describes the method.
+The script calls `die` unless `resultOfOperation)_` is `NaN` and assigns `THING_TO_EAT` the result of `die()`.
-Verbosity is generally encouraged. Function names should be as verbose as is needed to fully describe their purpose and behavior.
+#### Explanation
-Examples of acceptable function names include:
+JavaScript requires statements to end with a semicolon, except when it thinks it can safely infer their existence.
-* `filterInput()`
-* `getElementById()`
-* `widgetFactory()`
+In each of the examples above, a function declaration, or an object, or an array literal is used inside a statement.
-For object-oriented programming, accessors for instances or static variables should always have the `get` or `set` prefix.
+The closing brackets are not enough to indicate the end of the statement.
+JavaScript never ends a statement if the next token is an infix or bracket operator.
-In design patterns, such as the singleton or factory patterns, implementation method names should contain the pattern name where practical to provide the better behavior description.
+### Strings
-Methods that return certain status flags or other Boolean values should have the `has` or `is` prefix, instead of `get`.
+Use single quotes instead of double quotes for consistency.
-For object methods that are declared with the `private` or `protected` modifier, the method name should start with underscore (`_`).
+This is helpful when creating strings that include HTML:
+{% highlight javascript %}
+var msg = '<span class="text">Hello World!</div>';
+{% endhighlight %}
-This is the only acceptable use of an underscore in a method name. Public methods should never contain an underscore.
+## Additional naming convention standards
-### Variables and properties {#fedg_js-coding_naming_vars}
-Variable names may contain only alphanumeric characters.
+### General naming conventions
-Underscores (`_`) are not permitted.
+* Avoid underscores and numbers in names.
+* Variables or methods should have names that accurately describe their purpose or behavior.
+* Object methods or variables that are declared `private` or `protected` should start with an underscore(`_`).
-Numbers are permitted in variable names, but are discouraged in most cases.
+### Functions and methods
-Instance variables that are declared with the `private` or `protected` modifier, should start with a single underscore.
+* Class method names should start with an English verb in its infinitive form that describes the method.
+* Names for accessors for instance or static variables should always have the `get` or `set` prefix.
+* In {% glossarytooltip 53755359-9916-4677-bff2-f7d26025095a %}design pattern{% endglossarytooltip %} classes, implementation method names should contain the pattern name where practical to provide better behavior description.
+* Methods that return status flags or Boolean values should have the `has` or `is` prefix.
-This is the only acceptable use of the underscore in a variable name. Member variables declared as `public` should never start with an underscore.
+### Variables and properties
-Function names and variable names must always start with a lowercase letter and follow the camelCase capitalization convention.
+* Do not use short variable names such as `i` or `n` except in small loop contexts
+* If a loop contains more than 20 lines of code, the index variables should have more descriptive names.
-Verbosity is generally encouraged.
+## Additional coding construct standards
-Variables names should always be as verbose as needed to describe the data that the developer intends to store in them.
+### Binary and ternary operators
-Terse variable names such as `i` or `n` are discouraged for all, but the smallest loop contexts.
+Always put the operator on the preceding line to avoid implicit semi-colon insertion issues.
-If a loop contains more than 20 lines of code, the index variables should have more descriptive names.
+### Custom `toString()` method
-## Coding constructs {#coding-constructs}
-See one of the following sections:
+This method must always succeed without side effects.
-* [Array and object literals](#fedg_js-coding_codestyle_literals)
-* [Binary and ternary operators](#fedg_js-coding_codestyle_binary-ternary)
-* [Boolean expressions](#boolean)
-* [Boolean operators](#operators)
-* [Conditional (ternary) operators (? and :)](#conditional)
-* [Exceptions and custom exceptions](#exceptions)
-* [Function declarations within blocks](#functions-in-blocks)
-* [Standard features](#standard-features)
-* [Method definitions](#methods)
-* [Closures](#closures)
-
-
-### Array and object literals {#fedg_js-coding_codestyle_literals}
-Use array and object literals instead of array and object constructors.
-
-The following example is correct. Always use the more readable array literal:
-
- var a = [x1, x2, x3];
- var a2 = [x1, x2];
- var a3 = [x1];
- var a4 = [];
+### Function declarations within blocks
-
-
The following example is incorrect because array constructors are error-prone due to their arguments.
- Because of this, if someone changes the code to pass one argument instead of two arguments, the array might not have the expected length.
+Use a variable initialized with a function expression to define a function within a block.
-
-
-Object constructors don't have the same problems, but for readability and consistency object literals should be used.
-
- var o = {};
- var o2 = {
- a: 0,
- b: 1,
- c: 2,
- 'strange key': 3
- };
-
-### Binary and ternary operators {#fedg_js-coding_codestyle_binary-ternary}
-Always put the operator on the preceding line, so that you don't have to think about implicit semi-colon insertion issues.
-
-
-
-
Boolean expressions
-Pay attention to the values of the following Boolean expressions:
-
-
-
-
-
False
-
True
-
-
-
-
-
null
-
0
-
-
-
undefined
-
[] (empty array)
-
-
-
'' (the empty string)
-
{} (empty object)
-
-
-
0 (the number)
-
-
-
-
-
-The following code samples are equivalent:
-
-
-
-
-
Correct - long form
-
Correct - short form
-
Note
-
-
-
-
-
while (x != null)
-
while (x)
-
Equal as long as x is not 0, empty string, or false
-
-
-
if (y != null && y != '')
-
if (y)
-
-
-
-
-
-
Here are some examples of non-obvious Boolean expressions results:
-
-### Boolean operators (&& and ||) {#operators}
-These binary Boolean operators are short-circuited, and evaluate to the last evaluated term.
-
-The following code samples are equal:
-
-
-
-
-
Correct—long form
-
Correct—short form
-
Notes
-
-
-
-
-
-
function foo(opt_win) {
- var win;
- if (opt_win) {
- win = opt_win;
- } else {
- win = window;
- }
- // ...
-}
-
-
-
function foo(opt_win) {
- var win = opt_win || window;
- // ...
-}
-
-
That is why the || operator is the default.
-
-
-
-
if (node) {
- if (node.kids) {
- if (node.kids[index]) {
- foo(node.kids[index]);
- }
- }
-}
-
-
-
if (node && node.kids && node.kids[index]) {
- foo(node.kids[index]);
-}
-
-### Custom toString() method {#tostring-method}
-**Must always succeed without side effects.**
-You can control how your objects are converted to string by defining a custom `toString()` method.
-
-The method should:
-
-* Always succeed.
-* Not have side-effects.
-
-Otherwise you can run into serious problems. For example:
-
-* `toString()` calls a method that does an assert.
-* The assert tries to output the name of the object in which it failed.
-* `toString()` is called.
-
-### Function declarations within blocks {#functions-in-blocks}
-ECMAScript allows function declarations only in the root statement list of a script or a function.
-
-To define a function within a block, use a variable initialized with a function expression.
-
-**Wrong:**
-
- if (x) {
- function foo() {}
- }
+{% highlight javascript %}
+// Wrong
+if (x) {
+ function foo() {}
+}
-**Correct:**
+// Correct
+if (x) {
+ var foo = function() {}
+}
+{% endhighlight %}
- if (x) {
- var foo = function() {}
- }
+### Exceptions and custom exceptions
-
Exceptions and custom exceptions
You cannot avoid exceptions if you are doing something non-trivial (using an application development framework, and so on).
-Without custom exceptions, returning error information from a function that also returns a value can be tricky, not to mention inelegant. Bad solutions include passing in a reference type to hold error information or always returning Objects with a potential error member.
+Without custom exceptions, returning error information from a function that also returns a value can be tricky, not to mention inelegant.
+Bad solutions include passing in a reference type to hold error information or always returning Objects with a potential error member.
-These basically amount to a primitive exception handling hack. Feel free to use custom exceptions when appropriate.
+These basically amount to a primitive {% glossarytooltip 53da11f1-d0b8-4a7e-b078-1e099462b409 %}exception{% endglossarytooltip %} handling hack.
+Feel free to use custom exceptions when appropriate.
### Standard features {#standard-features}
+
For maximum portability and compatibility, use standard features whenever possible.
For example, `string.charAt(3)` instead of `string[3]`, and element access with DOM functions instead of using an application-specific shorthand.
-
Method definitions
+### Method definitions
+
There are several ways to attach methods and properties to a constructor, but the preferred style is:
- Foo.prototype.bar = function() {
- // ...
- };
+{% highlight javascript %}
+Foo.prototype.bar = function() {
+ // ...
+};
+{% endhighlight %}
Or you can also use this style:
- Foo.prototype = {
- bar: function() {
- // ...
+{% highlight javascript %}
+Foo.prototype = {
+ bar: function() {
+ // ...
},
- circle: function() {
- // ...
- }
- };
-
-### Closures {#closures}
-Keep in mind that a closure keeps a pointer to its enclosing scope.
-
-As a result, attaching a closure to a DOM element can create a circular reference and thus, a memory leak.
-
-**Wrong:**
-
- function foo(element, a, b) {
- element.onclick = function() { /* uses a and b */ };
+ circle: function() {
+ // ...
}
+};
+{% endhighlight %}
-The function closure keeps references to elements "a" and "b" even if it never uses them.
-
-Because elements also keep references to the closure, it is a cycle that will not be cleaned up by garbage collection. In these situations, the code can be structured as follows:
-
-**Correct:**
-
- function foo(element, a, b) {
- element.onclick = bar(a, b);
- }
-
- function bar(a, b) {
- return function() { /* uses a and b */ }
- }
-
-## General recommendations {#general-recommendations}
-See one of the following sections:
-
-* [Do not use eval](#eval)
-* [Do not use with()](#with)
-* [Use this with caution](#this)
-* [Array and object initializers](#fedg_js-coding_codestyle_arrayinit)
-* [Do not use associative arrays](#fedg_js-coding_codestyle_arrayinit)
-* [Use deferred initialization](#deferred-init)
-* [Do not modify built-in objects](#prototypes)
-* [Declare variables](#variables-scope)
+### Closures
-### Do not use eval() {#eval}
-Avoid using `eval()`.
+A closure keeps a pointer to its enclosing scope, so attaching a closure to a DOM element can create a circular reference and thus, a memory leak.
-The `eval()` function makes for confusing semantics and is dangerous to use if the string passed to `eval()` contains user input. Usually better options exist allowing to omit `eval()`, so its usage is generally not permitted. However, it is accepted for unserializing tasks (for example, to evaluate RPC responses), as it makes them much easier.
+{% highlight javascript %}
+// Wrong
+function foo(element, a, b) {
+ element.onclick = function() { /* uses a and b */ };
+}
+{% endhighlight %}
-### Do not use with() {#with}
-Do not use the `with()` statement.
-
-Using `with()` clouds the semantics of your program, because its object can have properties that collide with local variables, which can drastically change the meaning of your program.
-
-Example: what will be the result of the following code execution?
-
- with (foo) {
- var x = 3;
- return x;
- }
-
-Answer: anything.
+The function closure keeps references to elements "a" and "b" even if it never uses them.
-The local variable x could be clobbered by a property of foo, and perhaps it even has a setter, in which case assigning 3 could cause lots of other code to execute.
+Because elements also keep references to the closure, it is a cycle that will not be cleaned up by garbage collection.
+In these situations, the code can be structured as follows:
-### Use this with caution {#this}
-Semantic of this can be tricky. It can refer to either:
+{% highlight javascript %}
+// Correct
+function foo(element, a, b) {
+ element.onclick = bar(a, b);
+}
+function bar(a, b) {
+ return function() { /* uses a and b */ }
+}
+{% endhighlight %}
-* global object (in most cases)
-* the scope of the caller (in eval)
-* a node in the DOM tree (when attached using an event handler HTML attribute)
-* a newly created object (in a constructor)
-* other object - if a function was called by call() or apply().
+## Additional general standards
-To avoid confusion, use this only in object constructors, methods, and in closures setting up.
+### Array and object initializers
-### Array and object initializers {#fedg_js-coding_codestyle_arrayinit}
Single-line array and object initializers are allowed when they fit on a line as follows:
+{% highlight javascript %}
var arr = [1, 2, 3]; // No space after [ or before ].
- var obj = {a: 1, b: 2, c: 3}; // No space after { or before }.
-
-Multi-line array and object initializer must be indented four spaces.
+ var obj = {a: 1, b: 2, c: 3}; // No space after { or before }.
+{% endhighlight %}
-
Long identifiers or values present problems for aligned initialization lists, so always prefer non-aligned initialization.
For example:
- Object.prototype = {
- a: 0,
- b: 1,
- lengthyName: 2
- };
-
-
+};
+{% endhighlight %}
-### Do not use associative arrays {#associative-arrays}
-Do not use associative arrays.
+### Associative arrays
-If you need a map/hash, use Object instead of Array, because the features you need are actually Object features.
+Use `Object` instead of `Array` for associative arrays.
-`Array` just happens to extend `Object`.
+### Deferred initialization
-### Use deferred initialization {#deferred-init}
-It is sometimes impossible to initialize variables at the point of declaration, so deferred initialization is a good solution.
+Use deferred initialization when it is not possible to initialize variables at the point of declaration.
-### Use explicit scope {#explicit-scope}
-Always use explicit scope. This increases code portability and clarity.
+### Explicit scope
-For example, do not rely on window being in the scope chain. You might want to use your function in another application, for which this window is not the content window.
+Use explicit scope to increase code portability and clarity.
-### Do not modify built-in objects {#prototypes}
-
-
- Modifying built-ins like Object.prototype and Array.prototype is strictly forbidden.
+### Built-in objects
-
-
- Modifying other built-ins like Function.prototype is less dangerous, but still leads to debugging issues in production and should be avoided.
+Modifying built-in like `Object.prototype` and `Array.prototype` is strictly forbidden.
-
-
+Modifying other built-ins like `Function.prototype` is less dangerous but leads to debugging issue in production.
-### Declare variables {#variables-scope}
-If you do not declare a variable, it is placed in the global context, potentially clobbering existing values.
+### Variable declarations
-It also makes hard to define the variable scope. For example, it can be Document, Window or local scope.
+Declare a variable with `var` wherever possible to avoid overwriting existing global values.
-So always declare variables with var.
+Using only one var per scope promotes readability.
-Using only one var per scope (function) promotes readability.
+{% highlight javascript %}
+var foo == 'bar,'
+ num = 1,
+ arr = [1, 2, 3];
+{% endhighlight %}
- var foo = "bar,"
- num = 1,
- arr = [1, 2, 3];
+[js-guide]: https://google.github.io/styleguide/jsguide.html
+[jquery]: https://jquery.com/
+[jquery-widgets]: http://api.jqueryui.com/category/widgets
+[jquery-widget-coding-standard]: {{page.baseurl}}coding-standards/code-standard-jquery-widgets.html
+[jshint]: http://www.JSHint.com
diff --git a/guides/v2.0/coding-standards/code-standard-jquery-widgets.md b/guides/v2.0/coding-standards/code-standard-jquery-widgets.md
index 0dfc0ae377f..b896f22fbf3 100644
--- a/guides/v2.0/coding-standards/code-standard-jquery-widgets.md
+++ b/guides/v2.0/coding-standards/code-standard-jquery-widgets.md
@@ -11,784 +11,281 @@ github_link: coding-standards/code-standard-jquery-widgets.md
redirect_from: /guides/v1.0/coding-standards/code-standard-jquery-widgets.html
---
-
Overview
-
In the Magento system, all jQuery UI widgets and interactions are built on a simple, reusable base—the jQuery UI Widget Factory. The factory provides a flexible base for building complex, stateful plug-ins with a consistent API. It is designed not only for plug-ins that are part of jQuery UI, but for general usage by developers who want to create object-oriented components without reinventing common infrastructure.
This standard is mandatory for Magento core developers and recommended for third-party extension developers. Some parts of Magento code might not comply with the standard, but we are working to gradually improve this.
-
Use RFC 2119 to interpret the "must," "must not," "required," "shall," "shall not," "should," "should not," "recommended," "may," and "optional" keywords.
-
-
Naming conventions
-
Widget names must consist of one or more non-abbreviated English words
Widget names should be as verbose as needed to fully describe their purpose and behavior.
-
-
-
-
Correct
-
Incorrect
-
-
-
-
// Declaration of the frontend.advancedEventTrigger widget
+In the Magento system, all jQuery UI widgets and interactions are built on a simple, reusable base—the [jQuery UI Widget Factory][jquery-ui-widget-factory]{:target="_blank"}.
+
+The factory provides a flexible base for building complex, stateful plug-ins with a consistent {% glossarytooltip 786086f2-622b-4007-97fe-2c19e5283035 %}API{% endglossarytooltip %}.
+It is designed not only for plug-ins that are part of {% glossarytooltip 5bfa8a8e-6f3e-4fed-a43e-62339916f02e %}jQuery{% endglossarytooltip %} UI, but for general usage by developers who want to create object-oriented components without reinventing common infrastructure.
+
+For more information, see the [jQuery Widget API documentation][jquery-ui-api-doc]{:target="_blank"}.
+
+This standard is mandatory for Magento core developers and recommended for third-party {% glossarytooltip 55774db9-bf9d-40f3-83db-b10cc5ae3b68 %}extension{% endglossarytooltip %} developers.
+Some parts of Magento code might not comply with the standard, but we are working to gradually improve this.
+
+Use [RFC 2119][rfc2119]{:target="_blank"} to interpret the "must," "must not," "required," "shall," "shall not," "should," "should not," "recommended," "may," and "optional" keywords.
+
+## Naming conventions
+
+* {% glossarytooltip f0dcf847-ce21-4b88-8b45-83e1cbf08100 %}Widget{% endglossarytooltip %} names must consist of one or more non-abbreviated English word and in camelcase format.
+
+ {% highlight javascript %}
+
(function($) {
-"use strict";
+ $.widget('mage.accordion', $.ui.accordion, {
+ // ... My custom code ...
+ });
+ {% endhighlight %}
-$.widget('mage.advancedEventTrigger', $.ui.button, {
- // ... My custom code ...
-});
-}) (jQuery);
-
-
-
// Declaration of the ui.button widget
+* Widget names should be verbose enough to fully describe their purpose and behavior.
+
+ {% highlight javascript %}
+// Declaration of the frontend.advancedEventTrigger widget
(function($) {
-"use strict";
+ "use strict";
-$.widget('ui.button', $.ui.button, {
- // ... My custom code ...
-});
-}) (jQuery);
-
-
-
-
-
-
-
Instantiation and resources
-
-
Additional JavaScript files used as resources by a widget
-
-
Additional JavaScript files used as resources must be dynamically loaded using the $.mage.components() method and must not be included in the <head> block.
-
-
-
-
Correct
-
Incorrect
-
-
-
-
-
-
-
-
-
-
-
-
-
You must use $.mage.extend() to extend an existing set of widget resources
-
-
-
-
-
Correct
-
Incorrect
-
-
-
-
-
-
-
-
-
-
-
-
-
You must instantiate widgets using the data-mage-init attribute
-
-
-
You can use the .mage() plug-in to instantiate widgets that use callback methods.
-
-
Benefits:
-
-
You leverage benefits of $.mage.extend() and $.mage.components()
-
Using data-mage-init minimizes inline JavaScript code footprint.
-
You can modify widget initialization parameters.
-
-
-
-
-
Correct
-
Incorrect
-
-
-
-
// Widget initialization using the data-mage-init attribute
-<form data-mage-init="{form:[], validation:{ignore:':hidden'}}"></form>
-
// Widget initialization using the mage plug-in
-<script type="text/javascript">
+ $.widget('mage.advancedEventTrigger', $.ui.button, {
+ // ... My custom code ...
+ });
+}) (jQuery);
+ {% endhighlight %}
+
+## Instantiation and resources
+
+* Additional {% glossarytooltip 312b4baf-15f7-4968-944e-c814d53de218 %}JavaScript{% endglossarytooltip %} files used as a resources must be dynamically loaded using the `$.mage.components()` method and must not be included in the `` block.
+* Use the `$.mage.components()` method to load additional JavaScript resource files not included in the `` block.
+* You must use `$.mage.extend()` to extend an existing set of widget resources.
+* You must instantiate widgets using the `data-mage-init` attribute.
+ You can use the `.mage()` {% glossarytooltip 9fceecbe-31be-4e49-aac7-11d155a85382 %}plug-in{% endglossarytooltip %} to instantiate widgets that use callback methods.
+
+ Benefits:
+
+ * You leverage the benefits of `$.mage.extend()` and `$.mage.components()`.
+ * Using `data-mage-init` minimizes the inline JavaScript code footprint.
+ * You can modify widget initialization parameters.
+
+ {% highlight javascript %}
+// Widget initialization using the data-mage-init attribute
+
+
+// Widget initialization using the mage plug-in
(function($) {
+ $('selector').mage('dialog', {
+ close: function(e) {
+ $(this).dialog('destroy');
+ }
+ });
+})(jQuery);
+ {% endhighlight %}
+
+* You can declare callback methods inline JavaScript but not methods and widgets.
+
+ {% highlight javascript %}
+// Widget initialization and configuration
$('selector').mage('dialog', {
close: function(e) {
$(this).dialog('destroy');
}
});
-})(jQuery);
-</script>
-
-
-
// Widget initialization without using the mage plug-in
-<script type="text/javascript">
-(function($) {
-$('[data-role="form"]')
- .form()
- .validation({
- ignore: ':hidden'
- });
-})(jQuery);
-</script>
-
-
-
-
-
-
Methods and widgets must not be declared using inline JavaScript
// Widget initialization and binding event handlers
+
+// Widget initialization and binding event handlers
$('selector').mage('dialog').on('dialogclose', {
-$(this).dialog('destroy');
-});
-
// Extension for widget in a JavaScript file
+ $(this).dialog('destroy');
+});
+
+// Extension for widget in a JavaScript file
$.widget('mage.dialog', $.ui.dialog, {
-close: function() {
- this.destroy();
-}
-});
The responsibilities which are not related to the entity described by the widget should be moved to another widget.
-
-
-
-
Correct
-
Incorrect
-
-
-
-
// Widget "dialog" that is responsible
+ {% endhighlight %}
+
+## Development standards
+
+* Widgets should comply with the [single responsibility principle][single-responsibility-principle]{:target="_blank"}.
+
+ Widgets should not have responsibilities not related to the {% glossarytooltip a9027f5d-efab-4662-96aa-c2999b5ab259 %}entity{% endglossarytooltip %} described by the widget.
+
+ {% highlight javascript %}
+// Widget "dialog" that is responsible
// only for opening content in an interactive overlay.
$.widget('mage.dialog', {
-/* ... */
-});
-
// Widget "validation" that is responsible
+ // Code logic
+});
+
+// Widget "validation" that is responsible
// only for validating the form fields.
$.widget('mage.validation', $.ui.sortable, {
-/* ... */
-});
// Widget named 'dialog' that is
-// responsible for opening content in
-// an interactive overlay and
-// validating the form fields.
+ // Code logic
+});
+
+$('selector')
+ .mage('dialog')
+ .find('form')
+ .mage('validation');
+ {% endhighlight %}
+
+* Widget properties that modify the widget's behavior must be located in the widget's options to make them configurable and reusable.
+
+ {% highlight javascript %}
+//Declaration of the backend.dialog widget
$.widget('mage.dialog', {
-/* ... */
-_validateForm: function() {
- /* code which validates the form */
-}
-});
-
$('selector').mage('dialog')
-
-
-
-
-
-
All widget properties that can be used to modify widget's behavior must be located in widget's options.
-
-
Benefit: Widgets become configurable and reusable.
You must locate all of these under the <your Magento install dir>/app/code/<namespace>/<ModuleName>/view/<areaname>/js directory.
-
-
-
-
-
Correct
-
Incorrect
-
-
-
-
/app
-/code
+});
+
+ {% endhighlight %}
+
+* You must use [DOM event bubbling][dom-event-bubbling]{:target="_blank"} to perform one-way communication between a child widget and its parent widget.
+
+* Widgets must comply with the [Law of Demeter][law-of-demeter]{:target="_blank"} principle.
+ Do not instantiate a widget or call a widget's methods inside another widget.
+
+* Make widgets abstract enough so that they can be used anywhere in Magento.
+
+ For example, the `mage.dropdown` widget is applicable in many other scenarios, unlike `mage.topShoppingCart`.
+
+* Place abstract, share-able widgets under the `/pub/lib/` directory so non-Magento applications can access them.
+
+ For example:
+
+ ~~~
+/pub
+ /lib
+ /magento
+ dropdown.js
+ validation.js
+ dialog.js
+ ~~~
+
+* Place Magento-specific widgets under the `/app/code///view//js` directory.
+
+ For example:
+
+ ~~~
+/app
+ /code
/Mage
- /DesignEditor
- /view
- /frontend
- /js
- vde-block.js
- vde-container.js
// Declaration of the backend.accordion widget
+ /DesignEditor
+ /view
+ /frontend
+ /js
+ vde-block.js
+ vde-container.js
+ ~~~
+
+## Architecture
+
+* Use an underscore prefix to declare private widget methods.
+
+ Properties without an underscore prefix are accessible using the jQuery Widget factory public API.
+
+ {% highlight javascript %}
+// Declaration of the backend.accordion widget
$.widget('mage.accordion', {
-/* ... */
-_create: function() {
- this._header = this.element.find(this.options.header);
- this._icon = $(this.options.icon).prependTo(this._header);
-}
-});
-
-
-
-
-
-
A widget's element selection should start with this.element
-
-
-
-
-
Correct
-
Incorrect
-
-
-
-
-
-
-
-
-
-
-
-
-
Widgets must not interact with certain DOM elements
-
Widgets must not interact with DOM elements that can be selected with this.element.parent(), this.element.parents('selector'), or this.element.closest('selector').
-
Benefit: Reduced number of widget conflicts because widgets interact only with their child elements.
-
-
-
-
-
Correct
-
Incorrect
-
-
-
-
-
-
-
-
-
-
-
-
-
All widget options should have default values
-
If there is no default value for an option by design, a null value must be used.
-
-
-
-
-
Correct
-
Incorrect
-
-
-
-
-
-
-
-
-
-
-
-
-
All DOM selectors used by a widget must be passed to the widget as options
-
-
-
-
-
Correct
-
Incorrect
-
-
-
-
-
-
-
-
-
-
-
-
-
If an immediate state change is required, the change must be processed by the _setOption method
-
-
-
-
-
Correct
-
Incorrect
-
-
-
-
-
-
-
-
-
-
-
-
-
To call widget methods, you must use the public widget API
-
Benefit: The public widget API enables using chaining for widget methods.
-
-
-
-
-
Correct
-
Incorrect
-
-
-
-
// Call the 'open' method on the menu widget using the public widgets API
+ _create: function() {
+ this.header = this.element.find(this.options.header);
+ this.icon = $(this.options.icon).prependTo(this.header);
+ }
+});
+ {% endhighlight %}
+
+* Start a widget's element selection with `this.element`
+* Widgets must not interact with DOM elements selected using `this.element.parent()`, `this.element('selector')`, or `this.element.closest('selector')`.
+
+ This reduces the number of widget conflicts because widgets interact only with their child elements.
+* Widget options should have default values.
+ Use a `null` value if there is no default value for an option.
+* Pass as widget options all DOM selectors used by that widget.
+* Use the `_setOption` method to process required, immediate state changes.
+* Use the public widget API to call widget methods to allow chaining widget methods.
+
+ {% highlight javascript %}
+// Call the 'open' method on the menu widget using the public widgets API
$('selector')
.menu('open')
-.addClass('ui-state-active');
-
-
-
// Call the 'open' method on the
-// menu widget without using the public
-// widgets API
-var menuInstance = $('selector').data('menu');
-menuInstance.open();
-menuInstance.element.addClass('ui-state-active');
-
-
-
-
-
-
-
Widget initialization
-
Initializing a widget must be handled only if there is a logical action to perform on successive calls to the widget with no arguments.
-
The widget factory automatically fires the _create() and _init() methods during initialization, in that order. The widget factory prevents multiple instantiations on the same element, which is why _create() is called only once for each widget instance, whereas _init() is called each time the widget is called without arguments.
-
-
-
-
-
Correct
-
Incorrect
-
-
-
-
-
-
-
-
-
-
-
-
-
When a widget is destroyed, the element should be left exactly like it was before the widget was attached to it
-
Common tasks include:
-
-
Removing or adding of any CSS classes your widget added/removed from the element.
-
Detaching any elements your widget added to the DOM.
-
Destroying any widgets that your widget applied to other elements.
-
-
Example:
-
-
-
-
All event handlers must be bound by the _bind() method
-
Benefit: All widget event handlers are bound in one place (by the _bind method), which makes it easy to find what events the widget reacts on.
-
-
-
-
-
Correct
-
Incorrect
-
-
-
-
-
-
-
-
-
-
-
-
-
You must use the _on() method to bind events
-
Benefits:
-
-
Delegation is supported using selectors in the event names; for example, click .foo
-
Maintains proper this context inside the handlers, so it is not necessary to use the $.proxy() method.
-
Event handlers are automatically namespaced and cleaned up on destruction.
+.addClass('ui-state-active');
+ {% endhighlight %}
+
+* Handle widget initialization if there is a logical action to perform on successive calls to the widget with no arguments.
+
+ The widget factory automatically fires the `_create()` and `_init()` methods during initialization, in that order and prevents multiple instantiations of the same element.
+
+ The `_create()` method is called only once for each widget instance and `_init()` is called each time the widget is called without arguments.
+* When a widget is destroyed, the attached element should be left exactly like it was before attachment.
+
+ Common tasks for this include:
+
+ * Removing or adding any {% glossarytooltip 6c5cb4e9-9197-46f2-ba79-6147d9bfe66d %}CSS{% endglossarytooltip %} classes the widget added/removed to the element.
+ * Detaching any elements the widget added to the DOM.
+ * Destroying any widgets that the widget applied to other elements.
+
+* Bind {% glossarytooltip c57aef7c-97b4-4b2b-a999-8001accef1fe %}event{% endglossarytooltip %} handlers using the `_bind()` method to make it easy to find what events the widget reacts on.
+* Bind events using the `on()` method.
+
+ Benefits:
+
+ * Delegation is supported using selectors in the event names.
+ For example: `click.foo`.
+ * Maintains proper `this` context inside the handlers, so it is not necessary to use the `$.proxy()` method.
+ * Event handlers are automatically namespaced and cleaned up on destruction.
+
+[jquery-ui-widget-factory]: http://jqueryui.com/widget/
+[jquery-ui-api-doc]: http://api.jqueryui.com/jQuery.widget/
+[rfc2119]: http://www.ietf.org/rfc/rfc2119.txt
+[single-responsibility-principle]: https://en.wikipedia.org/wiki/Single_responsibility_principle
+[dom-event-bubbling]: http://stackoverflow.com/questions/4616694/what-is-event-bubbling-and-capturing
+[law-of-demeter]: http://en.wikipedia.org/wiki/Law_of_Demeter
diff --git a/guides/v2.0/coding-standards/code-standard-less.md b/guides/v2.0/coding-standards/code-standard-less.md
index 7ef7c986083..4091f52e5b8 100644
--- a/guides/v2.0/coding-standards/code-standard-less.md
+++ b/guides/v2.0/coding-standards/code-standard-less.md
@@ -10,7 +10,7 @@ version: 2.0
github_link: coding-standards/code-standard-less.md
---
-This standard defines Magento internal requirements for code formatting and style for teams that develop LESS and CSS code.
+This standard defines Magento internal requirements for code formatting and style for teams that develop LESS and {% glossarytooltip 6c5cb4e9-9197-46f2-ba79-6147d9bfe66d %}CSS{% endglossarytooltip %} code.
Some parts of Magento code might not comply with this coding standard yet, but we are working to gradually improve this.
@@ -582,7 +582,7 @@ Omit leading "0"s in values, use dot instead.
#### Local variables
-If variables are local and used only in a module scope, they should be located in the module file, in the beginning of the general comment.
+If variables are local and used only in a {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} scope, they should be located in the module file, in the beginning of the general comment.
**Example** `_module.less`:
@@ -657,11 +657,11 @@ Component name must meaningful. It can contain the `primary`, `secondary`, `tert
### Location
-Theme mixins (except extends) should be located in the `source/utilities` directory.
+{% glossarytooltip d2093e4a-2b71-48a3-99b7-b32af7158019 %}Theme{% endglossarytooltip %} mixins (except extends) should be located in the `source/utilities` directory.
### Naming
-For mixin naming apply the class naming rules.
+For {% glossarytooltip 1a305bdb-9be8-44aa-adad-98758821d6a7 %}mixin{% endglossarytooltip %} naming apply the class naming rules.
For mixins grouping use the double underscore "__" prefix.
@@ -688,7 +688,7 @@ Extend names should start with the `.abs-` prefix.
## `@import` directive
-Always add the file extension of the imported resource.
+Always add the file {% glossarytooltip 55774db9-bf9d-40f3-83db-b10cc5ae3b68 %}extension{% endglossarytooltip %} of the imported resource.
**Correct**:
diff --git a/guides/v2.0/coding-standards/code-standard-php.md b/guides/v2.0/coding-standards/code-standard-php.md
index 0dbcf2d5fbf..86c11100914 100644
--- a/guides/v2.0/coding-standards/code-standard-php.md
+++ b/guides/v2.0/coding-standards/code-standard-php.md
@@ -19,12 +19,12 @@ Otherwise, you must apply these standards and requirements through rigorous code
### Class name resolution standard
-For class name resolution, use the [`::class`](http://php.net/manual/en/language.oop5.basic.php#language.oop5.basic.class.class){:target="_blank"} keyword instead of a string literal for every class name reference outside of that class.
+For class name resolution, use the [`::class`](http://php.net/manual/en/language.oop5.basic.php#language.oop5.basic.class.class){:target="_blank"} {% glossarytooltip caa46cea-25d7-4e4f-bce1-11430ada59dc %}keyword{% endglossarytooltip %} instead of a string literal for every class name reference outside of that class.
This includes references to:
* Fully qualified class name
* Imported/non-imported class name
-* Namespace relative class name
+* {% glossarytooltip 621ef86b-7314-4fbc-a80d-ab7fa45a27cb %}Namespace{% endglossarytooltip %} relative class name
* Import relative class name
Examples:
diff --git a/guides/v2.0/coding-standards/code-standard-sniffers.md b/guides/v2.0/coding-standards/code-standard-sniffers.md
index 4560f5bf119..819e9155a58 100644
--- a/guides/v2.0/coding-standards/code-standard-sniffers.md
+++ b/guides/v2.0/coding-standards/code-standard-sniffers.md
@@ -14,7 +14,7 @@ github_link: coding-standards/code-standard-sniffers.md
We recommend the consistent use of a code sniffer to enhance the readability of your code and help ensure that it meets Magento code standards. A code sniffer is a tool that automates the process of identifying code irregularities. Although a sniffer will identify many more inconsistencies and errors than a manual edit, we recommend that you evaluate and make any fixes that your sniffer program identifies.
-Magento recommends the use of [PHP_CodeSniffer](http://pear.php.net/manual/en/package.php.php-codesniffer.faq.php){:target="_blank"}, the most popular code sniffer in use throughout the PHP development community.
+Magento recommends the use of [PHP_CodeSniffer](http://pear.php.net/manual/en/package.php.php-codesniffer.faq.php){:target="_blank"}, the most popular code sniffer in use throughout the {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} development community.
PHP_CodeSniffer 1.4.0+ includes PSR-1 and PSR-2 standards, which are followed by Magento 2.
You can configure PHP_CodeSniffer to use your own rules, too. The [Magento Extension Quality Program Coding Standard](https://github.com/magento/marketplace-eqp){:target="_blank"} provides specifications that you can use to configure your code sniffer of choice to bring your _PHP coding style closer to Magento PHP standards_.
@@ -25,4 +25,4 @@ You can configure PHP_CodeSniffer to use your own rules, too. The [Magento Exten
Magento supports the [PSR-1](http://www.php-fig.org/psr/psr-1/){:target="_blank"} and [PSR-2](http://www.php-fig.org/psr/psr-2/){:target="_blank"} standards.
-The [Coding standards overview](http://devdocs.magento.com/guides/v2.0/coding-standards/bk-coding-standards.html){:target="_blank"} introduces Magento-specific practices for PHP, JavaScript, and JQuery.
+The [Coding standards overview](http://devdocs.magento.com/guides/v2.0/coding-standards/bk-coding-standards.html){:target="_blank"} introduces Magento-specific practices for PHP, JavaScript, and {% glossarytooltip 5bfa8a8e-6f3e-4fed-a43e-62339916f02e %}JQuery{% endglossarytooltip %}.
diff --git a/guides/v2.0/coding-standards/docblock-standard-general.md b/guides/v2.0/coding-standards/docblock-standard-general.md
index e1be071e2c3..c4ccd083e68 100644
--- a/guides/v2.0/coding-standards/docblock-standard-general.md
+++ b/guides/v2.0/coding-standards/docblock-standard-general.md
@@ -133,7 +133,7 @@ If the file contains a structural element (for example, a class), description fo
Use the following templates for the license notice and copyright blocks:
-**Template for PHP Files**
+**Template for {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} Files**
{% highlight php %}
Introduction
-To add JavaScript code inline documentation, follow these guidelines. Some parts of Magento code may not comply with this standard, but we are working to gradually improve this. Following these standard is optional for 3rd-party Magento developers, but will help to create consistent, clean, and easy to read inline documentation.
+To add {% glossarytooltip 312b4baf-15f7-4968-944e-c814d53de218 %}JavaScript{% endglossarytooltip %} code inline documentation, follow these guidelines. Some parts of Magento code may not comply with this standard, but we are working to gradually improve this. Following these standard is optional for 3rd-party Magento developers, but will help to create consistent, clean, and easy to read inline documentation.
This standard are a subset of Google JavaScript Style Guide regulations.
Use RFC 2119 to interpret the "must," "must not," "required," "shall," "shall not," "should," "should not," "recommended," "may," and "optional" keywords.
@@ -43,7 +43,7 @@ Example:
*/
-Many tools extract metadata from JSDoc comments to validate and optimize the code.
+Many tools extract {% glossarytooltip 3f0f2ef1-ad38-41c6-bd1e-390daaa71d76 %}metadata{% endglossarytooltip %} from JSDoc comments to validate and optimize the code.
JSDoc indentation
@@ -224,7 +224,7 @@ Type names must be enclosed in curly braces. If the type is omitted, the compile
* @param {string|number|null} term An itemName,
* or itemId, or null to search everything.
*/
-namespace.Storage.prototype.query = function(groupNum, term) {
+{% glossarytooltip 621ef86b-7314-4fbc-a80d-ab7fa45a27cb %}namespace{% endglossarytooltip %}.Storage.prototype.query = function(groupNum, term) {
// ...
};
@@ -246,7 +246,7 @@ namespace.Storage.prototype.getLastId = function() {
@this
-The type of the object in whose context a particular method is called. Required when the this keyword is referenced from a function that is not a prototype method.
+The type of the object in whose context a particular method is called. Required when the this {% glossarytooltip caa46cea-25d7-4e4f-bce1-11430ada59dc %}keyword{% endglossarytooltip %} is referenced from a function that is not a prototype method.
pinto.chat.RosterWidget.extern('getRosterElement',
/**
diff --git a/guides/v2.0/comp-mgr/cli/cli-upgrade.md b/guides/v2.0/comp-mgr/cli/cli-upgrade.md
index 2d72ed56509..403230e94ad 100644
--- a/guides/v2.0/comp-mgr/cli/cli-upgrade.md
+++ b/guides/v2.0/comp-mgr/cli/cli-upgrade.md
@@ -13,7 +13,7 @@ github_link: comp-mgr/cli/cli-upgrade.md
## Command-line upgrade
You can upgrade Magento from the command line if you installed the software using any of the following:
-* Downloaded the metapackage using `composer create-project`
+* Downloaded the {% glossarytooltip 7490850a-0654-4ce1-83ff-d88c1d7d07fa %}metapackage{% endglossarytooltip %} using `composer create-project`
* Installed the compressed archive
diff --git a/guides/v2.0/comp-mgr/marketplace/marketplace.md b/guides/v2.0/comp-mgr/marketplace/marketplace.md
index b279dfab3ef..f05eafd3033 100644
--- a/guides/v2.0/comp-mgr/marketplace/marketplace.md
+++ b/guides/v2.0/comp-mgr/marketplace/marketplace.md
@@ -25,7 +25,7 @@ If you don't have an account yet:
{:width="300px"}
### Find an extension or theme
-Browse Marketplace to find an extension or theme. For example, you can enter all or part of a name in the search field, you can scroll down the page, or you can select options from the filters.
+Browse Marketplace to find an {% glossarytooltip 55774db9-bf9d-40f3-83db-b10cc5ae3b68 %}extension{% endglossarytooltip %} or {% glossarytooltip d2093e4a-2b71-48a3-99b7-b32af7158019 %}theme{% endglossarytooltip %}. For example, you can enter all or part of a name in the search field, you can scroll down the page, or you can select options from the filters.
### Add to cart
Supply any required information for the extension or theme and click **Add to Cart**.
diff --git a/guides/v2.0/comp-mgr/module-man/compman-checklist.md b/guides/v2.0/comp-mgr/module-man/compman-checklist.md
index 82e908644e7..7248933a730 100644
--- a/guides/v2.0/comp-mgr/module-man/compman-checklist.md
+++ b/guides/v2.0/comp-mgr/module-man/compman-checklist.md
@@ -15,7 +15,7 @@ redirect_from: /guides/v2.0/comp-mgr/compman-checklist.html
This section discusses how to start the Component Manager, which updates or uninstalls Magento components:
* Modules (extend Magento capabilities)
-* Themes (change the look and feel of your storefront and Admin)
+* Themes (change the look and feel of your {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %} and Admin)
* Language packages (localize the storefront and Admin)
-Magento requires any component that has more than one type to be a metapackage. For example, we require a component that contains a module and a theme to be packaged as a metapackage.
+Magento requires any component that has more than one type to be a metapackage. For example, we require a component that contains a module and a {% glossarytooltip d2093e4a-2b71-48a3-99b7-b32af7158019 %}theme{% endglossarytooltip %} to be packaged as a metapackage.
We currently do not support uninstalling a metapackage.
diff --git a/guides/v2.0/comp-mgr/module-man/compman-readiness.md b/guides/v2.0/comp-mgr/module-man/compman-readiness.md
index 1d3d9e58571..a9a26837894 100644
--- a/guides/v2.0/comp-mgr/module-man/compman-readiness.md
+++ b/guides/v2.0/comp-mgr/module-man/compman-readiness.md
@@ -11,7 +11,7 @@ github_link: comp-mgr/module-man/compman-readiness.md
redirect_from: /guides/v2.0/comp-mgr/compman-readiness.html
---
-The readiness check makes sure your server and environment are set up correctly for updating, enabling, or disabling components. In the event of errors, you can consult troubleshooting suggestions in this guide.
+The readiness check makes sure your server and environment are set up correctly for updating, enabling, or disabling components. In the {% glossarytooltip c57aef7c-97b4-4b2b-a999-8001accef1fe %}event{% endglossarytooltip %} of errors, you can consult troubleshooting suggestions in this guide.
To start, click either **Start Readiness Check** or **Next**. A sample follows.
diff --git a/guides/v2.0/comp-mgr/module-man/compman-start.md b/guides/v2.0/comp-mgr/module-man/compman-start.md
index 08cbe6b812d..291fa0096fb 100644
--- a/guides/v2.0/comp-mgr/module-man/compman-start.md
+++ b/guides/v2.0/comp-mgr/module-man/compman-start.md
@@ -16,7 +16,7 @@ redirect_from:
Start the Component Manager from the Magento Admin
To run the Component Manager:
-1. Log in to the Magento Admin as an administrator.
+1. Log in to the {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %} as an administrator.
2. Click **System** > **Web Setup Wizard**.
The following page displays.
To enter your authentication tokens:
-1. Log in to the Magento Admin as an administrator.
+1. Log in to the {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %} as an administrator.
2. Click **System** > Tools > **Web Setup Wizard**.
3. Click **System Configuration**.
diff --git a/guides/v2.0/comp-mgr/trouble/cman/ce-ee-upgrade.md b/guides/v2.0/comp-mgr/trouble/cman/ce-ee-upgrade.md
index b10da49d1ce..8be08299b06 100644
--- a/guides/v2.0/comp-mgr/trouble/cman/ce-ee-upgrade.md
+++ b/guides/v2.0/comp-mgr/trouble/cman/ce-ee-upgrade.md
@@ -20,7 +20,7 @@ Your upgrade from Magento Community Edition (CE) to Enterprise Edition (EE) migh
If this error displays, resolve it as follows:
-1. Log in to your Magento server as the Magento file system owner.
+1. Log in to your Magento server as the {% glossarytooltip 5e7de323-626b-4d1b-a7e5-c8d13a92c5d3 %}Magento file system owner{% endglossarytooltip %}.
2. Enter the following commands in the order shown:
php /bin/magento setup:upgrade
diff --git a/guides/v2.0/comp-mgr/trouble/cman/cron.md b/guides/v2.0/comp-mgr/trouble/cman/cron.md
index e0927a06844..6ff1572bc46 100644
--- a/guides/v2.0/comp-mgr/trouble/cman/cron.md
+++ b/guides/v2.0/comp-mgr/trouble/cman/cron.md
@@ -13,7 +13,7 @@ github_link: comp-mgr/trouble/cman/cron.md
Following are symptoms of cron issues:
* Your update or upgrade never runs; it stays in a `pending` state
-* An error message about the PHP setting `$HTTP_RAW_POST_DATA` displays even though it's set properly
+* An error message about the {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} setting `$HTTP_RAW_POST_DATA` displays even though it's set properly
* The cron readiness check fails
Possible errors include non-writable paths and cron not set up. An example follows:
diff --git a/guides/v2.0/comp-mgr/trouble/cman/maint-mode.md b/guides/v2.0/comp-mgr/trouble/cman/maint-mode.md
index 4bc81adaf48..91fcfddd6fc 100644
--- a/guides/v2.0/comp-mgr/trouble/cman/maint-mode.md
+++ b/guides/v2.0/comp-mgr/trouble/cman/maint-mode.md
@@ -12,7 +12,7 @@ github_link: comp-mgr/trouble/cman/maint-mode.md
This topic discusses how you can create a custom maintenance page to display to users while your Magento application is being upgraded. Creating a custom page is optional but recommended because your site is accessible during part of the upgrade.
-Creating a custom page to which to redirect users prevents any access to the site and also informs your users that the site is undergoing maintenance.
+Creating a custom page to which to {% glossarytooltip 510de766-1ebd-4546-bf38-c618c9c945d2 %}redirect{% endglossarytooltip %} users prevents any access to the site and also informs your users that the site is undergoing maintenance.
You must perform the tasks in this section as a user with root privileges.
@@ -99,7 +99,7 @@ This section discusses how to create a custom maintenance page and how to redire
To redirect traffic to a custom maintenance page:
-1. Use a text editor to open the nginx configuration file that contains your server block.
+1. Use a text editor to open the {% glossarytooltip b14ef3d8-51fd-48fe-94df-ed069afb2cdc %}nginx{% endglossarytooltip %} configuration file that contains your server block.
2. Add the following to the server block (`server` is shown for clarity only; don't add a second server block).
The following whitelists IP address 192.0.2.110 and 192.0.2.115 on a system where Magento is installed in `/var/www/html/magento2`:
diff --git a/guides/v2.0/comp-mgr/trouble/cman/out-of-memory.md b/guides/v2.0/comp-mgr/trouble/cman/out-of-memory.md
index 1ac1f13ad0c..283602244d6 100644
--- a/guides/v2.0/comp-mgr/trouble/cman/out-of-memory.md
+++ b/guides/v2.0/comp-mgr/trouble/cman/out-of-memory.md
@@ -22,7 +22,7 @@ When installing or updating the Magento application or components like extension
The error `proc_open(): fork failed - Cannot allocate memory` can also display on the command line.
### Description
-We recommend you allocate 2GB of memory to PHP to make sure your installation or upgrade succeeds. The error might mean you have exhausted the physical memory in your machine and your system has no swap file available. At minimum, we recommend you have at least 2GB of RAM and an enabled swap file.
+We recommend you allocate 2GB of memory to {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} to make sure your installation or upgrade succeeds. The error might mean you have exhausted the physical memory in your machine and your system has no swap file available. At minimum, we recommend you have at least 2GB of RAM and an enabled swap file.
### Solution
First, make sure you allocated [2GB of memory to PHP]({{ page.baseurl }}install-gde/prereq/php-settings.html); otherwise, your installation or upgrade might still run out of memory.
diff --git a/guides/v2.0/comp-mgr/trouble/cman/were-sorry.md b/guides/v2.0/comp-mgr/trouble/cman/were-sorry.md
index a2dc3723d80..a24c63cf588 100644
--- a/guides/v2.0/comp-mgr/trouble/cman/were-sorry.md
+++ b/guides/v2.0/comp-mgr/trouble/cman/were-sorry.md
@@ -21,10 +21,10 @@ See one of the following sections for possible solutions:
* [Problem: you cloned the Magento GitHub repository](#git-clone)
### Problem: you're not authenticated {#not-auth}
-You might not have entered your authentication keys in the Magento Admin.
+You might not have entered your authentication keys in the {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %}.
#### Solution
-Enter your authentication keys in the Admin. Try your upgrade again.
+Enter your authentication keys in the {% glossarytooltip 29ddb393-ca22-4df9-a8d4-0024d75739b1 %}Admin{% endglossarytooltip %}. Try your upgrade again.
If that doesn't work, try generating new authentication keys and enter those in the Admin. Then try your upgrade again.
diff --git a/guides/v2.0/comp-mgr/updater/update-updater.md b/guides/v2.0/comp-mgr/updater/update-updater.md
index 517dcd7bfd2..a5e5fbe887b 100644
--- a/guides/v2.0/comp-mgr/updater/update-updater.md
+++ b/guides/v2.0/comp-mgr/updater/update-updater.md
@@ -24,4 +24,4 @@ To update the updater application:
composer create-project magento/updater update --repository https://repo.magento.com
4. If prompted, enter your Magento [authentication keys]({{page.baseurl}}install-gde/prereq/connect-auth.html).
-5. Wait while Composer installs the updater and its dependencies.
+5. Wait while {% glossarytooltip d85e2d0a-221f-4d03-aa43-0cda9f50809e %}Composer{% endglossarytooltip %} installs the updater and its dependencies.
diff --git a/guides/v2.0/comp-mgr/upgrader/ce-ee-upgrade-start.md b/guides/v2.0/comp-mgr/upgrader/ce-ee-upgrade-start.md
index 1c960185b70..f6c3adf58cf 100644
--- a/guides/v2.0/comp-mgr/upgrader/ce-ee-upgrade-start.md
+++ b/guides/v2.0/comp-mgr/upgrader/ce-ee-upgrade-start.md
@@ -20,7 +20,7 @@ This section discusses how to upgrade Magento CE to Magento EE.
-Specify an associative array where keys are constants from \Magento\App\Filesystem\DirectoryList and values are absolute paths of directories or their URL paths, respectively.
+Specify an associative array where keys are constants from \Magento\App\Filesystem\DirectoryList and values are absolute paths of directories or their {% glossarytooltip a05c59d3-77b9-47d0-92a1-2cbffe3f8622 %}URL{% endglossarytooltip %} paths, respectively.
You can set `MAGE_DIRS` in any of the following ways:
diff --git a/guides/v2.0/config-guide/bootstrap/magento-bootstrap.md b/guides/v2.0/config-guide/bootstrap/magento-bootstrap.md
index 3cb2ce7b599..ce69d9c0690 100644
--- a/guides/v2.0/config-guide/bootstrap/magento-bootstrap.md
+++ b/guides/v2.0/config-guide/bootstrap/magento-bootstrap.md
@@ -57,7 +57,7 @@ $bootstrap->run($app);
Default exception handling
The bootstrap object specifies how the Magento application handles uncaught exceptions as follows:
-* In developer mode, displays the exception as-is.
+* In developer mode, displays the {% glossarytooltip 53da11f1-d0b8-4a7e-b078-1e099462b409 %}exception{% endglossarytooltip %} as-is.
* In any other mode, attempts to log exception and display a generic error message.
* Terminates Magento with error code `1`
@@ -93,7 +93,7 @@ We have the following entry point applications (that is, applications defined by
In default or developer mode, a request for a non-existent static resource is redirected to the static entry point according to the rewrite rules specified by the appropriate `.htaccess`.
-When the request is redirected to the entry point, the Magento application parses the requested URL based on retrieved parameters and finds the requested resource.
+When the request is redirected to the entry point, the Magento application parses the requested {% glossarytooltip a05c59d3-77b9-47d0-92a1-2cbffe3f8622 %}URL{% endglossarytooltip %} based on retrieved parameters and finds the requested resource.
* In developer mode, the content of the file is returned so that every time the resource is requested, the returned content is up to date.
* In default mode, the retrieved resource is published so it is accessible by the previously requested URL.
@@ -101,7 +101,7 @@ When the request is redirected to the entry point, the Magento application parse
All future requests for the static resource are processed by the server the same as static files; that is, without involving the entry point. If it's necessary to synchronize published files with original ones, the `pub/static` directory should be removed; as a result, files are automatically republished with the next request.
Media resource entry point
-Magento\MediaStorage\App\Media retrieves media resources (that is, any files uploaded to media storage) from the database. It is used whenever the database is configured as a media storage.
+Magento\MediaStorage\App\Media retrieves media resources (that is, any files uploaded to media storage) from the database. It is used whenever the database is configured as a {% glossarytooltip d95142d7-023f-451c-a2e9-dd88763dcd70 %}media storage{% endglossarytooltip %}.
`\Magento\Core\App\Media` attempts to find the media file in the configured database storage and write it into the `pub/static` directory, then return its contents. On error, it returns an HTTP 404 (Not Found) status code in the header with no contents.
diff --git a/guides/v2.0/config-guide/bootstrap/magento-how-to-set.md b/guides/v2.0/config-guide/bootstrap/magento-how-to-set.md
index 0a81ad36f7d..48abd777e3f 100644
--- a/guides/v2.0/config-guide/bootstrap/magento-how-to-set.md
+++ b/guides/v2.0/config-guide/bootstrap/magento-how-to-set.md
@@ -61,11 +61,11 @@ bash shell example for CentOS:
-
If a PHP Fatal error displays in the browser after you set a profiler value, restart your web server. The reason might be related to PHP bytecode caching, which caches bytecodes and PHP classpaths.
+
If a PHP Fatal error displays in the browser after you set a profiler value, restart your web server. The reason might be related to {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} bytecode caching, which caches bytecodes and PHP classpaths.
Specifying a parameter value
-This section discusses how to specify the mode for either Apache or nginx.
+This section discusses how to specify the mode for either Apache or {% glossarytooltip b14ef3d8-51fd-48fe-94df-ed069afb2cdc %}nginx{% endglossarytooltip %}.
See one of the following sections for more information:
diff --git a/guides/v2.0/config-guide/bootstrap/magento-modes.md b/guides/v2.0/config-guide/bootstrap/magento-modes.md
index f86995790f6..1b178418a01 100644
--- a/guides/v2.0/config-guide/bootstrap/magento-modes.md
+++ b/guides/v2.0/config-guide/bootstrap/magento-modes.md
@@ -57,7 +57,7 @@ In default mode:
* Errors are logged to the file reports at server, and never shown to a user
* A symlink to a static view file is published to the `pub/static` directory for each requested file
-* Default mode is not optimized for a production environment, primarily because of the adverse performance impact of static files being dynamically generated rather than [materialized](https://en.wikipedia.org/wiki/Materialized_view){:target="_blank"}. In other words, creating static files and caching them has a greater performance impact than generating them using the static files creation tool.
+* Default mode is not optimized for a production environment, primarily because of the adverse performance impact of {% glossarytooltip 363662cb-73f1-4347-a15e-2d2adabeb0c2 %}static files{% endglossarytooltip %} being dynamically generated rather than [materialized](https://en.wikipedia.org/wiki/Materialized_view){:target="_blank"}. In other words, creating static files and caching them has a greater performance impact than generating them using the static files creation tool.
For more information, see Set the Magento mode.
@@ -69,8 +69,8 @@ In developer mode:
* A symlink to a static view file is published to the `pub/static` directory for each requested file
* Uncaught exceptions display in the browser
* System logging in `var/report` is verbose
-* An exception is thrown in the error handler, rather than being logged
-* An exception is thrown when an event subscriber cannot be invoked
+* An {% glossarytooltip 53da11f1-d0b8-4a7e-b078-1e099462b409 %}exception{% endglossarytooltip %} is thrown in the error handler, rather than being logged
+* An exception is thrown when an {% glossarytooltip c57aef7c-97b4-4b2b-a999-8001accef1fe %}event{% endglossarytooltip %} subscriber cannot be invoked
For more information, see Set the Magento mode.
@@ -81,7 +81,7 @@ This improves performance because static files don't go through the fallback mec
In production mode:
-* Static view files are not materialized, and URLs for them are composed on the fly without going through the fallback mechanism. (Static view files are served from cache only.)
+* Static view files are not materialized, and URLs for them are composed on the fly without going through the fallback mechanism. (Static view files are served from {% glossarytooltip 0bc9c8bc-de1a-4a06-9c99-a89a29c30645 %}cache{% endglossarytooltip %} only.)
* Errors are logged to the file system and are never displayed to the user
#### Next step
diff --git a/guides/v2.0/config-guide/cache/cache-priv-context.md b/guides/v2.0/config-guide/cache/cache-priv-context.md
index 5f51fc97fb2..2133434698d 100644
--- a/guides/v2.0/config-guide/cache/cache-priv-context.md
+++ b/guides/v2.0/config-guide/cache/cache-priv-context.md
@@ -12,7 +12,7 @@ version: 2.0
github_link: config-guide/cache/cache-priv-context.md
---
-Caching servers and proxies usually use a URL as the caching identifier; however, Magento URLs are not unique *enough* to allow caching by URL only. (We can cache the customer group, selected language, whether the customer logged in or not, and so on).
+Caching servers and proxies usually use a {% glossarytooltip a05c59d3-77b9-47d0-92a1-2cbffe3f8622 %}URL{% endglossarytooltip %} as the caching identifier; however, Magento URLs are not unique *enough* to allow caching by URL only. (We can {% glossarytooltip 0bc9c8bc-de1a-4a06-9c99-a89a29c30645 %}cache{% endglossarytooltip %} the customer group, selected language, whether the customer logged in or not, and so on).
To make each cached URL totally unique, we use *HTTP context variables*. Context variables enable the Magento application to serve different content on the same URL based on customer group, selected language, whether customer logged in or not, and so on.
diff --git a/guides/v2.0/config-guide/cache/cache-priv-inval.md b/guides/v2.0/config-guide/cache/cache-priv-inval.md
index 7f79df160dc..280ccd20727 100644
--- a/guides/v2.0/config-guide/cache/cache-priv-inval.md
+++ b/guides/v2.0/config-guide/cache/cache-priv-inval.md
@@ -13,11 +13,11 @@ github_link: config-guide/cache/cache-priv-inval.md
---
## Cache invalidation {#config-cache-inval}
-The Magento application enables you to clear cached content immediately after a entity changes. We use an `IdentityInterface` to link entities in the application with cached content and to know what cache to clear when an entity changes.
+The Magento application enables you to clear cached content immediately after a entity changes. We use an `IdentityInterface` to link entities in the application with cached content and to know what {% glossarytooltip 0bc9c8bc-de1a-4a06-9c99-a89a29c30645 %}cache{% endglossarytooltip %} to clear when an {% glossarytooltip a9027f5d-efab-4662-96aa-c2999b5ab259 %}entity{% endglossarytooltip %} changes.
This section discusses how you inform the Magento application what cache to clear when you change an entity.
-First, your entity module must implement [`Magento/Framework/DataObject/IdentityInterface`]({{ site.mage2000url }}lib/internal/Magento/Framework/DataObject/IdentityInterface.php){:target="_blank"} as follows:
+First, your entity {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} must implement [`Magento/Framework/DataObject/IdentityInterface`]({{ site.mage2000url }}lib/internal/Magento/Framework/DataObject/IdentityInterface.php){:target="_blank"} as follows:
{% highlight php startinline=true %}
use Magento\Framework\DataObject\IdentityInterface;
@@ -70,7 +70,7 @@ Versioning works as follows:
1. The user performs some action, such as adding to a cart, that results in an POST or PUT request to the Magento application.
2. The server generates the `private_content_version` cookie for this user and returns the response to the browser.
-3. JavaScript interprets the presence of the `private_content_version` cookie to mean that private content is present on the page, so it sends an AJAX request to the Magento server to get the current private content.
+3. {% glossarytooltip 312b4baf-15f7-4968-944e-c814d53de218 %}JavaScript{% endglossarytooltip %} interprets the presence of the `private_content_version` cookie to mean that private content is present on the page, so it sends an AJAX request to the Magento server to get the current private content.
4. The server's reply is cached in the browser's local storage.
Subsequent requests with the same data version are retrieved from local storage.
diff --git a/guides/v2.0/config-guide/cache/cache-priv-over.md b/guides/v2.0/config-guide/cache/cache-priv-over.md
index 99d35f9e692..c17a1d082e7 100644
--- a/guides/v2.0/config-guide/cache/cache-priv-over.md
+++ b/guides/v2.0/config-guide/cache/cache-priv-over.md
@@ -14,7 +14,7 @@ github_link: config-guide/cache/cache-priv-over.md
Caching one of the most effective way of improving performance of web applications of all kinds. Generally speaking, there are two ways to cache: client-side (browser) and server-side. In addition, there are two types of content: public (available to multiple customers) and private (specific to one customer).
-Magento page caching is synonymous with *full-page caching*; in other words, we cache the entire page. The Magento application gives you the following options:
+Magento page caching is synonymous with *full-page caching*; in other words, we {% glossarytooltip 0bc9c8bc-de1a-4a06-9c99-a89a29c30645 %}cache{% endglossarytooltip %} the entire page. The Magento application gives you the following options:
* The default caching mechanism which stores cache files in any of the following:
@@ -26,11 +26,11 @@ Magento page caching is synonymous with *full-page caching*; in other words, we
* [Varnish]({{ page.baseurl }}config-guide/varnish/config-varnish.html) (recommended)
### Cacheable and uncacheable pages {#config-cache-over-cacheable}
-*Cacheable* and *uncacheable* are terms we use to indicate whether or not a page should be cached at all. (By default, all pages are cacheable.) If any block in a layout is designated as uncacheable, the entire page is uncacheable.
+*Cacheable* and *uncacheable* are terms we use to indicate whether or not a page should be cached at all. (By default, all pages are cacheable.) If any block in a {% glossarytooltip 73ab5daa-5857-4039-97df-11269b626134 %}layout{% endglossarytooltip %} is designated as uncacheable, the entire page is uncacheable.
To create an uncacheable page, mark any block on that page as uncacheable in the layout using `cacheable="false"`.
-Examples of uncacheable pages include the compare products, cart, checkout pages, and so on.
+Examples of uncacheable pages include the compare products, cart, {% glossarytooltip 278c3ce0-cd4c-4ffc-a098-695d94d73bde %}checkout{% endglossarytooltip %} pages, and so on.
[Example]({{ site.mage2000url }}app/code/Magento/Paypal/view/frontend/layout/paypal_payflow_returnurl.xml){:target="_blank"}
diff --git a/guides/v2.0/config-guide/cache/cache-priv-priv.md b/guides/v2.0/config-guide/cache/cache-priv-priv.md
index e0ad85fc433..1cc5b9d1627 100644
--- a/guides/v2.0/config-guide/cache/cache-priv-priv.md
+++ b/guides/v2.0/config-guide/cache/cache-priv-priv.md
@@ -12,7 +12,7 @@ version: 2.0
github_link: config-guide/cache/cache-priv-priv.md
---
-The Magento page cache stores *entire* cacheable pages; where pages are stored depends on whether the content is private or public. These terms are defined as follows:
+The Magento page {% glossarytooltip 0bc9c8bc-de1a-4a06-9c99-a89a29c30645 %}cache{% endglossarytooltip %} stores *entire* cacheable pages; where pages are stored depends on whether the content is private or public. These terms are defined as follows:
* *Public*, which can display to many customers.
@@ -36,7 +36,7 @@ The public method `getSectionData` must return an array with data for private bl
[Example]({{ site.mage2000url }}app/code/Magento/Catalog/CustomerData/CompareProducts.php#L36-L45){:target="_blank"}
-Add the following to your component's dependency injection configuration (`di.xml`):
+Add the following to your component's {% glossarytooltip 2be50595-c5c7-4b9d-911c-3bf2cd3f7beb %}dependency injection{% endglossarytooltip %} configuration (`di.xml`):
{% highlight xml %}
@@ -49,13 +49,13 @@ Add the following to your component's dependency injection configuration (`di.xm
{% endhighlight %}
### Step 2: Create a block and template {#config-cache-priv-how-block}
-To render private content, create a block and a template to display user-agnostic data; this data is replaced with user-specific data by the UI component.
+To render private content, create a block and a template to display user-agnostic data; this data is replaced with user-specific data by the {% glossarytooltip 9bcc648c-bd08-4feb-906d-1e24c4f2f422 %}UI component{% endglossarytooltip %}.
Do not use the $_isScopePrivate property in your blocks. This property is obsolete and won't work properly.
-Replace private data in blocks with placeholders (using [Knockout](http://knockoutjs.com/documentation/introduction.html){:target="_blank"} syntax). The init scope on the root element is `data-bind="scope: 'compareProducts'"`, where you define the scope name (`compareProducts` in this example) in your layout.
+Replace private data in blocks with placeholders (using [Knockout](http://knockoutjs.com/documentation/introduction.html){:target="_blank"} syntax). The init scope on the root element is `data-bind="scope: 'compareProducts'"`, where you define the scope name (`compareProducts` in this example) in your {% glossarytooltip 73ab5daa-5857-4039-97df-11269b626134 %}layout{% endglossarytooltip %}.
Initialize the component as follows:
@@ -68,7 +68,7 @@ Initialize the component as follows:
[Example]({{ site.mage2000url }}app/code/Magento/Catalog/view/frontend/templates/product/compare/sidebar.phtml#L46-L48){:target="_blank"}
### Step 3: Configure a UI component {#config-cache-priv-how-ui}
-The UI component renders block data on the Magento storefront. To initialize the UI component, you must call the initialization method `_super()`.
+The UI component renders block data on the Magento {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %}. To initialize the UI component, you must call the initialization method `_super()`.
[Example]({{ site.mage2000url }}app/code/Magento/Catalog/view/frontend/web/js/view/compare-products.js){:target="_blank"}
diff --git a/guides/v2.0/config-guide/cache/caching-cache-type.md b/guides/v2.0/config-guide/cache/caching-cache-type.md
index 5e858408c25..8e98403f9e3 100644
--- a/guides/v2.0/config-guide/cache/caching-cache-type.md
+++ b/guides/v2.0/config-guide/cache/caching-cache-type.md
@@ -10,29 +10,40 @@ level3_menu_node: level3child
level3_subgroup: cache-types
version: 2.0
github_link: config-guide/cache/caching-cache-type.md
-redirect_from: /guides/v2.0/config-guide/cache/caching-cache-type.html
---
-A *cache type* enables you to specify what is cached and enables merchants to clear that cache type using the Cache Management page in the Magento Admin.
+A *cache type* enables you to specify what is cached and enables merchants to clear that {% glossarytooltip 65f9a5a1-79ee-4f27-aac7-29abe24db40d %}cache type{% endglossarytooltip %} using the {% glossarytooltip 0bc9c8bc-de1a-4a06-9c99-a89a29c30645 %}Cache{% endglossarytooltip %} Management page in the {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %}.
The tag *scope* provides a mechanism for a cache type.
To create a new cache type:
-
+{% highlight php startinline %}
+class %Namespace%_%Module%_Model_Cache_Type extends \Magento\Cache\Frontend\Decorator\TagScope
+{
+ public function __construct(\Magento\App\Cache\Type\FrontendPool $cacheFrontendPool)
+ {
+ parent::__construct($cacheFrontendPool->get('%cache_type_id%'), '%cache_type_tag%');
+ }
+}
+{% endhighlight %}
You must specify the following parameters:
-* `Namespace_Module` defines the name of a module that uses a cache type. A module can use several cache types and a cache type can be used in several modules.
+* `Namespace_Module` defines the name of a {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} that uses a cache type. A module can use several cache types and a cache type can be used in several modules.
* `%cache_type_id%` defines unique identifier of a cache type.
* `%cache_type_tag%` defines unique tag to be used in the cache type scoping.
-
More information about caching
-You can get more information about caching by looking at the code. We suggest you locate classes that extend Magento\Framework\Cache\Frontend\Decorator\TagScope.
+## More information about caching
-For example, look at Magento\Eav\Model\Cache\Type to understand more about the EAV cache type.
+You can get more information about caching by looking at the code.
+We suggest you locate classes that extend [Magento\Framework\Cache\Frontend\Decorator\TagScope][tagscope].
+
+For example, look at [Magento\Eav\Model\Cache\Type][type] to understand more about the EAV cache type.
Please help us improve this topic by suggesting details using the Edit this page in GitHub link at the top of the page.
+[tagscope]: {{ site.mage2000url }}lib/internal/Magento/Framework/Cache/Frontend/Decorator/TagScope.php
+[type]: {{ site.mage2000url }}app/code/Magento/Eav/Model/Cache/Type.php
diff --git a/guides/v2.0/config-guide/cache/caching-database.md b/guides/v2.0/config-guide/cache/caching-database.md
index 1106672a26d..97dfba478fc 100644
--- a/guides/v2.0/config-guide/cache/caching-database.md
+++ b/guides/v2.0/config-guide/cache/caching-database.md
@@ -21,7 +21,7 @@ This topic discusses how to use the Magento 2 database for caching. After you co
This topic discusses how to set up database caching and how to verify database caching is working. We discuss the following options:
* Using the `default` cache frontend, in which case you modify `di.xml` only.
-* Using a custom cache frontend, in which case you modify `env.php` only.
+* Using a custom {% glossarytooltip 0bc9c8bc-de1a-4a06-9c99-a89a29c30645 %}cache{% endglossarytooltip %} frontend, in which case you modify `env.php` only.
Database caching—like file-based caching— works well in a development environment but we strongly recommend you use Varnish in production instead.
@@ -29,7 +29,7 @@ This topic discusses how to set up database caching and how to verify database c
Prerequisites
-Before you continue, if you're using your own frontend cache, make sure you associate cache frontends with cache types. If you're using the `default` frontend cache, you don't have to do that.
+Before you continue, if you're using your own frontend cache, make sure you associate cache frontends with cache types. If you're using the `default` {% glossarytooltip b00459e5-a793-44dd-98d5-852ab33fc344 %}frontend{% endglossarytooltip %} cache, you don't have to do that.
We provide sample configurations at the end of this topic.
@@ -98,7 +98,7 @@ To modify `di.xml`:
7. Continue with Verify database caching is working.
Database caching using a custom cache frontend
-This section discusses how to set up database caching with a custom cache frontend.
+This section discusses how to set up database caching with a custom {% glossarytooltip ca5ad9ac-9d39-45b5-80b1-e90d192f20d0 %}cache frontend{% endglossarytooltip %}.
@@ -148,7 +148,7 @@ Use the following steps:
rm -rf /var/cache/* /var/page_cache/* /var/di/* /var/generation/*
-3. In a web browser, go to any cacheable page (such as the storefront front door page).
+3. In a web browser, go to any cacheable page (such as the {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %} front door page).
If exceptions display, verify `di.xml` syntax and try again. (To see exceptions in the browser, you must enable developer mode.)
4. Enter the following commands:
diff --git a/guides/v2.0/config-guide/cache/caching.md b/guides/v2.0/config-guide/cache/caching.md
index ad3b920bc37..9cd65e8b2bb 100644
--- a/guides/v2.0/config-guide/cache/caching.md
+++ b/guides/v2.0/config-guide/cache/caching.md
@@ -14,7 +14,7 @@ redirect_from:
---
Overview of caching
-Magento uses Zend_Cache to interact with the cache storage. However, Magento also has the Magento\Cache library for implementing Magento-specific caching. These topics discuss how to configure caching and cache types.
+Magento uses Zend_Cache to interact with the cache storage. However, Magento also has the Magento\Cache {% glossarytooltip 08968dbb-2eeb-45c7-ae95-ffca228a7575 %}library{% endglossarytooltip %} for implementing Magento-specific caching. These topics discuss how to configure caching and {% glossarytooltip 0bc9c8bc-de1a-4a06-9c99-a89a29c30645 %}cache{% endglossarytooltip %} types.
By default, file system caching is enabled; no configuration is necessary to use it. This means the cache is located under <your Magento install dir>/var.
Magento enables you to configure alternatives to the default file system caching. This guide discusses some of those alternatives; namely,
-* Set up the following cache mechanisms in the Magento configuration:
+* Set up the following {% glossarytooltip 0bc9c8bc-de1a-4a06-9c99-a89a29c30645 %}cache{% endglossarytooltip %} mechanisms in the Magento configuration:
* Database
* Redis
@@ -41,7 +41,7 @@ Magento uses the following caching terminology:
This topic discusses the following options for configuring caching:
-* Modifying the provided `default` cache frontend, which means you modify only `/app/etc/di.xml` (the Magento application's global dependency injection configuration)
+* Modifying the provided `default` cache frontend, which means you modify only `/app/etc/di.xml` (the Magento application's global {% glossarytooltip 2be50595-c5c7-4b9d-911c-3bf2cd3f7beb %}dependency injection{% endglossarytooltip %} configuration)
* Configuring your own custom cache frontend, which means you modify only `/app/etc/env.php` because it overrides the equivalent configuration in `di.xml`
@@ -49,7 +49,7 @@ This topic discusses the following options for configuring caching:
Step 1: Define a cache frontend
-The Magento application has a `default` cache frontend you can use for any cache type. This section discusses how to optionally define a cache frontend with a different name, which is preferable if you expect to customize your frontend.
+The Magento application has a `default` cache {% glossarytooltip b00459e5-a793-44dd-98d5-852ab33fc344 %}frontend{% endglossarytooltip %} you can use for any cache type. This section discusses how to optionally define a {% glossarytooltip ca5ad9ac-9d39-45b5-80b1-e90d192f20d0 %}cache frontend{% endglossarytooltip %} with a different name, which is preferable if you expect to customize your frontend.
To use the default cache type, you don't need to modify env.php at all; you modify Magento's global di.xml. See the topics referenced in Low-level cache options.
@@ -82,7 +82,7 @@ The following example shows how to define it in `env.php` (which overrides `di.x
where `` is a unique name to identify your frontend and `` are options discussed in the topics specific to each type of caching (database, Redis, and so on).
Step 2: Configure the cache
-You can specify frontend and backend cache configuration options in `env.php` or `di.xml`. This task is optional.
+You can specify frontend and {% glossarytooltip 74d6d228-34bd-4475-a6f8-0c0f4d6d0d61 %}backend{% endglossarytooltip %} cache configuration options in `env.php` or `di.xml`. This task is optional.
`env.php` example:
@@ -101,7 +101,7 @@ You can specify frontend and backend cache configuration options in `env.php` or
where
-* `` is the low-level frontend cache type. Specify the name of a class that is compatible with Zend_Cache_Core.
+* `` is the low-level frontend {% glossarytooltip 65f9a5a1-79ee-4f27-aac7-29abe24db40d %}cache type{% endglossarytooltip %}. Specify the name of a class that is compatible with Zend_Cache_Core.
If you omit ``, Magento\Framework\Cache\Core is used.
* ``, `` are the name and value of options the Magento framework passes as an associative array to the frontend cache upon its creation.
diff --git a/guides/v2.0/config-guide/cache/caching_low-level.md b/guides/v2.0/config-guide/cache/caching_low-level.md
index 60a726b0abe..0679ffff618 100644
--- a/guides/v2.0/config-guide/cache/caching_low-level.md
+++ b/guides/v2.0/config-guide/cache/caching_low-level.md
@@ -13,7 +13,7 @@ github_link: config-guide/cache/caching_low-level.md
redirect_from: /guides/v2.0/config-guide/cache/caching_low-level.html
---
-The Magento application uses a low-level cache frontend and backend to provide access to the cache storage.
+The Magento application uses a low-level {% glossarytooltip 0bc9c8bc-de1a-4a06-9c99-a89a29c30645 %}cache{% endglossarytooltip %} {% glossarytooltip b00459e5-a793-44dd-98d5-852ab33fc344 %}frontend{% endglossarytooltip %} and {% glossarytooltip 74d6d228-34bd-4475-a6f8-0c0f4d6d0d61 %}backend{% endglossarytooltip %} to provide access to the cache storage.
Low-level frontend cache
Magento extends Zend_Cache_Core by implementing Magento\Framework\Cache\Core frontend cache.
@@ -25,7 +25,7 @@ In general, the Magento application works with any backend cache that Database
* File system (default): No configuration is necessary to use file system caching.
-Varnish doesn't require setting up a low-level cache backend.
+Varnish doesn't require setting up a low-level {% glossarytooltip 8f2067d1-4a39-4ed2-916d-7c9c58ccf30c %}cache backend{% endglossarytooltip %}.
We'll periodically add more low-level cache types so watch this space.
-Magento 2 has the following cache types:
+Magento 2 has the following {% glossarytooltip 0bc9c8bc-de1a-4a06-9c99-a89a29c30645 %}cache{% endglossarytooltip %} types:
@@ -154,7 +154,7 @@ Sample result:
-
Enabling a cache type automatically clears that cache type.
+
Enabling a {% glossarytooltip 65f9a5a1-79ee-4f27-aac7-29abe24db40d %}cache type{% endglossarytooltip %} automatically clears that cache type.
Clean and flush cache types
@@ -198,7 +198,7 @@ Sample result:
-
You can also clean and flush cache types in the Magento Admin. Go to System > Tools > Cache Management. Flush Cache Storage is equivalent to magento cache:flush. Flush Magento Cache is equivalent to magento cache:clean.
+
You can also clean and flush cache types in the {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %}. Go to System > Tools > Cache Management. Flush Cache Storage is equivalent to magento cache:flush. Flush Magento Cache is equivalent to magento cache:clean.
#### Related topics
diff --git a/guides/v2.0/config-guide/cli/config-cli-subcommands-compiler.md b/guides/v2.0/config-guide/cli/config-cli-subcommands-compiler.md
index 093570f81b9..bbd71dba02e 100644
--- a/guides/v2.0/config-guide/cli/config-cli-subcommands-compiler.md
+++ b/guides/v2.0/config-guide/cli/config-cli-subcommands-compiler.md
@@ -18,12 +18,12 @@ redirect_from:
This section discusses the basics of code compilation.
Code compilation consists of all of the following in no particular order:
Application code generation (factories, proxies, and so on)
-
Area configuration aggregation (that is, optimized dependency injection configurations per area)
+
Area configuration aggregation (that is, optimized {% glossarytooltip 2be50595-c5c7-4b9d-911c-3bf2cd3f7beb %}dependency injection{% endglossarytooltip %} configurations per area)
Interceptor generation (that is, optimized code generation of interceptors)
Service data attributes generation (that is, generated {% glossarytooltip 55774db9-bf9d-40f3-83db-b10cc5ae3b68 %}extension{% endglossarytooltip %} classes for data objects)
+
You can find code compilation in classes in the \Magento\Setup\Module\Di\App\Task\Operation {% glossarytooltip 621ef86b-7314-4fbc-a80d-ab7fa45a27cb %}namespace{% endglossarytooltip %}.
First steps
{% include install/first-steps-cli.html %}
@@ -48,7 +48,7 @@ Use this command if you have multiple *tenants*, which means more than one indep
* There is one Magento 2 code base instance
* There is one database instance per tenant
-* Independent configurations in the Magento Admin per tenant
+* Independent configurations in the {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %} per tenant
* The storefronts are independent of each other
If you do not have multiple tenants, use the single-tenant compiler instead.
diff --git a/guides/v2.0/config-guide/cli/config-cli-subcommands-depen.md b/guides/v2.0/config-guide/cli/config-cli-subcommands-depen.md
index 834257422e7..cf0ce7c207b 100644
--- a/guides/v2.0/config-guide/cli/config-cli-subcommands-depen.md
+++ b/guides/v2.0/config-guide/cli/config-cli-subcommands-depen.md
@@ -14,7 +14,7 @@ redirect_from: /guides/v1.0/config-guide/cli/config-cli-subcommands-depen.html
Overview of dependency reports
You can run the following types of reports:
-* Module dependencies: Shows the total number of dependencies between modules and whether the dependencies are hard or soft
+* {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}Module{% endglossarytooltip %} dependencies: Shows the total number of dependencies between modules and whether the dependencies are hard or soft
* Circular dependencies: Shows the total number of dependency chains and the number and list of circular dependencies for each module
* Framework dependencies: Shows the total number of dependencies on the Magento framework by module (including the total number of framework entries for each library)
diff --git a/guides/v2.0/config-guide/cli/config-cli-subcommands-i18n.md b/guides/v2.0/config-guide/cli/config-cli-subcommands-i18n.md
index 7485aa70d92..59ae9833232 100644
--- a/guides/v2.0/config-guide/cli/config-cli-subcommands-i18n.md
+++ b/guides/v2.0/config-guide/cli/config-cli-subcommands-i18n.md
@@ -16,7 +16,7 @@ Magento translations enable you to customize and localize your store for multipl
This topic discusses how to generate:
-* Translation dictionaries, which are a convenient way to translate *some* words and phrases, such as those for a custom module or theme.
+* Translation dictionaries, which are a convenient way to translate *some* words and phrases, such as those for a custom {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} or {% glossarytooltip d2093e4a-2b71-48a3-99b7-b32af7158019 %}theme{% endglossarytooltip %}.
* Language packages, which enable you to translate *any or all* words and phrases in the Magento application.
For more information, see Translation.
@@ -26,7 +26,7 @@ For more information, see Common arguments.
Generate a translation dictionary
-You can generate a translation dictionary to use by itself (for example, to translate words and phrases in a custom module) or for use by a language package. See one of the following sections:
+You can generate a translation dictionary to use by itself (for example, to translate words and phrases in a custom module) or for use by a {% glossarytooltip 9c4c7b9b-43f0-4454-8e8c-fb62ad40c35f %}language package{% endglossarytooltip %}. See one of the following sections:
* About translation dictionaries
* Work with translation dictionaries
@@ -201,7 +201,7 @@ To create these files:
Language package language.xml
When declaring a language package in the `language.xml` configuration file, you must specify the sequence of the language inheritance for this package.
-Language inheritance enables you to create a new translation based on an existing one (the existing translation is referred to as the _parent_). The child translations override the parent. However, if the child translation fails to upload or display, the parent is used instead. If some child translation lacks a phrase or a word, this phrase or word is taken from the parent locale. Examples of language package inheritance.
+Language inheritance enables you to create a new translation based on an existing one (the existing translation is referred to as the _parent_). The child translations override the parent. However, if the child translation fails to upload or display, the parent is used instead. If some child translation lacks a phrase or a word, this phrase or word is taken from the parent {% glossarytooltip 05099dbb-d491-4e33-a065-16035cb2d4d9 %}locale{% endglossarytooltip %}. Examples of language package inheritance.
To declare a package, specify the following information:
diff --git a/guides/v2.0/config-guide/cli/config-cli-subcommands-index.md b/guides/v2.0/config-guide/cli/config-cli-subcommands-index.md
index 9b35be40eaf..185dc34068f 100644
--- a/guides/v2.0/config-guide/cli/config-cli-subcommands-index.md
+++ b/guides/v2.0/config-guide/cli/config-cli-subcommands-index.md
@@ -102,7 +102,7 @@ Sample result:
Configure indexers
This command enables you to set the following indexer options:
-* Update on save (`realtime`): Indexed data is updated as soon as a change is made in the Admin. (For example, the category products index is reindex after products are added to a category in the Admin.) This is the default.
+* Update on save (`realtime`): Indexed data is updated as soon as a change is made in the {% glossarytooltip 29ddb393-ca22-4df9-a8d4-0024d75739b1 %}Admin{% endglossarytooltip %}. (For example, the {% glossarytooltip 50e49338-1e6c-4473-8527-9e401d67ea2b %}category{% endglossarytooltip %} products index is reindex after products are added to a category in the Admin.) This is the default.
* Update by schedule (`schedule`): Data is indexed according to the schedule set by your Magento cron job.
[More information about indexing]({{ page.baseurl }}extension-dev-guide/indexing.html)
diff --git a/guides/v2.0/config-guide/cli/config-cli-subcommands-layout-xml.md b/guides/v2.0/config-guide/cli/config-cli-subcommands-layout-xml.md
index 16dac153e73..50da7e69047 100644
--- a/guides/v2.0/config-guide/cli/config-cli-subcommands-layout-xml.md
+++ b/guides/v2.0/config-guide/cli/config-cli-subcommands-layout-xml.md
@@ -13,7 +13,7 @@ redirect_from: /guides/v1.0/config-guide/cli/config-cli-subcommands-layout-xml.h
Overview of layout XML conversion
-This command enables you to update your layout XML files if you update the corresponding Extensible Stylesheet Language Transformations (XSLT) stylesheet.
+This command enables you to update your {% glossarytooltip 73ab5daa-5857-4039-97df-11269b626134 %}layout{% endglossarytooltip %} {% glossarytooltip 8c0645c5-aa6b-4a52-8266-5659a8b9d079 %}XML{% endglossarytooltip %} files if you update the corresponding Extensible Stylesheet Language Transformations (XSLT) stylesheet.
For more information about layout XML files, see:
@@ -32,7 +32,7 @@ Command options:
where
* `{xml file}` is the full path and file name of a layout XML file to convert (required)
-* `{xslt stylesheet}` is the full path and file name of an XSLT stylesheet file to use for conversion (required)
+* `{xslt stylesheet}` is the full path and file name of an XSLT stylesheet file to use for {% glossarytooltip 38c73ce4-8f01-4f74-ab30-1134cec5664f %}conversion{% endglossarytooltip %} (required)
* `-o|--overwrite` include this option to overwrite the existing XML file
#### Related topics
diff --git a/guides/v2.0/config-guide/cli/config-cli-subcommands-mode.md b/guides/v2.0/config-guide/cli/config-cli-subcommands-mode.md
index 68519f5c072..f26ef45f8a5 100644
--- a/guides/v2.0/config-guide/cli/config-cli-subcommands-mode.md
+++ b/guides/v2.0/config-guide/cli/config-cli-subcommands-mode.md
@@ -98,8 +98,8 @@ Following is a summary of messages that display:
New version of deployed files: 1440461332
Static content deployment complete
Gathering css/styles-m.less sources.
-Successfully processed LESS and/or SASS files
-CSS deployment complete
+Successfully processed LESS and/or {% glossarytooltip 45f1f76d-91cd-4789-a8b5-1e3f321a6280 %}SASS{% endglossarytooltip %} files
+{% glossarytooltip 6c5cb4e9-9197-46f2-ba79-6147d9bfe66d %}CSS{% endglossarytooltip %} deployment complete
Generated classes:
Magento\Sales\Api\Data\CreditmemoCommentInterfacePersistor
Magento\Sales\Api\Data\CreditmemoCommentInterfaceFactory
diff --git a/guides/v2.0/config-guide/cli/config-cli-subcommands-perf-data.md b/guides/v2.0/config-guide/cli/config-cli-subcommands-perf-data.md
index b2ea7aba51d..6a3d495df21 100644
--- a/guides/v2.0/config-guide/cli/config-cli-subcommands-perf-data.md
+++ b/guides/v2.0/config-guide/cli/config-cli-subcommands-perf-data.md
@@ -16,7 +16,7 @@ To use the Magento performance toolkit or another tool for performance testing,
You can adjust the amount of data you create using *profiles* (small, medium, large, and extra large). The next section discusses profiles in more detail.
-The following figure shows how a product displays on the storefront using the small profile:
+The following figure shows how a product displays on the {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %} using the small profile:
{:width="550px"}
diff --git a/guides/v2.0/config-guide/cli/config-cli-subcommands-spt-util.md b/guides/v2.0/config-guide/cli/config-cli-subcommands-spt-util.md
index 4c165940d72..790ff399857 100644
--- a/guides/v2.0/config-guide/cli/config-cli-subcommands-spt-util.md
+++ b/guides/v2.0/config-guide/cli/config-cli-subcommands-spt-util.md
@@ -82,7 +82,7 @@ After the command completes, provide the database backup to Magento Support.
{% include install/sens-data.md %}
## Troubleshooting: display utilities and paths {#config-cli-spt-utils-trouble}
-We provide commands that display paths to utilities required by the Data Collector and the command line. You can use these commands, for example, if errors like the following display in the Admin or on the command line:
+We provide commands that display paths to utilities required by the Data Collector and the command line. You can use these commands, for example, if errors like the following display in the {% glossarytooltip 29ddb393-ca22-4df9-a8d4-0024d75739b1 %}Admin{% endglossarytooltip %} or on the command line:
Utility lsof not found
diff --git a/guides/v2.0/config-guide/cli/config-cli-subcommands-static-view.md b/guides/v2.0/config-guide/cli/config-cli-subcommands-static-view.md
index 9faafee2649..4762fd67d06 100644
--- a/guides/v2.0/config-guide/cli/config-cli-subcommands-static-view.md
+++ b/guides/v2.0/config-guide/cli/config-cli-subcommands-static-view.md
@@ -12,11 +12,11 @@ redirect_from: /guides/v1.0/config-guide/cli/config-cli-subcommands-static-view.
---
Overview of static view files deployment
-The static view files deployment command enables you to write static files to the Magento file system when the Magento software is set for production mode.
+The static view files deployment command enables you to write {% glossarytooltip 363662cb-73f1-4347-a15e-2d2adabeb0c2 %}static files{% endglossarytooltip %} to the Magento file system when the Magento software is set for production mode.
The term *static view file* refers to the following:
-* "Static" means it can be cached for a site (that is, the file is not dynamically generated). Examples include images and CSS generated from LESS.
+* "Static" means it can be cached for a site (that is, the file is not dynamically generated). Examples include images and {% glossarytooltip 6c5cb4e9-9197-46f2-ba79-6147d9bfe66d %}CSS{% endglossarytooltip %} generated from LESS.
* "View" refers to presentation layer (from MVC).
Static view files are located in the `/pub/static` directory, and some are cached in the `/var/view_preprocessed` directory as well.
@@ -29,7 +29,7 @@ Static view files deployment is affected by Magento modes as follows:
You must write static view files to the Magento file system manually using the command discussed in this topic; after that, you can restrict permissions to limit your vulnerabilities and to prevent accidental or malicious overwriting of files.
-_Developer mode only_: When you install or enable a new module, it might load new JavaScript, CSS, layouts, and so on. To avoid issues with static files, you must clean the old files to make sure you get all the changes for the new module.
+_Developer mode only_: When you install or enable a new module, it might load new JavaScript, CSS, layouts, and so on. To avoid issues with static files, you must clean the old files to make sure you get all the changes for the new {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %}.
You can clean generated static view files in several ways, see the Clean static files cache topic for details.
@@ -41,7 +41,7 @@ In addition to the command arguments discussed here, see Deploy static view files
To deploy static view files:
-1. Log in to the Magento server as, or switch to, the Magento file system owner.
+1. Log in to the Magento server as, or switch to, the {% glossarytooltip 5e7de323-626b-4d1b-a7e5-c8d13a92c5d3 %}Magento file system owner{% endglossarytooltip %}.
2. Delete the contents of `/pub/static`.
3. Run the static view files deployment tool `/bin/magento setup:static-content:deploy`.
@@ -130,7 +130,7 @@ Use the following steps:
-->
## Tips for developers customizing the static content deployment tool
-When creating a custom implementation of the static content deployment tool, do not use non atomic writing to files that should be available on the client side. Otherwise, those files might be loaded on the client side with partial content.
+When creating a custom implementation of the {% glossarytooltip a3e37235-4e8b-464f-a19d-4a120560206a %}static content{% endglossarytooltip %} deployment tool, do not use non atomic writing to files that should be available on the client side. Otherwise, those files might be loaded on the client side with partial content.
One of the options for making it atomic, is writing to files stored in a temporary directory and copying or moving them to the destination directory (from where they are actually loaded to client side) once writing is over. For details about writing to files see [http://php.net/manual/en/function.fwrite.php](http://php.net/manual/en/function.fwrite.php).
diff --git a/guides/v2.0/config-guide/cli/config-cli-subcommands-test.md b/guides/v2.0/config-guide/cli/config-cli-subcommands-test.md
index fd9c8114471..120381d5499 100644
--- a/guides/v2.0/config-guide/cli/config-cli-subcommands-test.md
+++ b/guides/v2.0/config-guide/cli/config-cli-subcommands-test.md
@@ -22,7 +22,7 @@ Following execution, a detailed report displays showing the test run and results
Prerequisites
Before you run this command, all of the following must be true:
-* The `Magento_Developer` module must be enabled. You can enable it as follows:
+* The `Magento_Developer` {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} must be enabled. You can enable it as follows:
magento module:enable [--force] Magento_Developer
diff --git a/guides/v2.0/config-guide/config/config-create.md b/guides/v2.0/config-guide/config/config-create.md
index d28ba0cf142..2bc946e969f 100644
--- a/guides/v2.0/config-guide/config/config-create.md
+++ b/guides/v2.0/config-guide/config/config-create.md
@@ -11,7 +11,7 @@ redirect_from: /guides/v1.0/config-guide/config/config-create.html
---
Extend configuration types
-To extend an existing configuration type, you need only create a configuration file in your module.
+To extend an existing configuration type, you need only create a configuration file in your {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %}.
For example, to add an event observer, you create `app/etc/events.xml` and declare a new observer.
@@ -22,11 +22,11 @@ Your new `events.xml` is automatically collected from your module and merged wit
Create configuration types
To create new configuration type, you must add at minimum:
-* XML configuration files
+* {% glossarytooltip 8c0645c5-aa6b-4a52-8266-5659a8b9d079 %}XML{% endglossarytooltip %} configuration files
* XSD validation schema
* A loader
-For example, to introduce an adapter for a new search server that enables extensions to configure how its entities are indexed in that server, create:
+For example, to introduce an {% glossarytooltip edb42858-1ff8-41f9-80a6-edf0d86d7e10 %}adapter{% endglossarytooltip %} for a new search server that enables extensions to configure how its entities are indexed in that server, create:
* A loader.
* An XSD schema.
diff --git a/guides/v2.0/config-guide/config/config-files.md b/guides/v2.0/config-guide/config/config-files.md
index 422bf68e590..8d92f48eec9 100644
--- a/guides/v2.0/config-guide/config/config-files.md
+++ b/guides/v2.0/config-guide/config/config-files.md
@@ -11,7 +11,7 @@ redirect_from: /guides/v1.0/config-guide/config/config-files.html
---
Overview of module configuration files
-The responsibilities of the `config.xml` configuration file used in earlier versions of Magento is now divided between several files, located in various module directories. Magento's multiple configuration files load on demand only when a module requests a specific configuration type.
+The responsibilities of the `config.xml` configuration file used in earlier versions of Magento is now divided between several files, located in various {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} directories. Magento's multiple configuration files load on demand only when a module requests a specific configuration type.
You can use these files—also referred to as *configuration types*—to customize specific aspects of your module's behavior.
@@ -113,7 +113,7 @@ You can interact with configuration files using interfaces under Framework\Config\ConverterInterface, which converts the XML into an in-memory array representation of the configurations.
+* Framework\Config\ConverterInterface, which converts the {% glossarytooltip 8c0645c5-aa6b-4a52-8266-5659a8b9d079 %}XML{% endglossarytooltip %} into an in-memory array representation of the configurations.
* Framework\Config\DataInterface, which retrieves the configuration data in a specified scope.
* Framework\Config\FileResolverInterface, which identifies the location of files to be read by `\Magento\Framework\Config\ReaderInterface`
* Framework\Config\ReaderInterface, which reads the configuration data from storage and selects the storage from which it reads.
diff --git a/guides/v2.0/config-guide/config/config-php.md b/guides/v2.0/config-guide/config/config-php.md
index bb84e710a35..70c52e2cfae 100644
--- a/guides/v2.0/config-guide/config/config-php.md
+++ b/guides/v2.0/config-guide/config/config-php.md
@@ -14,13 +14,13 @@ redirect_from: /guides/v1.0/config-guide/config/config-php.html
{% include install/deployment-config.html %}
Details about the deployment configuration
-`config.php` and `env.php` are PHP files that return a multi-dimensional associative array, which is basically a hierarchical arrangement of configuration parameters and values.
+`config.php` and `env.php` are {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} files that return a multi-dimensional associative array, which is basically a hierarchical arrangement of configuration parameters and values.
On the top level of this array are *configuration segments*. A segment has arbitrary content (a scalar value or a nested array) distinguished by an arbitrary key—where both the key and its value are defined by the Magento framework.
Magento\Framework\App\DeploymentConfig merely provides access to these sections but does not allow you to extend them.
-On the next hierarchy level, items in each segment are ordered according to the module sequence definition, which is obtained by merging all modules' configuration files, with the exception of disabled modules.
+On the next hierarchy level, items in each segment are ordered according to the {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} sequence definition, which is obtained by merging all modules' configuration files, with the {% glossarytooltip 53da11f1-d0b8-4a7e-b078-1e099462b409 %}exception{% endglossarytooltip %} of disabled modules.
The following sections discusses the structure and contents of the deployment configuration—`config.php` and `env.php`.
@@ -59,7 +59,7 @@ return array (
The value `1` or `0` indicates whether a module is enabled or disabled.
-Disabled modules are not recognized by the Magento application; in other words, they don't participate in merging configuration, in dependency injection, events, plug-ins, and so on. Disabled modules do not modify the storefront or Admin and don't affect routing.
+Disabled modules are not recognized by the Magento application; in other words, they don't participate in merging configuration, in dependency injection, events, plug-ins, and so on. Disabled modules do not modify the {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %} or {% glossarytooltip 29ddb393-ca22-4df9-a8d4-0024d75739b1 %}Admin{% endglossarytooltip %} and don't affect routing.
The only practical difference of a module being disabled and being completely absent in the code base is that a disabled module is found by the autoloader, enabling its classes and constants to be reused in other code.
@@ -131,7 +131,7 @@ The following table provides details about each `env.php` segment and its struct
### Magento PSR-3 compliance
-The [PSR-3 standard](https://zendframework.github.io/zend-log/psr3){:target="_blank"} defines a common PHP interface for logging libraries. The main goal of PSR-3 is to allow libraries to receive a `Psr\Log\LoggerInterface` object and write logs to it in a simple and universal way.
+The [PSR-3 standard](https://zendframework.github.io/zend-log/psr3){:target="_blank"} defines a common {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} interface for logging libraries. The main goal of PSR-3 is to allow libraries to receive a `Psr\Log\LoggerInterface` object and write logs to it in a simple and universal way.
This provides the ability for the implementation to be replaced easily without worry that such replacement may break the application code. It also guarantees a custom component will work even when the Magento log implementation is changed in a future version of the system.
diff --git a/guides/v2.0/config-guide/log/log-magento.md b/guides/v2.0/config-guide/log/log-magento.md
index 82359956308..a195deba976 100644
--- a/guides/v2.0/config-guide/log/log-magento.md
+++ b/guides/v2.0/config-guide/log/log-magento.md
@@ -15,7 +15,7 @@ github_link: config-guide/log/log-magento.md
## Monolog {#config-log-monolog}
Magento 2 complies with the PSR-3 standard. By default, Magento uses [Monolog](https://github.com/Seldaek/monolog){:target="_blank"}. Monolog implemented as a preference for `Psr\Log\LoggerInterface` in the Magento application [`di.xml`]({{ site.mage2000url }}app/etc/di.xml#L9){:target="_blank"}.
-Monolog is a popular PHP logging solution with a wide range of handlers that enable you to build advanced logging strategies. Following is a summary of how Monolog works.
+Monolog is a popular {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} logging solution with a wide range of handlers that enable you to build advanced logging strategies. Following is a summary of how Monolog works.
A Monolog _logger_ is a channel that has its own set of _handlers_. Monolog has a large number of handlers, including:
diff --git a/guides/v2.0/config-guide/memcache/memcache.md b/guides/v2.0/config-guide/memcache/memcache.md
index 801f56c00bd..5e98b05cbf2 100644
--- a/guides/v2.0/config-guide/memcache/memcache.md
+++ b/guides/v2.0/config-guide/memcache/memcache.md
@@ -19,7 +19,7 @@ Magento uses memcached for session storage but not for page caching. For page ca
-
We recommend you use memcached for session storage. The Redis session handler in the phpredis PHP extension does not support session locking, which might cause issues with distributed systems and applications that rely on Ajax.
+
We recommend you use memcached for session storage. The Redis session handler in the phpredis {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} {% glossarytooltip 55774db9-bf9d-40f3-83db-b10cc5ae3b68 %}extension{% endglossarytooltip %} does not support session locking, which might cause issues with distributed systems and applications that rely on Ajax.
#### Next step
diff --git a/guides/v2.0/config-guide/memcache/memcache_centos.md b/guides/v2.0/config-guide/memcache/memcache_centos.md
index 8ef5f2819f3..969976aff9a 100644
--- a/guides/v2.0/config-guide/memcache/memcache_centos.md
+++ b/guides/v2.0/config-guide/memcache/memcache_centos.md
@@ -86,7 +86,7 @@ To verify memcached is recognized by the web server:
### Create a memcache test consisting of a MySQL database and PHP script
-The test uses a MySQL database, table, and data to verify you can retrieve the database data and store it in memcache. A PHP script first searches the cache. If the result does not exist, the script queries database. After the query has been fulfilled by the original database, the script stores the result in memcache, using the `set` command.
+The test uses a MySQL database, table, and data to verify you can retrieve the database data and store it in memcache. A {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} script first searches the {% glossarytooltip 0bc9c8bc-de1a-4a06-9c99-a89a29c30645 %}cache{% endglossarytooltip %}. If the result does not exist, the script queries database. After the query has been fulfilled by the original database, the script stores the result in memcache, using the `set` command.
More details about this test
diff --git a/guides/v2.0/config-guide/memcache/memcache_magento.md b/guides/v2.0/config-guide/memcache/memcache_magento.md
index 362e3d10e37..4ea98899123 100644
--- a/guides/v2.0/config-guide/memcache/memcache_magento.md
+++ b/guides/v2.0/config-guide/memcache/memcache_magento.md
@@ -48,9 +48,9 @@ To verify memcached works with Magento:
rm -rf var/cache/* var/page_cache/* var/session/*
-2. Go to any page on the storefront.
+2. Go to any page on the {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %}.
-3. Log in to the Magento Admin and browse to several pages.
+3. Log in to the {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %} and browse to several pages.
If no errors display, congratulations! memcached is working! You can optionally look at memcached storage as discussed in the next step.
diff --git a/guides/v2.0/config-guide/memcache/memcache_ubuntu.md b/guides/v2.0/config-guide/memcache/memcache_ubuntu.md
index 460f2381343..c1f2c6a1ca2 100644
--- a/guides/v2.0/config-guide/memcache/memcache_ubuntu.md
+++ b/guides/v2.0/config-guide/memcache/memcache_ubuntu.md
@@ -73,7 +73,7 @@ To verify memcached is recognized by the web server:
If memcache does not display, restart the web server and refresh the browser page. If it still does not display, verify you installed the `php-pecl-memcache` extension.
### Verify memcached can cache data
-This test uses a PHP script to verify that memcached can store and retrieve cache data.
+This test uses a {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} script to verify that memcached can store and retrieve {% glossarytooltip 0bc9c8bc-de1a-4a06-9c99-a89a29c30645 %}cache{% endglossarytooltip %} data.
For more information about this test, see this digitalocean tutorial.
diff --git a/guides/v2.0/config-guide/mq/config-mq.md b/guides/v2.0/config-guide/mq/config-mq.md
index f988ace5310..3eb4052844c 100644
--- a/guides/v2.0/config-guide/mq/config-mq.md
+++ b/guides/v2.0/config-guide/mq/config-mq.md
@@ -13,7 +13,7 @@ github_link: config-guide/mq/config-mq.md
The message queue topology can only be configured after Magento Community Edition has been installed and before Magento Enterprise Editions has been installed.
-Each module that is to be a publisher must be configured as such. If you want a module to use the MQF, create a `/etc/queue.xml` file and define the publisher, consumers, exchanges and bindings.
+Each module that is to be a {% glossarytooltip d5777fe2-f786-45d9-b052-cca8a10120d9 %}publisher{% endglossarytooltip %} must be configured as such. If you want a module to use the MQF, create a `/etc/queue.xml` file and define the publisher, consumers, exchanges and bindings.
Edit the queue.xml file
The `queue.xml` file can contain the following elements:
@@ -50,7 +50,7 @@ The `publisher` element configures the type of connection and the exchange to pu
connection
-
If RabbitMQ is to used to manage the queue, then the value must be rabbitmq. The value can also be db or the name of a custom adapter.
+
If RabbitMQ is to used to manage the queue, then the value must be rabbitmq. The value can also be db or the name of a custom {% glossarytooltip edb42858-1ff8-41f9-80a6-edf0d86d7e10 %}adapter{% endglossarytooltip %}.
exchange
@@ -66,7 +66,7 @@ Configuring the `topic` element defines the interface that processes the message
name
-
The name assigned to the topic. The format should be object.action You can further distinguish topic names by appending .subaction to the end of the name. Use the past tense for all verbs, to indicate the event has already happened.
+
The name assigned to the topic. The format should be object.action You can further distinguish topic names by appending .subaction to the end of the name. Use the past tense for all verbs, to indicate the {% glossarytooltip c57aef7c-97b4-4b2b-a999-8001accef1fe %}event{% endglossarytooltip %} has already happened.
Examples: customer.created, customer.sent.email
The value is specified in a bind element.
diff --git a/guides/v2.0/config-guide/mq/rabbitmq-overview.md b/guides/v2.0/config-guide/mq/rabbitmq-overview.md
index c273d0dd7a8..25e0646d78e 100644
--- a/guides/v2.0/config-guide/mq/rabbitmq-overview.md
+++ b/guides/v2.0/config-guide/mq/rabbitmq-overview.md
@@ -12,13 +12,13 @@ github_link: config-guide/mq/rabbitmq-overview.md
-The Message Queue Framework (MQF) is a system within Magento Enterprise Edition that allows a module to publish messages to queues. It also defines the consumers that will receive the messages asynchronously. The MQF uses [RabbitMQ](http://www.rabbitmq.com) as the messaging broker, which provides a scalable platform for sending and receiving messages. It also includes a mechanism for storing undelivered messages. RabbitMQ is based on the Advanced Message Queuing Protocol (AMQP) 0.9.1 specification.
+The Message Queue Framework (MQF) is a system within Magento Enterprise Edition that allows a {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} to publish messages to queues. It also defines the consumers that will receive the messages asynchronously. The MQF uses [RabbitMQ](http://www.rabbitmq.com) as the messaging broker, which provides a scalable platform for sending and receiving messages. It also includes a mechanism for storing undelivered messages. RabbitMQ is based on the Advanced Message Queuing Protocol (AMQP) 0.9.1 specification.
The following diagram illustrates the Message Queue Framework.
-* A publisher is a component that sends messages to an exchange. It knows which exchange to publish to and the format of the messages it sends.
+* A {% glossarytooltip d5777fe2-f786-45d9-b052-cca8a10120d9 %}publisher{% endglossarytooltip %} is a component that sends messages to an exchange. It knows which exchange to publish to and the format of the messages it sends.
* An exchange receives messages from publishers and sends them to queues. Although RabbitMQ supports multiple types of exchanges, Magento uses topic exchanges only. A topic includes a routing key, which contains text strings separated by dots. The format for a topic name is string1.string2..., for example, `customer.created` or `customer.sent.email`.
@@ -28,7 +28,7 @@ The following diagram illustrates the Message Queue Framework.
* A consumer receives messages. It knows which queue to consume. It can map processors of the message to a specific queue.
-A basic message queue system can also be set up without using RabbitMQ. In this system, a MySQL adapter stores messages in the database. Three database tables (`queue`, `queue_message`, and `queue_message_status`) manage the message queue workload. Cron jobs ensure the consumers are able to receive messages. This solution is not very scalable. RabbitMQ should be used whenever possible.
+A basic message queue system can also be set up without using RabbitMQ. In this system, a MySQL {% glossarytooltip edb42858-1ff8-41f9-80a6-edf0d86d7e10 %}adapter{% endglossarytooltip %} stores messages in the database. Three database tables (`queue`, `queue_message`, and `queue_message_status`) manage the message queue workload. Cron jobs ensure the consumers are able to receive messages. This solution is not very scalable. RabbitMQ should be used whenever possible.
See Configure message queues for information about setting up the message queue system.
diff --git a/guides/v2.0/config-guide/multi-master/multi-master.md b/guides/v2.0/config-guide/multi-master/multi-master.md
index 07be69d0be0..89748292fce 100644
--- a/guides/v2.0/config-guide/multi-master/multi-master.md
+++ b/guides/v2.0/config-guide/multi-master/multi-master.md
@@ -17,7 +17,7 @@ github_link: config-guide/multi-master/multi-master.md
Magento 2 EE offers number of scalability advantages, including the ability to use three separate master databases for different functional areas of the Magento application.
-Checkout, orders, and product data can all each use a separate master databases that you can optionally replicate. This separation independently scales load from website checkouts, order management activities, website browsing, and merchandising activities, depending on your needs. These changes provide considerable flexibility in how the database tier can be scaled.
+Checkout, orders, and product data can all each use a separate master databases that you can optionally replicate. This separation independently scales load from {% glossarytooltip a3c8f20f-b067-414e-9781-06378c193155 %}website{% endglossarytooltip %} checkouts, order management activities, website browsing, and merchandising activities, depending on your needs. These changes provide considerable flexibility in how the database tier can be scaled.
Magento Enterprise Cloud Edition does _not_ support this feature at this time.
@@ -45,7 +45,7 @@ Magento EE uses three master databases and a configurable number of slave databa
Because of the way the split database performance solution is designed, your custom code and installed components *cannot* do any of the following:
* Write directly to the database (instead, you must use the Magento EE database interface)
-* Use JOINs that affect the sales or quote databases
+* Use JOINs that affect the sales or {% glossarytooltip 77e19d0d-e7b1-4d3d-9bad-e92fbb9fb59a %}quote{% endglossarytooltip %} databases
* Use foreign keys to tables in the checkout, sales, or main databases
@@ -71,7 +71,7 @@ This also means you can either:
Prerequisites
The split database requires you to set up three MySQL master databases on any host (all three on the Magento server, each database on a separate server, and so on). These are the *master* databases and they're used as follows:
-* One master database for checkout tables
+* One master database for {% glossarytooltip 278c3ce0-cd4c-4ffc-a098-695d94d73bde %}checkout{% endglossarytooltip %} tables
* One master database for sales tables (also referred to as *Order Management System*, or *OMS*, tales)
* One master database for the remainder of the Magento 2 application tables
diff --git a/guides/v2.0/config-guide/multi-master/multi-master_manual.md b/guides/v2.0/config-guide/multi-master/multi-master_manual.md
index 04892d2061b..8a662f72051 100644
--- a/guides/v2.0/config-guide/multi-master/multi-master_manual.md
+++ b/guides/v2.0/config-guide/multi-master/multi-master_manual.md
@@ -17,7 +17,7 @@ If the Magento application is already in production or if you've already install
Manually splitting databases involves:
-* Create the checkout and order management system (OMS) databases
+* Create the {% glossarytooltip 278c3ce0-cd4c-4ffc-a098-695d94d73bde %}checkout{% endglossarytooltip %} and order management system (OMS) databases
* Run a series of SQL scripts that:
* Drop foreign keys
@@ -44,7 +44,7 @@ This topic uses the following naming conventions:
## Back up the Magento system {#config-ee-multidb-backup}
-We strongly recommend you back up your current database and file system so you can restore it later in the event of issues during the process.
+We strongly recommend you back up your current database and file system so you can restore it later in the {% glossarytooltip c57aef7c-97b4-4b2b-a999-8001accef1fe %}event{% endglossarytooltip %} of issues during the process.
{% collapsible Click to show how to back up Magento %}
@@ -58,7 +58,7 @@ To back up your system:
{% endcollapsible %}
## Set up additional master databases {#config-ee-multidb-master-masters}
-This section discusses how to create database instances for sales and quote tables.
+This section discusses how to create database instances for sales and {% glossarytooltip 77e19d0d-e7b1-4d3d-9bad-e92fbb9fb59a %}quote{% endglossarytooltip %} tables.
{% collapsible Click to show how to create database instances %}
Create sales and OMS quote databases as follows:
@@ -484,7 +484,7 @@ Locate the block starting with `'resource'` and add `'checkout'` and `'sales'` s
{% endcollapsible %}
## Reference scripts {#split-db-ref}
-This section provides scripts you can run that print a complete list of affected tables without performing any actions on them. You can use them to see what tables are affected before you manually split databases, which can be useful if you use extensions that customize the Magento database schema.
+This section provides scripts you can run that print a complete list of affected tables without performing any actions on them. You can use them to see what tables are affected before you manually split databases, which can be useful if you use extensions that customize the Magento {% glossarytooltip 66b924b4-8097-4aea-93d9-05a81e6cc00c %}database schema{% endglossarytooltip %}.
{% collapsible Click to view reference SQL scripts %}
diff --git a/guides/v2.0/config-guide/multi-master/multi-master_masterdb.md b/guides/v2.0/config-guide/multi-master/multi-master_masterdb.md
index 3ac956171b4..3a20ac37939 100644
--- a/guides/v2.0/config-guide/multi-master/multi-master_masterdb.md
+++ b/guides/v2.0/config-guide/multi-master/multi-master_masterdb.md
@@ -16,7 +16,7 @@ github_link: config-guide/multi-master/multi-master_masterdb.md
This topic discusses how to get started with the split database solution by:
1. Installing Magento 2 EE with a single master database (named `magento`)
-2. Creating two additional master databases for checkout and OMS (named `magento_quote` and `magento_sales`)
+2. Creating two additional master databases for {% glossarytooltip 278c3ce0-cd4c-4ffc-a098-695d94d73bde %}checkout{% endglossarytooltip %} and OMS (named `magento_quote` and `magento_sales`)
2. Configuring EE to use the checkout and sales databases
diff --git a/guides/v2.0/config-guide/multi-master/multi-master_slavedb.md b/guides/v2.0/config-guide/multi-master/multi-master_slavedb.md
index 6593e17319c..02042ef455c 100644
--- a/guides/v2.0/config-guide/multi-master/multi-master_slavedb.md
+++ b/guides/v2.0/config-guide/multi-master/multi-master_slavedb.md
@@ -116,7 +116,7 @@ The following is more advanced and is provided for your information only:
{% endhighlight %}
## Performance improvement
-To improve the performance of master-slave replication, you can filter some tables on slave instances. We recommend filtering all temporary tables with name pattern `search\_tmp\_%` that are used for catalog search.
+To improve the performance of master-slave replication, you can filter some tables on slave instances. We recommend filtering all temporary tables with name pattern `search\_tmp\_%` that are used for {% glossarytooltip 8d40d668-4996-4856-9f81-b1386cf4b14f %}catalog{% endglossarytooltip %} search.
To do this, add the following line to your `my.cnf` file on your slave instances:
diff --git a/guides/v2.0/config-guide/multi-master/multi-master_verify.md b/guides/v2.0/config-guide/multi-master/multi-master_verify.md
index e1368bf6d6e..c065ce0432a 100644
--- a/guides/v2.0/config-guide/multi-master/multi-master_verify.md
+++ b/guides/v2.0/config-guide/multi-master/multi-master_verify.md
@@ -15,7 +15,7 @@ github_link: config-guide/multi-master/multi-master_verify.md
After configuration, the master databases are configured as follows:
* Main magento database: 250 tables
-* Magento quote database: 10 tables
+* Magento {% glossarytooltip 77e19d0d-e7b1-4d3d-9bad-e92fbb9fb59a %}quote{% endglossarytooltip %} database: 10 tables
* Magento sales database: 54 tables
To verify your split databases are working properly, perform the following tasks and verify that data is added to the database tables using a database tool like phpmyadmin:
diff --git a/guides/v2.0/config-guide/multi-site/ms_apache.md b/guides/v2.0/config-guide/multi-site/ms_apache.md
index 0f4ba44f75d..ed361ab8468 100644
--- a/guides/v2.0/config-guide/multi-site/ms_apache.md
+++ b/guides/v2.0/config-guide/multi-site/ms_apache.md
@@ -11,7 +11,7 @@ github_link: config-guide/multi-site/ms_apache.md
---
## Set values in an entry point script {#ms-entry-script}
-If necessary, copy the existing `index.php` entry point script for your website or store view and add to it the following:
+If necessary, copy the existing `index.php` entry point script for your {% glossarytooltip a3c8f20f-b067-414e-9781-06378c193155 %}website{% endglossarytooltip %} or {% glossarytooltip ca5a9ff1-8182-4fc4-a34b-9b3f831dbf3f %}store view{% endglossarytooltip %} and add to it the following:
* You're working on a development machine (laptop, virtual machine, and so on)
@@ -30,7 +30,7 @@ If necessary, copy the existing `index.php` entry point script for your website
### Roadmap for setting up multiple websites with Apache
Setting up multiple stores consists of the following tasks:
-1. [Set up websites, stores, and store views]({{ page.baseurl }}config-guide/multi-site/ms_websites.html) in the Magento Admin.
+1. [Set up websites, stores, and store views]({{ page.baseurl }}config-guide/multi-site/ms_websites.html) in the {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %}.
2. Create one [Apache virtual host](#ms-apache-vhosts) per Magento website.
diff --git a/guides/v2.0/config-guide/multi-site/ms_nginx.md b/guides/v2.0/config-guide/multi-site/ms_nginx.md
index 2b179183ac0..74c6b60e397 100644
--- a/guides/v2.0/config-guide/multi-site/ms_nginx.md
+++ b/guides/v2.0/config-guide/multi-site/ms_nginx.md
@@ -11,7 +11,7 @@ github_link: config-guide/multi-site/ms_nginx.md
---
## Set up multiple websites with nginx {#ms-nginx-over}
-This tutorial shows you step-by-step how to set up multiple websites using nginx.
+This tutorial shows you step-by-step how to set up multiple websites using {% glossarytooltip b14ef3d8-51fd-48fe-94df-ed069afb2cdc %}nginx{% endglossarytooltip %}.
### Assumptions
We assume the following:
@@ -32,8 +32,8 @@ We assume the following:
### Roadmap for setting up multiple websites with nginx
Setting up multiple stores consists of the following tasks:
-1. [Set up websites, stores, and store views]({{ page.baseurl }}config-guide/multi-site/ms_websites.html) in the Magento Admin.
-2. Create one [nginx virtual host](#ms-nginx-vhosts) per Magento website.
+1. [Set up websites, stores, and store views]({{ page.baseurl }}config-guide/multi-site/ms_websites.html) in the {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %}.
+2. Create one [nginx virtual host](#ms-nginx-vhosts) per Magento {% glossarytooltip a3c8f20f-b067-414e-9781-06378c193155 %}website{% endglossarytooltip %}.
3. Pass the values of the [Magento variables](#ms-nginx-vars) `$MAGE_RUN_TYPE` and `$MAGE_RUN_CODE` to nginx using the Magento-provided `nginx.conf.sample`.
* `$MAGE_RUN_TYPE` can be either `store` or `website`
@@ -44,7 +44,7 @@ Setting up multiple stores consists of the following tasks:
* `$MAGE_RUN_CODE` is the unique website or store view code that corresponds to `$MAGE_RUN_TYPE`
## Step 2: Create nginx virtual hosts {#ms-nginx-vhosts}
-This section discusses how to load websites on the storefront. You can use either websites or store views; if you use store views, you must adjust parameter values accordingly. You must complete the tasks in this section as a user with `root` privileges.
+This section discusses how to load websites on the {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %}. You can use either websites or store views; if you use store views, you must adjust parameter values accordingly. You must complete the tasks in this section as a user with `root` privileges.
{% collapsible To create virtual hosts: %}
diff --git a/guides/v2.0/config-guide/multi-site/ms_over.md b/guides/v2.0/config-guide/multi-site/ms_over.md
index b2b7d7ab488..e259e0c078e 100644
--- a/guides/v2.0/config-guide/multi-site/ms_over.md
+++ b/guides/v2.0/config-guide/multi-site/ms_over.md
@@ -17,12 +17,12 @@ redirect_from:
One instance of the Magento software can enable you to start multiple websites or store views that use different:
* Default languages
-* Domain names
+* {% glossarytooltip 41aee03b-a5d5-49c2-8839-894090ef4e86 %}Domain{% endglossarytooltip %} names
* Categories
-This flexible solution enables one Magento codebase and Magento Admin to administer and display different stores.
+This flexible solution enables one Magento codebase and {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %} to administer and display different stores.
-You configure the websites, stores, and store views in the Magento Admin. You use the `MAGE_RUN_TYPE` and `MAGE_RUN_CODE` variables in virtual hosts to start the Magento application using these websites or store views.
+You configure the websites, stores, and store views in the Magento {% glossarytooltip 29ddb393-ca22-4df9-a8d4-0024d75739b1 %}Admin{% endglossarytooltip %}. You use the `MAGE_RUN_TYPE` and `MAGE_RUN_CODE` variables in virtual hosts to start the Magento application using these websites or store views.
A typical use of `MAGE_RUN_TYPE` and `MAGE_RUN_CODE` is to set up stores with different options in different domains. For example, you could have one set of categories and products on one domain and another domain that has categories and products for a different language.
@@ -33,13 +33,13 @@ We use the following terms:
* *Website* is the top-level container for sites, shipping methods, payment methods, and so on. To create completely separate sites that do not share cart, shipping methods, and so on, you must create separate websites.
-* *Store* is contained by a website. In turn, a store contains at least one *store view*.
+* *Store* is contained by a {% glossarytooltip a3c8f20f-b067-414e-9781-06378c193155 %}website{% endglossarytooltip %}. In turn, a store contains at least one *store view*.
Multiple stores can share cart, user sessions, payment gateways, and so on, but they have separate catalog structures.
Store views change the way pages are presented, and are typically used to display a store with different layouts or languages.
-Each website and each store view must have a unique identifier. This identifier is required to use `MAGE_RUN_TYPE` and `MAGE_RUN_CODE` as follows:
+Each website and each {% glossarytooltip ca5a9ff1-8182-4fc4-a34b-9b3f831dbf3f %}store view{% endglossarytooltip %} must have a unique identifier. This identifier is required to use `MAGE_RUN_TYPE` and `MAGE_RUN_CODE` as follows:
* `MAGE_RUN_TYPE` can be either `store` or `website`
diff --git a/guides/v2.0/config-guide/multi-site/ms_websites.md b/guides/v2.0/config-guide/multi-site/ms_websites.md
index e120e8e179f..c3a384aa02c 100644
--- a/guides/v2.0/config-guide/multi-site/ms_websites.md
+++ b/guides/v2.0/config-guide/multi-site/ms_websites.md
@@ -11,7 +11,7 @@ github_link: config-guide/multi-site/ms_websites.md
---
## Set up multiple websites, stores, and store views in the Admin
-This task requires you to create a root category (and additional categories if desired) for each store.
+This task requires you to create a root {% glossarytooltip 50e49338-1e6c-4473-8527-9e401d67ea2b %}category{% endglossarytooltip %} (and additional categories if desired) for each store.
The tasks discussed in this topic provide one way to set up multiple stores. For additional information, see the following resources in the Magento User Guide:
@@ -21,7 +21,7 @@ The tasks discussed in this topic provide one way to set up multiple stores. For
* [Content](http://docs.magento.com/m2/ce/user_guide/cms/content-menu.html){:target="_blank"}
-For example purposes only, we use a French website with website code `french` in this topic. For step-by-step tutorials, see:
+For example purposes only, we use a French {% glossarytooltip a3c8f20f-b067-414e-9781-06378c193155 %}website{% endglossarytooltip %} with website code `french` in this topic. For step-by-step tutorials, see:
* [Tutorial—Set up multiple websites with Apache]({{ page.baseurl }}config-guide/multi-site/ms_apache.html)
* [Tutorial—Set up multiple websites with nginx]({{ page.baseurl }}config-guide/multi-site/ms_nginx.html)
@@ -29,7 +29,7 @@ For example purposes only, we use a French website with website code `french` in
## Step 1: Create root categories
-Creating a root category is optional, but we show how to do it in this tutorial in the event you want each website to have a unique root category. You can create additional categories if you choose.
+Creating a root category is optional, but we show how to do it in this tutorial in the {% glossarytooltip c57aef7c-97b4-4b2b-a999-8001accef1fe %}event{% endglossarytooltip %} you want each website to have a unique root category. You can create additional categories if you choose.
{% collapsible To create a root category: %}
@@ -109,7 +109,7 @@ Creating a root category is optional, but we show how to do it in this tutorial
{% endcollapsible %}
## Step 5: Change a website's base URL
-To access a website using a unique URL like `http://french.magento.mg`, you must change the base URL for each site in the Magento Admin.
+To access a website using a unique {% glossarytooltip a05c59d3-77b9-47d0-92a1-2cbffe3f8622 %}URL{% endglossarytooltip %} like `http://french.magento.mg`, you must change the base URL for each site in the {% glossarytooltip 18b930cf-09cc-47c9-a5e5-905f86c43f81 %}Magento Admin{% endglossarytooltip %}.
{% collapsible To change the website's base URL: %}
diff --git a/guides/v2.0/config-guide/prod/prod_deploy.md b/guides/v2.0/config-guide/prod/prod_deploy.md
index 7b94ced0b0d..a58f2727228 100644
--- a/guides/v2.0/config-guide/prod/prod_deploy.md
+++ b/guides/v2.0/config-guide/prod/prod_deploy.md
@@ -21,5 +21,5 @@ The following is a list of recommended strategies for production deployment:
* [Deployment strategies from the community][2]
[0]: {{page.baseurl}}config-guide/prod/single-machine-deployment.html
-[1]: {{page.baseurl}}cloud/discover-deploy.html
+[1]: {{page.baseurl}}cloud/reference/discover-deploy.html
[2]: {{site.baseurl}}community/resources/#installdeploy
diff --git a/guides/v2.0/config-guide/prod/single-machine-deployment.md b/guides/v2.0/config-guide/prod/single-machine-deployment.md
index 6055be5cd41..2191eff0baf 100644
--- a/guides/v2.0/config-guide/prod/single-machine-deployment.md
+++ b/guides/v2.0/config-guide/prod/single-machine-deployment.md
@@ -14,7 +14,7 @@ This topic provides instructions for deploying updates to Magento on a productio
This process applies to technical users responsible for stores running on a single machine with some themes and locales installed.
-For less technical users, i.e. business users, we recommend using the [System Upgrade][9] feature in the Admin.
+For less technical users, i.e. business users, we recommend using the [System Upgrade][9] feature in the {% glossarytooltip 29ddb393-ca22-4df9-a8d4-0024d75739b1 %}Admin{% endglossarytooltip %}.
## Assumptions
@@ -55,7 +55,7 @@ Contributing developers should use [this guide][6] to update their Magento insta
composer update
-6. Update the database schema and data:
+6. Update the {% glossarytooltip 66b924b4-8097-4aea-93d9-05a81e6cc00c %}database schema{% endglossarytooltip %} and data:
php bin/magento setup:upgrade
diff --git a/guides/v2.0/config-guide/redis/config-redis.md b/guides/v2.0/config-guide/redis/config-redis.md
index 7b8e524ec92..8e2c911593a 100644
--- a/guides/v2.0/config-guide/redis/config-redis.md
+++ b/guides/v2.0/config-guide/redis/config-redis.md
@@ -17,21 +17,21 @@ github_link: config-guide/redis/config-redis.md
* The `core_cache_tag` table constantly grows. If a Magento instance has multiple web sites and web stores with large catalogs, the table can grow to 15 million records in less than a day. Insertion into `core_cache_tag` leads to issues with MySQL server, including performance degradation.
- (A *tag* is an identifier that classifies different types of Magento cache objects.)
+ (A *tag* is an identifier that classifies different types of Magento {% glossarytooltip 0bc9c8bc-de1a-4a06-9c99-a89a29c30645 %}cache{% endglossarytooltip %} objects.)
-* The TwoLevels backend is more difficult to maintain because two services are required to make it work which makes it difficult to analyze cache content when necessary.
+* The TwoLevels {% glossarytooltip 74d6d228-34bd-4475-a6f8-0c0f4d6d0d61 %}backend{% endglossarytooltip %} is more difficult to maintain because two services are required to make it work which makes it difficult to analyze cache content when necessary.
Further, memcached itself has limitations such as a maximum object size and fixed bucket sizes which also contribute to difficult maintenance.
-* The Zend TwoLevels backend does not scale well because using the database as part of the cache backend adds additional load to the master database server. Additionally, there is no reliable method for `memcached` replication.
+* The Zend TwoLevels backend does not scale well because using the database as part of the {% glossarytooltip 8f2067d1-4a39-4ed2-916d-7c9c58ccf30c %}cache backend{% endglossarytooltip %} adds additional load to the master database server. Additionally, there is no reliable method for `memcached` replication.
### Why Redis is better
Advantages of Redis include:
-* Redis can also be used for PHP session storage, making it possible to completely replace `memcached` with Redis.
+* Redis can also be used for {% glossarytooltip bf703ab1-ca4b-48f9-b2b7-16a81fd46e02 %}PHP{% endglossarytooltip %} session storage, making it possible to completely replace `memcached` with Redis.
* The Redis backend works by indexing tags in files so that tag operations do not require a full scan of every cache file.
-* The metadata and the cache record are stored in the same file rather than separate files resulting in fewer inodes and fewer file stat, read, write, lock, and unlink operations. Also, the original hashed directory structure had very poor distribution due to the `adler32` hashing algorithm and prefixes. The multi-level nested directories have been dropped in favor of single-level nesting made from multiple characters.
+* The {% glossarytooltip 3f0f2ef1-ad38-41c6-bd1e-390daaa71d76 %}metadata{% endglossarytooltip %} and the cache record are stored in the same file rather than separate files resulting in fewer inodes and fewer file stat, read, write, lock, and unlink operations. Also, the original hashed directory structure had very poor distribution due to the `adler32` hashing algorithm and prefixes. The multi-level nested directories have been dropped in favor of single-level nesting made from multiple characters.
* The backend supports tag-based cache cleanup without `foreach` loops.
diff --git a/guides/v2.0/config-guide/redis/redis-session.md b/guides/v2.0/config-guide/redis/redis-session.md
index 3a755764020..3ec6704bcec 100644
--- a/guides/v2.0/config-guide/redis/redis-session.md
+++ b/guides/v2.0/config-guide/redis/redis-session.md
@@ -22,29 +22,29 @@ Before you continue, [install Redis]({{page.baseurl}}config-guide/redis/config-r
Following is a sample configuration to add to `app/etc/env.php`:
'session' =>
- array (
- 'save' => 'redis',
- 'redis' =>
- array (
- 'host' => '127.0.0.1',
- 'port' => '6379',
- 'password' => '',
- 'timeout' => '2.5',
- 'persistent_identifier' => '',
- 'database' => '2',
- 'compression_threshold' => '2048',
- 'compression_library' => 'gzip',
- 'log_level' => '1',
- 'max_concurrency' => '6',
- 'break_after_frontend' => '5',
- 'break_after_adminhtml' => '30',
- 'first_lifetime' => '600',
- 'bot_first_lifetime' => '60',
- 'bot_lifetime' => '7200',
- 'disable_locking' => '0',
- 'min_lifetime' => '60',
- 'max_lifetime' => '2592000'
- )
+ array (
+ 'save' => 'redis',
+ 'redis' =>
+ array (
+ 'host' => '127.0.0.1',
+ 'port' => '6379',
+ 'password' => '',
+ 'timeout' => '2.5',
+ 'persistent_identifier' => '',
+ 'database' => '2',
+ 'compression_threshold' => '2048',
+ 'compression_library' => 'gzip',
+ 'log_level' => '1',
+ 'max_concurrency' => '6',
+ 'break_after_frontend' => '5',
+ 'break_after_adminhtml' => '30',
+ 'first_lifetime' => '600',
+ 'bot_first_lifetime' => '60',
+ 'bot_lifetime' => '7200',
+ 'disable_locking' => '0',
+ 'min_lifetime' => '60',
+ 'max_lifetime' => '2592000'
+ )
),
where
diff --git a/guides/v2.0/config-guide/secy/secy-cron.md b/guides/v2.0/config-guide/secy/secy-cron.md
index b7d4089605c..a5363d600b5 100644
--- a/guides/v2.0/config-guide/secy/secy-cron.md
+++ b/guides/v2.0/config-guide/secy/secy-cron.md
@@ -74,7 +74,7 @@ Contents of the file:
Step 3: Secure cron in .htaccess
To add security for cron in Magento's `.htaccess`:
-1. Log in to your Magento server as, or switch to, the Magento file system owner.
+1. Log in to your Magento server as, or switch to, the {% glossarytooltip 5e7de323-626b-4d1b-a7e5-c8d13a92c5d3 %}Magento file system owner{% endglossarytooltip %}.
2. Open `/pub/.htaccess` in a text editor.
(Because `cron.php` is located in the `pub` directory, edit this `.htaccess` only.)
@@ -100,7 +100,7 @@ To add security for cron in Magento's `.htaccess`:
6. Continue with Verify cron is secure.
Secure cron with nginx
-This section discusses how to secure cron using the nginx web server. You must perform the following tasks:
+This section discusses how to secure cron using the {% glossarytooltip b14ef3d8-51fd-48fe-94df-ed069afb2cdc %}nginx{% endglossarytooltip %} web server. You must perform the following tasks:
1. Set up an encrypted password file for nginx
2. Modify your nginx configuration to reference the password file when accessing `pub/cron.php`
diff --git a/guides/v2.0/config-guide/secy/secy-headers.md b/guides/v2.0/config-guide/secy/secy-headers.md
index be4d2e2f985..ac364ef6901 100644
--- a/guides/v2.0/config-guide/secy/secy-headers.md
+++ b/guides/v2.0/config-guide/secy/secy-headers.md
@@ -10,7 +10,7 @@ version: 2.0
github_link: config-guide/secy/secy-headers.md
---
-This topic discusses how to prevent cache poisoning if you use the Microsoft Internet Information Server (IIS) web server. *Cache poisoning* is a method of changing cache contents to include different pages from the same site. For example, it is possible to inject an HTTP 404 (Not Found) error page in place of some benign page (for example, the storefront home page), which can lead to a potential denial-of-service (DoS). The malicious page URLs are cached by Varnish or Redis, hence the name *page cache poisoning*.
+This topic discusses how to prevent {% glossarytooltip 0bc9c8bc-de1a-4a06-9c99-a89a29c30645 %}cache{% endglossarytooltip %} poisoning if you use the Microsoft Internet Information Server (IIS) web server. *Cache poisoning* is a method of changing cache contents to include different pages from the same site. For example, it is possible to inject an HTTP 404 (Not Found) error page in place of some benign page (for example, the {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %} home page), which can lead to a potential denial-of-service (DoS). The malicious page URLs are cached by Varnish or Redis, hence the name *page cache poisoning*.
These types of attacks can be difficult to detect because they do not result in errors in web server logs.
@@ -24,7 +24,7 @@ This solution applies to the following Magento versions:
### Description
-The issue results if URL rewrites are enabled on the IIS server, and any of the following HTTP headers are altered before the request reaches the Varnish or Redis caching service:
+The issue results if {% glossarytooltip a05c59d3-77b9-47d0-92a1-2cbffe3f8622 %}URL{% endglossarytooltip %} rewrites are enabled on the IIS server, and any of the following HTTP headers are altered before the request reaches the Varnish or Redis caching service:
* `X-Rewrite-Url`
* `X-Original-Url`
diff --git a/guides/v2.0/config-guide/secy/secy-xframe.md b/guides/v2.0/config-guide/secy/secy-xframe.md
index bab85a4ac2b..68041e7725f 100644
--- a/guides/v2.0/config-guide/secy/secy-xframe.md
+++ b/guides/v2.0/config-guide/secy/secy-xframe.md
@@ -11,7 +11,7 @@ github_link: config-guide/secy/secy-xframe.md
---
## Overview
-To help prevent clickjacking exploits, we added an option to use the X-Frame-Options HTTP request header in requests to your storefront.
+To help prevent clickjacking exploits, we added an option to use the X-Frame-Options HTTP request header in requests to your {% glossarytooltip 1a70d3ac-6bd9-475a-8937-5f80ca785c14 %}storefront{% endglossarytooltip %}.
The `X-Frame-Options` header enables you to specify whether or not a browser should be allowed to render a page in a ``, `
diff --git a/guides/v2.0/architecture/view/page-assets.md b/guides/v2.0/architecture/view/page-assets.md
index 4949e1f8543..976c0673757 100644
--- a/guides/v2.0/architecture/view/page-assets.md
+++ b/guides/v2.0/architecture/view/page-assets.md
@@ -13,10 +13,10 @@ redirect_from: /guides/v1.0/architecture/view/page-assets.html
## Overview {#m2devgde-page-assets-intro}
-An _asset_ is a reference to a certain resource linked to an HTML page; that is, references to scripts, stylesheets, RSS feeds, and so on using `
-The Message Queue Framework (MQF) is a system within Magento Enterprise Edition that allows a module to publish messages to queues. It also defines the consumers that will receive the messages asynchronously. The MQF uses [RabbitMQ](http://www.rabbitmq.com) as the messaging broker, which provides a scalable platform for sending and receiving messages. It also includes a mechanism for storing undelivered messages. RabbitMQ is based on the Advanced Message Queuing Protocol (AMQP) 0.9.1 specification.
+The Message Queue Framework (MQF) is a system within Magento Enterprise Edition that allows a {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} to publish messages to queues. It also defines the consumers that will receive the messages asynchronously. The MQF uses [RabbitMQ](http://www.rabbitmq.com) as the messaging broker, which provides a scalable platform for sending and receiving messages. It also includes a mechanism for storing undelivered messages. RabbitMQ is based on the Advanced Message Queuing Protocol (AMQP) 0.9.1 specification.
The following diagram illustrates the Message Queue Framework.
-* A publisher is a component that sends messages to an exchange. It knows which exchange to publish to and the format of the messages it sends.
+* A {% glossarytooltip d5777fe2-f786-45d9-b052-cca8a10120d9 %}publisher{% endglossarytooltip %} is a component that sends messages to an exchange. It knows which exchange to publish to and the format of the messages it sends.
* An exchange receives messages from publishers and sends them to queues. Although RabbitMQ supports multiple types of exchanges, Magento uses topic exchanges only. A topic includes a routing key, which contains text strings separated by dots. The format for a topic name is