You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 19, 2024. It is now read-only.
abort"Error in '#{page.path}'.\nThe 'migrated_to' parameter in the front matter points to the wrong domain: #{page.data['migrated_to']}.\nShould be 'https://experienceleague.adobe.com' or 'https://developer.adobe.com'".red
49
-
end
52
+
redirected_to: page.data['redirect_to'] || abort("Error in '#{page.path}'.\n Check 'redirect_to' in the file's frontmatter.".red),
abort"Error in '#{page.path}'.\nThe 'redirected_to' parameter in the front matter points to the wrong domain: #{page.data['redirect_to']}.\nShould be 'https://experienceleague.adobe.com' or 'https://developer.adobe.com'".red
Catalog Service uses GraphQL queries to provide rich view-model (read-only) catalog data to quickly and fully render product-related content on storefront, including product detail pages and product list pages. Catalog Service, along with [Live Search]({{site.baseurl}}/live-search/overview.html), each implement queries that return information that is not available to the [`products` query]({{site.baseurl}}/guides/v2.4/graphql/queries/products.html) on Adobe Commerce and Magento Open Source. For example, the Catalog Service [`products` query](products.html) treats all products as either simple or complex. Simple products have a single price, while complex products have a price range. The Live Search [`productSearch` query](../live-search/product-search.html) returns detailed facet information.
The Catalog Service for Adobe Commerce `products` query returns details about the SKUs specified as input. Although this query has the same name as the [`products` query]({{site.baseurl}}/guides/v2.4/graphql/queries/products.html) that is provided with core Adobe Commerce and Magento Open Source, there are some differences.
The Catalog Service for Adobe Commerce `productSearch` query can use LiveSearch to return details about the SKUs specified as input. Although this query is the same as the [`productSearch` query]({{site.baseurl}}/live-search/product-search.html), LiveSearch returns a `productView` object. See the [`productSearch` query]({{site.baseurl}}/live-search/product-search.html) topic for reference information.
The `refineProduct` query narrows the results of a `products` query that was run against a complex product. Before you run the `refineProduct` query, you must run the `products` query and construct the response so that it returns a list of `options` within a `ComplexProductView` inline fragment. When a shopper selects a product option (such as size or color) on the storefront, run the `refineProduct` query, specifying the SKU and selected option value IDs as input. Depending on the number of product options the complex product has, you might need to run the `refineProduct` query multiple times, until the shopper has selected a specific variant.
{{site.data.var.ece}} has a Starter and a Pro plan. Each plan has a unique architecture to drive your {{site.data.var.ee}} development and deployment process. Both the Starter plan and the Pro plan architecture deploy databases, web server, and caching servers across multiple environments for end-to-end testing while supporting continuous integration.
The {{site.data.var.ece}} Pro plan includes a single Git repository with a Global Master and three main environments: the **Integration** environment for development and testing, the **Staging** environment for testing with all services, and the **Production** environment for launching and maintaining your live site. See [Pro architecture]({{ site.baseurl }}/cloud/architecture/pro-architecture.html) for an overview.
The Cloud infrastructure scales according to your resource needs to achieve greater efficiency. The {{site.data.var.ece}} monitors your applications and can adjust capacity to maintain steady, predictable performance. Converting to this architecture helps to mitigate problems, such as latency or large spikes in traffic.
Your {{site.data.var.ece}} Starter architecture supports up to **four** environments, including a Master environment that contains the initial project code, the Staging environment, and up to two Integration environments.
The {{site.data.var.ece}} includes a single Git repository with a master branch for the Production environment that can be branched to create Staging and Integration environments for testing and development work. You can have up to four active environments, including a `master` environment for your production server. See [Starter architecture]({{ site.baseurl }}/cloud/architecture/starter-architecture.html) for an overview.
To develop, deploy, and test {{site.data.var.ece}}, you need to setup your local environment and clone your project's master Git branch. This local environment provides a development system for your custom code, extensions, and configurations to push for active testing in one of the Integration environments.
{{site.data.var.ece}} is a managed, automated hosting platform for the {{site.data.var.ee}} software. {{site.data.var.ece}} comes with additional features that set it apart from the on-premises {{site.data.var.ee}} and {{site.data.var.ce}} platforms:
When a request to the Fastly origin fails, Fastly returns default response pages with basic formatting and generic messaging that can be confusing for users. For example, Fastly returns the following default error page when a request to the Fastly origin fails because of a 503 error.
Fastly supports a customized version of the Varnish Configuration Language (VCL) to customize the Fastly service configuration. For example, you can allow, block, or redirect access for specific users or IPs using VCL code blocks in combination with edge and ACL dictionaries.
After you enable and verify the Fastly service in your Staging and Production environments, you can review and customize cache configuration settings like enabling force TLS to redirect HTTP requests to Fastly, updating purge settings, enabling basic authentication to password-protect your site during development, and setting up GeoIP support.
[Fastly]({{ site.baseurl }}/cloud/cdn/cloud-fastly.html) is required for {{site.data.var.ece}}, and is used in Staging and Production environments. It works with Varnish to provide fast caching capabilities and a [Content Delivery Network](https://glossary.magento.com/content-delivery-network) (CDN) for static assets. Fastly also provides a Web Application Firewall (WAF) to secure your site and Cloud infrastructure. You must route all incoming site traffic through Fastly to protect your site and Cloud infrastructure from malicious traffic and attacks.
Fastly image optimization (Fastly IO) provides real-time image manipulation and optimization to speed up image delivery and simplify maintenance of image source sets for responsive web applications. Once configured Fastly IO provides the following image optimization features:
You can use a Fastly Edge ACL list in combination with a custom VCL code snippet to filter incoming requests and allow access by IP address. The ACL list specifies the IP addresses to allow.
The following example shows how to configure [Fastly Edge Dictionary](https://docs.fastly.com/guides/edge-dictionaries/working-with-dictionaries-using-the-api) with a custom VCL snippet to block referral spam from your {{ site.data.var.ece }} site.
You can use the Fastly CDN module for Magento 2 to create an Edge ACL with a list of IP addresses that you want to block. Then, you can use that list in combination with a VCL snippet to block incoming requests. The code checks the IP address of the incoming request. If it matches an IP address included in the ACL list, Fastly blocks the request from accessing your site and returns a `403 Forbidden error`. All other client IPs are allowed access.
You can create a custom VCL snippet to bypass the Fastly cache so you can troubleshoot request traffic to the origin server, for example to determine whether site issues are caused by caching, or to troubleshoot headers.
The following procedure describes how to reroute incoming requests from a {{ site.data.var.ee }} store to a separate WordPress site using the Fastly edge module _Other CMS/backend integration_ with an Edge dictionary. You can follow a similar process to reroute requests to other CMS backends.
Powered by Fastly, the web application firewall (WAF) service for {{ site.data.var.ece }} detects, logs, and blocks malicious request traffic before it can damage your sites or network. The WAF service is available on production environments only.
0 commit comments