workarea 3.4.12

data/docs/source/articles/favicon-support.html.md

@@ -0,0 +1,112 @@
+---
+title: Favicon Support
+excerpt: Learn how Workarea manages favicons and how they are output in your application
+---
+
+# Favicon Support
+
+Favicons are a collection of images used by browsers and mobile devices to visually represent a site within their user interfaces. Due to the variation between browsers and mobile devices, favicons are typically supplied in a variety of sizes and via a number of delivery methods.
+
+Suffice it to say that long passed are the days of simply dropping a `favicon.ico` file in your site's root directory.
+
+The good news is that Workarea provides a way to set and automate the creation and linking of these assets without developer intervention through the Admin.
+
+## Setting an asset as a favicon
+
+Within the Admin, a user may use an Asset's <em>tags</em> field to denote that the Asset should be used as a favicon.
+
+<!-- TODO v3.4 mention the visual indicator -->
+
+For a single Asset to be used as the site's favicon the Admin user may simply add the `favicon` tag to the chosen Asset. Once this is done, the platform will create, output, and link all necessary files automatically.
+
+For more granular control over each generated favicon, an Admin user may apply tags to the chosen Asset in the following format: `favicon-SIZE`. For example, if the chosen Asset does not scale well and is visually unintelligible when scaled down to 16 pixels (the smallest required favicon size), the user may choose another, smaller Asset to replace this size by applying the `favicon-16x16` tag to the Asset.
+
+The majority of the generated favicons will be of type `.png`, though a fallback `favicon.ico` file is still generated for canonical posterity and for use with older browsers. To manually override this icon, a user may simply denote an Asset as the `.ico` fallback by applying the `favicon-ico` tag to the Asset. Since tagging supports multiple, comma-delimited values, an Asset can carry more than one favicon tag at a time.
+
+<!-- TODO v3.4 mention the favicon placeholder fallback -->
+
+It should be noted that favicons are intended to be square images.
+
+## Favicon asset and manifest automation
+
+The markup necessary for rendering the generated favicons is added to each Storefront layout via methods found within `Workarea::Storefront::FaviconsHelper`. This helper renders the `workarea/storefront/favicons/tags` partial, where the following is generated:
+
+<!-- TODO v3.4 remove web manifest? -->
+
+* A link to a 180x180 pixel Apple Touch icon
+* A link to a 32x32 pixel .png icon
+* A link to a 16x16 pixel .ico icon
+* A link to a web manifest file 
+* A meta tag providing the URL to a browserconfig file 
+* A meta tag to specify the tile color for use in the Microsoft Windows Metro UI
+* A meta tag to specify the color of the browser's "theme", a feature available on some devices
+
+The color-specific settings are output as the aforementioned meta tags in addition to appearing as entries within the web manifest and browserconfig files. These settings are configurable via:
+
+```ruby
+Workarea.config.web_manifest.tile_color
+Workarea.config.web_manifest.theme_color
+```
+
+URLs for each linked icon are provided by the following `FaviconsHelper` methods:
+
+* `Workarea::Storefront::FaviconsHelper#favicons_path` generates a URL to a dynamically sized `.png` file
+* `Workarea::Storefront::FaviconsHelper#favicon_path` generates a URL to the `favicon.ico` file
+
+Each favicon is dynamically generated on demand using Dragonfly. The following custom dragonfly processors defined within `core/config/initializers/07_dragonfly.rb`:
+
+* `:favicon` handles the resizing of a file to the passed size.
+* `:favicon_ico` handles the conversion to the `.ico` format.
+
+<!-- TODO v3.4 remove below --> 
+Lastly, if there is no Asset tagged as a favicon, the system will not generate any of the above. 
+
+## Favicon URLs
+
+Storefront routes are provided to handle requests for an icon of a particular size and the `favicon.ico` file itself. These routes are:
+
+* `dynamic_favicon` which takes no parameters, returning the `favicon.ico` and serving the file from `https://domain.com/favicon.ico`
+* `dynamic_favicons` which takes a size parameter, returns a `.png` version and serving the file from, for example, `https://domain.com/favicons/32x32.png` if the requested size parameter is set to `32x32`.
+
+Both of these routes are Dragonfly endpoints which handle the favicon rendering within `Workarea::AssetEndpoints::Favicons`. This class has two methods to match the provided routes:
+
+* `result` handles the dynamic_favicons request, restricting sizes to those defined within `Workarea.config.favicon_allowed_sizes`, preventing DDOS attacks that may try to request many varying sizes at once.
+* `ico` handles the generation of the `favicon.ico` file by finding the appropriate Asset and running it through the `:favicon_ico` Dragonfly processor.
+
+## The Web Manifest
+ 
+<!-- TODO v3.4 explain repurposing for PWA apps -->
+
+The rendered favicon tags in the layout link each page to a web manifest.
+
+A web manifest is a file that can inform devices how to style particular elements of the client UI when accessing the site. In addition to favicon settings, it provides further configuration for theme coloring and other basic meta information for the site. Further information can be found on the following sites:
+
+* [https://developer.mozilla.org/en-US/docs/Web/Manifest](https://developer.mozilla.org/en-US/docs/Web/Manifest)
+* [https://developers.google.com/web/fundamentals/web-app-manifest/](https://developers.google.com/web/fundamentals/web-app-manifest/)
+
+The Workarea platform automatically generates this file from `Storefront::PagesController#web_manifest` via a route which serves the file from `https://domain.com/site.webmanifest`. The file itself is in JSON format and lives at `storefront/pages/web_manifest.json.jbuilder` in the views directory and will be cached by Rack cache.
+
+This template contains a mix of favicon images and configuration values to provide a basic web manifest which can be expanded upon to suit your client's needs. Out of the box it provides:
+
+* **name** using `Workarea.config.site_name`
+* **short_name** also using `Workarea.config.site_name`
+* **icons** containing
+  * a 192x192 `.png` icon
+  * a 512x512 `.png` icon
+* **theme_color** using `Workarea.config.web_manifest.theme_color`
+* **background_color** using `Workarea.config.web_manifest.background_color`
+* **start_url** using `'/?utm_source=homescreen'`
+* **display** using `Workarea.config.web_manifest.display_mode`
+
+## Browserconfig
+ 
+The rendered favicon tags in the layout also link each page to a browserconfig file.
+
+A browserconfig file informs Microsoft Windows devices on how they should present and style their UI elements when accessing the site. This file is similar to the web manifest in many regards. The main difference is that this file is in XML format.
+
+Like the web manifest, the Workarea platform automatically generates this file from `Storefront::PagesController#browser_config` via a route which serves the file from `https://domain.com/browserconfig.xml`. The file itself is in XML format and lives at `storefront/pages/browser_config.xml.builder` in the views directory and will be cached by Rack cache.
+
+Also like the web manifest, this template contains a mix of favicon iamges and configuration values which can further be expanded upon to suit your client's needs. By default it offers:
+
+* **square150x150logo** which is dynamically generated 
+* **TileColor** defined by `Workarea.config.web_manifest.tile_color`, for use in the Windows Metro UI

data/docs/source/articles/feature-spec-helper-stylesheet.html.md

@@ -0,0 +1,25 @@
+---
+title: Feature Test Helper Stylesheet
+excerpt: 'In a test environment, the application stylesheet manifest includes the following style rules:'
+---
+
+# Feature Test Helper Stylesheet
+
+In a test environment, the application stylesheet manifest includes the following style rules:
+
+```
+/**
+ * "Disable" transitions and animations in the test environment
+ */
+
+* {
+    transition: none !important;
+    animation: none !important;
+}
+```
+
+These rules effectively disable CSS transitions and animations in the test environment.
+
+Workarea applies these styles to allow for more reliable full stack automated tests. If you are not running any of Workarea's tests, you may remove this code if you prefer.
+
+

data/docs/source/articles/featurejs-and-feature-spec-helper.html.md

@@ -0,0 +1,20 @@
+---
+title: Feature.js & Feature Test Helper
+excerpt: Feature.js provides browser feature detection for developers. It is loaded in its entirety in the Storefront's head manifest. Out of the box it provides JavaScript methods and root HTML element classes that represent which features are available to th
+---
+
+# Feature.js & Feature Test Helper
+
+## Feature.js
+
+[Feature.js](http://featurejs.com) provides browser feature detection for developers. It is loaded in its entirety in the Storefront's head manifest. Out of the box it provides JavaScript methods and root HTML element classes that represent which features are available to the developer to program against.
+
+## Feature Test Helper
+
+After Feature.js does all that hard work to set up the features above, Workarea's feature test helper file works equally hard (at least I like to think so) to undo a portion of it. However, it only does this if the Rails environment is `test`.
+
+Some styles, particularly CSS animations and transitions, interfere with full stack testing and make it difficult to write reliable tests. Workarea therefore applies additional styles in the test environment to effectively disable all animations and transitions.
+
+However, Feature.js is not aware of this and still reports those features as supported. The feature test helper updates the class values on the html element to report animations and transitions as not supported overwrites the corresponding properties on the `Feature.js` object to do the same.
+
+

data/docs/source/articles/help-and-support.html.md

@@ -0,0 +1,34 @@
+---
+title: Help & Support
+excerpt: In addition to these guides, Workarea provides the following resources for help and support.
+---
+
+# Help & Support
+
+In addition to these guides, Workarea provides the following resources for help and support.
+
+## Slack
+
+Workarea has a public Slack, where we hang out, mostly during EST business hours. [Signup and chat with us!](https://workarea-community.slack.com)
+
+Use Slack to:
+
+- Read and post announcements about new Workarea releases, plugins, and documentation (from the core team and the community)
+- Report bugs or inquire if certain behavior is a bug
+- Ask the community about or share known solutions to problems to reduce implementation time
+- Ask the community how to use a feature or how it's expected to work
+- Ask the community about what to learn or how to learn, or suggest resource to others to learn more about Workarea and its dependencies
+
+## Workarea Support
+
+The Workarea Support team provides support and training services to merchants and partners. Visit [https://support.workarea.com] (https://support.workarea.com) to open an issue or contact us for support.
+
+### Submit an Incident Report
+Go to [https://support.workarea.com] (https://support.workarea.com) and submit an [Incident Report] (https://jira.tools.weblinc.com/servicedesk/customer/portal/16/create/248) detailing the observed issue. Provide as much detail as possible (screen shots, error codes, steps to reproduce, etc.) to reduce the need to further diagnose and resolve more quickly.
+
+Please include your Solution Partner primary contact on all incidents and requests, so communication can be facilitated as needed.
+
+Alternatively, email [support@workarea.com] (mailto:support@workarea.com) and include your priority in the subject of the email.
+
+### After Hours Escalation
+To escalate the issue after Hours of Support, call __[+1 (215) 398-7814] (tel:+1-215-398-7814)__ and leave a message for on-call support and request a call back.

data/docs/source/articles/html-fragment-caching.html.md

@@ -0,0 +1,46 @@
+---
+title: HTML Fragment Caching
+excerpt: After HTTP caching The next level of caching happens in the Rails views. The Workarea system does this fragment caching in the conventional Rails way, so if you've worked with caching on Rails systems before this will be familar to you.
+---
+
+# HTML Fragment Caching
+
+After [HTTP caching](http-caching.html) The next level of caching happens in the Rails views. The Workarea system does this fragment caching in the conventional Rails way, so if you've worked with caching on Rails systems before this will be familiar to you.
+
+storefront/app/views/workarea/storefront/categories/show.html.haml:
+
+```
+- cache "#{@category.cache_key}/head", expires_in: Workarea.config.cache_expirations.categories_fragment_cache do
+  = append_partial('admin.category_head', category: @category)
+
+  - if @category.first_page?
+    %link{ href: category_url(@category), rel: 'canonical' }
+  - unless @category.last_page?
+    %link{ href: url_for(page: @category.next_page, only_path: false), rel: 'next' }
+  - unless @category.first_page?
+    %link{ href: url_for(page: @category.prev_page, only_path: false), rel: 'prev' }
+  - unless @category.meta_keywords.blank?
+    %meta{ name: :keywords, content: @category.meta_keywords }
+  - unless @category.meta_description.blank?
+    %meta{ name: :description, content: @category.meta_description }
+
+  %meta{ property: 'og:url', content: url_for(only_path: false) }
+  %meta{ property: 'og:title', content: page_title }
+  %meta{ property: 'og:type', content: 'website' }
+  %meta{ property: 'og:image', content: image_path('workarea/storefront/logo.png') }
+  %meta{ property: 'og:image:secure_url', content: image_path('workarea/storefront/logo.png') }
+```
+
+In the Rails views, a chunk of HTML is wrapped in a `cache` block. When that `cache` block is hit, Rails fetches the key from the cache store and returns the value. If the key doesn't exist or is expired, the code in the `cache` block will be run, and the result is saved in the cache store. Examples of fragment caches include:
+
+- Primary navigation menus
+- Secondary navigation menus
+- Product summaries (shown on browse pages and recommendations)
+- Browse results
+
+When defining any fragment caches, keep in mind cache expiration. The simplest way to handle this is to use the updated\_at timestamp of the correlating model to ensure this cache will be expired when the model is updated.
+
+## Resources on Fragment Caching
+
+- [Rails Guide: Fragment Caching](http://guides.rubyonrails.org/caching_with_rails.html#fragment-caching)
+- [Heroku: Fragment Caching](https://devcenter.heroku.com/articles/caching-strategies#fragment-caching)

data/docs/source/articles/http-caching.html.md

@@ -0,0 +1,43 @@
+---
+title: HTTP Caching
+excerpt: All major content, browse, and search pages are cached for a short and configurable duration by an HTTP cache. This allows the system to serve a large number of requests in a short period of time.
+---
+
+# HTTP Caching
+
+All major content, browse, and search pages are cached for a short and configurable duration by an HTTP cache. This allows the system to serve a large number of requests in a short period of time.
+
+storefront/app/controllers/workarea/storefront/pages\_controller.rb:
+
+```
+module Workarea
+  class Storefront::PagesController < Storefront::ApplicationController
+    before_filter :cache_page
+    # ...
+  end
+end
+```
+
+Controller/actions which enable this include:
+
+- `Workarea::Storefront::CategoriesController#show`
+- `Workarea::Storefront::PagesController#show`
+- `Workarea::Storefront::PagesController#home_page`
+- `Workarea::Storefront::ProductsController#show`
+- `Workarea::Storefront::SearchesController#show`
+
+This creates a major complication for any data on the page with user or session specific. Examples include login status, cart count, and personalized product recommendations. Workarea solves this problem by loading this content asynchronously via Javascript. Make sure you review any customized functionality to ensure you won't be caching pages with session-specific data.
+
+**Note:** [Rack::Cache](http://rtomayko.github.io/rack-cache/) is a simple way to achieve the caching advantage explained above without the configuration and hosting burden of a more robust HTTP cache like [Varnish](https://www.varnish-cache.org).
+
+## Customizing the Rack::Cache Key
+
+There are scenarios where it becomes necessary to vary `Rack::Cache` entries, like geolocated content blocks or segmentation-based navigation. In these cases, Workarea provides a relatively straight-forward way to add to the cache key. Refer to [the documentation in the code for Workarea::Cache::Varies](https://github.com/workarea-commerce/workarea/blob/master/core/lib/workarea/cache.rb) for more information.
+
+**Note:** Using `Workarea::Cache::Varies` can have a _very_ adverse affect on application performance, and is not encouraged. Make sure this is what you need, and feel free to reach out on [Slack](https://workarea-community.slack.com) to see if there may be a better way to achieve your goals.
+
+## Resources on HTTP Caching
+
+- [W3 Spec](http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html)
+- [Web Fundamentals: HTTP caching](https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=en)
+- [HTTP Caching in Ruby with Rails](https://devcenter.heroku.com/articles/http-caching-ruby-rails)

data/docs/source/articles/i18n.html.md

@@ -0,0 +1,35 @@
+---
+title: I18n
+excerpt: Internationalization/localization features in Workarea allow for translation/customization of static content (including message content and JavaScript content) and translation of administrable content.
+---
+
+# I18n
+
+Internationalization/localization features in Workarea allow for [translation/customization of static content](translate-or-customize-static-content.html) (including [message content](translate-or-customize-message-content.html) and [JavaScript content](translate-javascript-content.html)) and [translation of administrable content](translate-administrable-content.html).
+
+**Note:** Internationalization/localization in Workarea relies heavily on [Rails I18n](http://guides.rubyonrails.org/i18n.html) and [Mongoid Localization](https://docs.mongodb.org/ecosystem/tutorial/ruby-mongoid-tutorial/#localized-fields). The preceding links provide excellent explanations of those features, so they are recommended reading.
+
+## Customizing Text
+
+Rails I18n features are useful even if your app has only a single locale. Use I18n to customize static text strings, such as [the content of success, failure, and warning messages](translate-or-customize-message-content.html).
+
+## Translating Text
+
+Of course, your app may also use multiple locales to provide [static content translations](translate-or-customize-static-content.html) and [translation of administrable content](translate-administrable-content.html).
+
+To use multiple locales, start by [configuring locales](configure-locales.html).
+
+## Determining the Current Locale
+
+Workarea determines the current locale by looking for a locale prefix in the request URL.
+
+Given an app with en (default), es, and de locales, the following table demonstrates how each URL maps to a locale.
+
+| URL | Locale |
+| --- | --- |
+| http://example.com/categories/sale | en (default) |
+| http://example.com/en/categories/sale | en |
+| http://example.com/es/categories/sale | es |
+| http://example.com/de/categories/sale | de |
+
+

data/docs/source/articles/images-flow.html.md

@@ -0,0 +1,10 @@
+---
+title: Images Flow
+excerpt: A diagram to illustrate how images (product images, content assets) flow into the system and how they are modified and presented to end users.
+---
+
+# Images Flow
+
+The following diagram illustrates how images (product images, content assets) flow into the system and how they are modified and presented to end users.
+
+![Images Diagram](images/images.svg "View Larger")

data/docs/source/articles/index-storefront-search-documents.html.md

@@ -0,0 +1,104 @@
+---
+title: Index Storefront Search Documents
+excerpt: This document provides procedures developers can use to manually index Storefront search documents.
+---
+
+Index Storefront Search Documents
+================================================================================
+
+This document provides procedures developers can use to manually index Storefront search documents.
+
+These procedures are for _manually_ indexing search documents. However, most search indexing is _automatic_, as explained in [Search, Indexing](searching.html#indexing_7).
+See also [Storefront Search Features, Indexing](storefront-search-features.html#indexing_12) for an overview of Storefront search document creation and indexing.
+
+
+Index All Storefront Search Documents
+--------------------------------------------------------------------------------
+
+Workarea's `search.rake` Rakefile provides a task for (re)indexing all Storefront search documents.
+
+Index all Storefront search documents from a shell session within the environment:
+
+```bash
+$ bin/rails workarea:search_index:storefront
+```
+
+Index all Storefront search documents within Ruby:
+
+```ruby
+Rake::Task['workarea:search_index:storefront'].invoke
+```
+
+The procedures above index documents _inline_ (i.e. in the foreground).
+Alternatively, set the environment variable `INLINE` to `false` before executing the task to perform the indexing with Sidekiq workers (i.e. in the background):
+
+```bash
+$ INLINE=false bin/rails workarea:search_index:all
+```
+
+
+Index Specific Storefront Search Documents
+--------------------------------------------------------------------------------
+
+In some cases, you may need to index only specific Storefront search documents.
+The procedure for this varies for product and non-product search documents.
+
+
+### Non-Product Documents
+
+For non-product search documents (e.g. categories, pages, searches), initialize a Storefront search model and call `#save` to index the resulting search document.
+
+```ruby
+catalog_category = Workarea::Catalog::Category.first
+Search::Storefront::Category.new(catalog_category).save
+```
+
+See [Storefront Search Features, Search Models](storefront-search-features.html#search-models_13) for an explanation of Storefront search models.
+
+
+### Product Documents
+
+For product search documents, don't use a search model directly.
+Use any of the following API calls, which create the search model instances for you.
+(See [Workers](workers.html) for more details regarding the `perform` and `perform_async` methods.)
+
+* `Workarea::IndexProduct.perform(product)`
+* `Workarea::IndexProduct#perform(id)`
+* `Workarea::IndexProduct#perform_async(id)`
+* `Workarea::BulkIndexProducts.perform_by_models(products)`
+* `Workarea::BulkIndexProducts.perform(ids)`
+* `Workarea::BulkIndexProducts#perform(ids)`
+* `Workarea::BulkIndexProducts#perform_async(ids)`
+
+For example, index one product:
+
+```ruby
+catalog_product = Workarea::Catalog::Product.first
+Workarea::IndexProduct.perform(catalog_product)
+```
+
+Or, enqueue a background job to index 5 products in bulk (using only a single request to Elasticsearch):
+
+```ruby
+catalog_product_ids = Workarea::Catalog::Product.all.pluck('id').first(5)
+# => ["71C098FFD9", "9A7160EBF0", "2702316B04", "06C6FC0827", "0FA514641B"]
+Workarea::BulkIndexProducts.new.perform_async(catalog_product_ids)
+```
+
+Each of the API calls above provides two additional functions, which is why these calls are used instead of creating search models directly.
+
+First, calling any of the above methods sets `:last_indexed_at` on each of the affected models in MongoDB.
+Among other things, this timestamp is used by workers responsible for keeping indexes fresh.
+
+Second, for each product passed in, these methods create a collection of _product entries_ to represent the document within the Storefront search indexes.
+The product entries collection (an instance of `Search::ProductEntries` is a collection of search models, each of which produce a search document to be indexed.
+
+This allows more or fewer search documents to be indexed for each product.
+For example, with [Workarea Browse Option](https://github.com/workarea-commerce/workarea-browse-option) installed, a single MongoDB document may be represented by multiple search documents in each search index (e.g. one for each color of the product).
+In contrast, with [Workarea Package Products](https://github.com/workarea-commerce/workarea-package-products) installed, the child products of a package are not indexed at all (they produce an empty product entries collection).
+
+The product entries abstraction also allows a different search model to be used conditionally.
+For example, Workarea Browse Option extends product entries to use a different search model for those products that "browse by option".
+This search model uses only variants of the given option (e.g. blue) to construct the search model.
+Similarly, Workarea Package Products uses a different search model for "package" products.
+This search model includes details from the package's "child" products, which themselves are not indexed.

data/docs/source/articles/infrastructure.html.md

@@ -0,0 +1,46 @@
+---
+title: Infrastructure
+excerpt: An overview of the required pieces of infrastructure for hosting Workarea.
+---
+
+# Infrastructure
+
+This will be a brief overview of what you'll need to host a Workarea app on your own. Workarea is a hefty application which can be complex to run efficiently, so we recommend our [Workarea Commerce Cloud hosting](https://www.workarea.com/pages/commerce-cloud) for merchants who want to focus on their unique business problems.
+
+## Application
+
+### Web
+
+Workarea ships with a [default Puma configuration](https://github.com/workarea-commerce/workarea/blob/master/core/lib/workarea/configuration/puma.rb) out-of-the-box, which is the application server we recommend. Workarea is known to work with [Passenger](https://www.phusionpassenger.com), and will probably work with most any application server that supports Rails.
+
+### Sidekiq
+
+Workarea depends on [Sidekiq](https://sidekiq.org) for performing background work, so you'll need to have a Sidekiq daemon running along with the application server. Workarea will automatically configure Sidekiq based on its own configuration.
+
+## Databases
+
+### MongoDB
+
+Workarea uses on [MongoDB](https://www.mongodb.com), so you'll need a production-grade replica set. Currently, the latest version of Workarea supports MongoDB v4.0.x.
+
+### Elasticsearch
+
+Workarea uses [Elasticsearch](https://www.elastic.co/products/elasticsearch) for large portions of functionality. You'll want a production-grade cluster running version v5.6.x.
+
+### Redis
+
+Workarea uses [Redis](https://redis.io) for the Sidekiq queue, cache, Rack::Attack, and more. Note that while only one instance of Redis is _required_, we recommend running two. The first would be for persistent data like the Sidekiq queue or recommendations. The second is for ephemeral data like cache.
+
+## Miscellaneous
+
+### Assets
+
+Currently, Workarea depends on [Amazon's S3](https://aws.amazon.com/s3/) to back its asset storage. You'll need at least one bucket setup to run Workarea. An optional second (called the "integration" bucket in the code) can be configured for integrating with other systems, like flat-file exports, image imports, etc.
+
+### Geolocation
+
+Workarea provides a number of geography-based features. For these features to function, you have two options. The first (very slow) way is to configure the [Geocoder gem](https://github.com/alexreisner/geocoder) that Workarea uses to look up request location by IP address. The second, preferred way is to integrate an upstream proxy like [nginx](http://nginx.org) to lookup geography data based on IP address and add headers, which the Workarea application will read. See [the ngx_http_geoip_module](http://nginx.org/en/docs/http/ngx_http_geoip_module.html) for an example.
+
+### Compliance
+
+This is just dropping you a note that the Workarea application is written to be compliant with PCI-DSS requirements. Workarea Commerce Cloud hosting provides a complete top-to-bottom certified, tier 1, PCI-DSS environment. This is recommended for all merchants.