workarea 3.4.16 → 3.4.17

data/docs/source/articles/domain-modeling.html.md

@@ -1,82 +0,0 @@
----
-title: Domain Modeling
-excerpt: Here are a few key concepts related to domain modeling and how they are applied within the platform.
----
-
-# Domain Modeling
-
-Here are a few key concepts related to domain modeling and how they are applied within the platform.
-
-**Note:** It's important to keep in mind these are guidelines, and are not followed completely or religiously. Instead, think of them as heuristics when reading the code or extending elements of the platform.
-
-## Bounded Contexts
-
-With large domains (ecommerce is certainly one of these), it becomes difficult to track the intricacies of how models relate to one another. Therefore, Workarea separates these models into different contexts as a way to break down the bigger picture into more manageable pieces. Each context addresses a single problem or set of problems within the larger system. This technique reduces coupling along domain lines and allows functionality to change independently.
-
-To see this in Workarea, look at how the `app/models` directory in Workarea Core is divided. Each subdirectory is a bounded context, such as the following:
-
-- `Catalog`
-- `Content`
-- `Fulfillment`
-- `Inventory`
-- `Navigation`
-- `Order`
-- `Payment`
-- `Pricing`
-- `Recommendation`
-- `Shipping`
-- `Tax`
-- `User`
-
-### Orders Example
-
-From a customer's perspective, an "order" might contain the following elements:
-
-- Products
-- Prices
-- Shipping method
-- Credit card
-
-By handling these problems separately, the code/modeling/logic for each is much simpler and less coupled. For instance, logic around what shipping methods are available has no coupling to putting together the pricing for the order, even though shipping methods will always have and depend on a price.
-
-However, to present the order to the customer, Workarea pulls:
-
-- Some products from the `Catalog::Product` class
-- Pricing for the order items from the `Pricing` engine
-- Available shipping methods from the `Shipping::Method` class
-- A credit card from the `Payment`
-
-This is the responsibility of the view model layer (and one of the reasons it exists).
-
-### Pricing Example
-
-In another example, pricing from a business user's perspective probably includes several elements:
-
-- SKU price
-- Discounts
-- Shipping costs
-- Taxes
-
-This can get quite complicated, so it is effective to break the problem apart:
-
-- SKU price - stored and calculated in the `Pricing` engine
-- Discounts - stored and calculated in the `Pricing` engine
-- Shipping costs - stored and calculated by the `Shipping` module and totalled by the `Pricing` engine
-- Taxes - rates are stored calculated by the `Tax` module, but applied by the `Pricing` engine
-
-This design makes it much easier to swap out how shipping or taxes are determined. These can be significant problems in their own right, and many implementations use third parties for these purposes.
-
-## Shared Models
-
-There are some things that the contexts share. Changing these classes may/will require cooperation from a potentially broad range of classes, so it's a risky move.
-
-Examples of classes that are shared include:
-
-- `Address` - generically models an address
-- `PriceAdjustment` - represents an adjustment to price, used for tracking/calculating prices
-- `Region` and `Country` - models countries and subdivisions of countries
-- `ShippingOption` - models a shipping method selectable or selected by a user
-
-So `PriceAdjustment` is used by the `Pricing` engine to create the pricing on the `Order`, `Shipping::Shipment`, etc.
-
-

data/docs/source/articles/error-pages.html.md.erb

@@ -1,95 +0,0 @@
----
-title: Error Pages
-excerpt: Workarea Storefront provides an errors controller through which it routes all 404 and 500 errors, and an errors view, which it conditionally renders for HTML responses in place of the static 404 and 500 error pages provided by Rails.[1] Storefront err
----
-
-# Error Pages
-
-Workarea Storefront provides an errors controller through which it routes all 404 and 500 errors, and an errors view, which it conditionally renders for HTML responses in place of the static 404 and 500 error pages provided by Rails.<sup><a href="#notes" id="note-1-context">[1]</a></sup> Storefront error pages provide several advantages over the Rails defaults.
-
-- Each error page renders with administrable system content, specific to the error type (404 or 500)
-- The error pages use the Storefront layout, providing a consistent look and feel, as well as global functionality such as search and navigation
-- The errors view is a standard Workarea view, which you can [override](overriding.html) to extend as necessary
-
-For these reasons, **Workarea 3.3 changes error page rendering to _always_ use Workarea error pages instead of the Rails defaults**.
-
-## Use Workarea Error Pages
-
-To use the Storefront errors view with administrable content in place of the default Rails error pages, ensure [system contents](content.html#system-content) with the following names exist within each environment:
-
-- `'Not Found'` for 404 pages
-- `'Internal Server Error'` for 500 pages
-
-(Since Workarea 3.3, the errors controller creates these contents on demand, so it isn't necessary to create them in advance. However, you should create them if the retailer would like to customize the content for these pages.)
-
-The default customer service pages [seeds](seeds.html) create these system contents within development environments. For all other environments, create these contents through any Ruby interface to which you have access (e.g.&nbsp;Rails console/runner/task). Refer to the example in Listing 1.
-
-<!-- <figure id="listing-1">
-  <figcaption>
-    <p>Listing 1: Excerpt from <i>workarea-core-3.2.4/app/seeds/workarea/customer_service_pages_seeds.rb</i></p>
-  </figcaption> -->
-
-Listing 1: Excerpt from _workarea-core-3.2.4/app/seeds/workarea/customer\_service\_pages\_seeds.rb_
-
-```ruby
-module Workarea
-  class CustomerServicePagesSeeds
-    def perform
-      puts 'Adding auxiliary pages...'
-
-      <var># …</var>
-
-      internal_error_page = Content.for('Internal Server Error')
-      internal_error_page.save!
-
-      not_found_content = Content.for('Not Found')
-      not_found_content.blocks.build(
-        type: :html,
-        data: {
-          html: '<p>Try searching or <a href="/">start at the home page</a>.</p>'
-        }
-      )
-      not_found_content.save!
-    end
-  end
-end
-```
-<!-- </figure> -->
-
-Next, edit the content for these pages within each environment and view the results.
-
-<figure id="figure-1">
-  <figcaption>
-    <p>Figure 1: Administration of the 404 system content</p>
-  </figcaption>
-  <p><%= image_tag "images/404-system-content-admin.png", alt: "The admin for 404 system content" %></p>
-</figure><figure id="figure-2">
-  <figcaption>
-    <p>Figure 2: A Storefront 404 error page in a development environment</p>
-  </figcaption>
-  <p><%= image_tag "images/404-storefront-error-page.png", alt: "A 404 page in the Storefront" %></p>
-</figure>
-
-## View Production Error Pages in Development
-
-By default, Rails responds to an error in development with a debugging page. To view production error pages in development, you must change this behavior. Modify your application’s development configuration as shown in the following patch:
-
-```
---- config/environments/development.rb.old	2018-03-20 15:37:21.000000000 -0400
-+++ config/environments/development.rb	2018-03-20 15:37:04.000000000 -0400
-@@ -14,7 +14,7 @@
-   config.eager_load = false
-
-   # Show full error reports.
-- config.consider_all_requests_local = true
-+ config.consider_all_requests_local = false
-
-   # Enable/disable caching. By default caching is disabled.
-   if Rails.root.join('tmp/caching-dev.txt').exist?
-```
-
-After changing your configuration, restart the application.
-
-## Notes
-
-[1] Specifically, the paths `'/404'` and `'/500'` (regardless of HTTP method) are routed to the `not_found` and `internal` actions of the `Storefront::ErrorsController`, each of which conditionally renders the _workarea/storefront/errors/show.html.haml_ view.

data/docs/source/articles/extension-overview.html.md

@@ -1,152 +0,0 @@
----
-title: Extension
-excerpt: Extension is the process of adding, modifying, or even removing Workarea platform functionality from within a Workarea application or plugin. Workarea plugins extend the platform in ways that are re-usable across applications, while individual applica
----
-
-# Extension
-
-<dfn>Extension</dfn> is the process of adding, modifying, or even removing Workarea platform functionality from within a Workarea application or plugin. Workarea plugins extend the platform in ways that are re-usable across applications, while individual applications extend the platform further to meet the specific needs of a retailer or other stakeholders. While administration allows for platform customization through a UI, extension allows for deeper customization via code changes.
-
-The code changes performed for extension may conflict with the platform's own code changes between versions. When upgrading to a new version of Workarea, application and plugin developers must resolve these conflicts. Developers must therefore consider the long term cost of extension. Another concern is the initial implementation cost of an extension.
-
-This document provides an overview of extension techniques for easier comparison, while other guides describe various techniques in greater detail.
-
-## Augmentation
-
-One form of extension is simple <dfn>augmentation</dfn>—adding new code within the Workarea namespace. For example, your application may require a calendar of events. Such a feature is entirely new and does not overlap with any existing platform functionality. However, to provide consistent user and developer experiences, it makes sense to add your new code (such as models, views, and controllers) within the Workarea namespace. It also makes sense to leverage Workarea patterns, such as the use of additional object types (e.g. view models, workers), and to follow Workarea conventions (e.g. file naming and structuring).
-
-## Domain-Specific Extension
-
-Workarea provides various _designed_ points of extension that employ conventions, inheritance, DSLs, and other techniques to reduce cost during the initial implementation, and potentially at upgrade time. These techniques are domain-specific, so within this documentation, I cover each where that particular domain aspect is covered. Examples of these extension points are listed below.&nbsp;<sup><a href="#notes" id="note-1-context">[1]</a></sup>
-
-- Catalog customizations
-- [Content block types](add-a-content-block-type.html)
-- [Discount types](create-a-custom-discount.html)
-- Inventory policies
-- [Payment gateways](integrate-a-payment-gateway.html)
-- [Pricing calculators](customize-pricing.html)
-- Product templates
-- Seeds
-- Shipping carriers
-- Storefront search middlewares
-
-## Generic Extension
-
-Workarea also provides generic extension techniques that apply across domain boundaries and allow for extensions beyond those specifically designed into the platform.
-
-### Configuration
-
-[Configuration](configuration.html) allows developers to customize specific programmatic values in Ruby and JavaScript.
-
-#### Summary
-
-- Allows applications and plugins to customize configuration values defined by the core platform and plugins
-- Allows plugins to define their own configuration values to be customized by applications and other plugins
-- Applications and plugins write configuration code within their own Ruby and JavaScript configuration files
-- Configuration can affect any aspect of the platform, from the number of products to show in a content block to the list of calculators used to calculate pricing
-
-#### Limitations
-
-- Configuration is limited to specific values defined as configurable by the core platform and plugins
-- Most configuration values are simple values (often integers) or collections/lists of those values
-
-#### Test Considerations
-
-- The scope/reach of a configuration tends to be limited, however, configuration may break tests or create the need for new tests
-- After configuring your app or plugin, write new tests or decorate existing tests as necessary
-
-#### Upgrade Considerations
-
-- When Workarea makes configuration changes between versions, those changes are generally applied seamlessly to your application or plugin when you upgrade your Workarea version
-- However, if Workarea has changed any config values that you have replaced with your own, you will need to apply those changes manually if necessary
-- When customizing config values that represent collections, mutate the collection (prepend, append, delete member, etc) rather than replacing it to ensure Workarea's changes to the collection are applied when upgrading
-- For example, if adding a product template, append your custom value to the existing list of templates instead of replacing the entire list
-
-### Decoration
-
-[Decoration](decoration.html) allows developers to customize Ruby classes.
-
-#### Summary
-
-- Allows applications and plugins to customize Ruby classes defined by the core platform and plugins
-- Within these customizations, developers may add new instance and class methods, modify existing instance and class methods (with access to the pre-customized implementation via `super`), and execute class macros or other code as if inside the original class definition
-- Decoration allows for extensive customization of Ruby code, going far beyond the extension points designed into the platform
-- Because test cases are Ruby classes, decoration also allows for customization of the test suite
-
-#### Limitations
-
-- Decoration allows for the customization of Ruby classes only—modules are not supported at this time
-- Decoration cannot be used to customize code written using other language or file types (such as JavaScript and other UI code)
-
-#### Test Considerations
-
-- Decoration is likely to break existing tests or create the need for additional tests
-- When using decoration to customize functionality, write new tests or decorate existing tests as necessary
-
-#### Upgrade Considerations
-
-- When Workarea changes Ruby code between versions, those changes are generally applied seamlessly to your application or plugin when you upgrade your Workarea version
-- However, if Workarea has changed methods you have replaced with your own implementations, you will need to apply those changes manually if necessary
-- When decorating classes, change only the aspects of the class necessary for your requirements, and use `super` to maintain original method implementations where possible
-
-### Appending
-
-[Appending](appending.html) allows developers to inject their own views and assets into existing user interfaces.
-
-#### Summary
-
-- Allows plugins and applications to render their own (new) partials within existing platform views at designated positions
-- Allows plugins and applications to include their own (new) assets within existing platform asset manifests
-- Plugins and apps create their own partials and assets, and assign these to platform append points within an initializer or other configuration file
-
-#### Limitations
-
-- This technique is limited in scope/reach as it allows only for the injection of new UI code
-- Appending generally provides little control over position and display
-- New code may be injected into only the designated append points provided by the platform
-- There are no formal APIs to remove files from append points or re-order files within append points
-- Without also leveraging overriding, you cannot change the position of an append point within a view
-
-#### Test Considerations
-
-- Appending is likely to break existing tests or create the need for additional tests
-- When appending files, write new tests or decorate existing tests as necessary
-
-#### Upgrade Considerations
-
-- Appending is a simple way of introducing new code into the platform and therefore has few upgrade concerns
-- Unlike other extension techniques, appending is not used to customize existing code; it therefore avoids many of the concerns affecting other extension techniques
-
-### Overriding
-
-[Overriding](overriding.html) allows developers to replace user interface files such as views and assets with their own customized copies of the files.
-
-#### Summary
-
-- Allows applications (and in rare cases, plugins) to completely replace existing platform views and assets
-- Applications copy the views and assets into their own source and customize the files as needed
-- Overriding allows developers to completely replace all HTML and assets served by the application, allowing UI customization that goes far beyond any specifically designed extension points
-
-#### Limitations
-
-- Overriding affects only views, layouts, partials, and files served by the asset pipeline (UI customization)
-- Except in rare cases, plugins should not use overrides (see [Overriding](overriding.html) for more on this)
-
-#### Test Considerations
-
-- Overriding is likely to break existing tests or create the need for additional tests
-- When overriding, write new tests or decorate existing tests as necessary
-
-#### Upgrade Considerations
-
-- Overriding completely replaces platform files with your own copies
-- When Workarea changes views and assets between versions, these changes will not appear in your application if you are overriding the affected files
-- You must apply these changes manually to your own copies of the files
-- While overriding is necessary for UI customization, try to override only the files necessary for your requirements
-- Where possible, use appending instead of overriding to reduce upgrade cost
-
-## Notes
-
-[1] Much of the domain-specific documentation is still forthcoming. I will continue to cross reference these extension points as coverage is added.
-
-

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

@@ -1,112 +0,0 @@
----
-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

@@ -1,25 +0,0 @@
----
-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

@@ -1,20 +0,0 @@
----
-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

@@ -1,34 +0,0 @@
----
-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

@@ -1,46 +0,0 @@
----
-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

@@ -1,43 +0,0 @@
----
-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

@@ -1,35 +0,0 @@
----
-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 |
-
-