Rename to Workarea
Workarea 3 renames the WebLinc software and its components to Workarea. The rename encompasses the core software and all plugins, including file and directory names, code constants, repository names, and gem names.
Workarea 3 requires PhantomJS version 2.x. You must update this dependency in all test environments. Workarea 2.3.0 allowed use of PhantomJS 2.x, but this version is now a hard requirement in Workarea version 3.
Workarea v3 removes the following features.
- Product sharing
- Browsing by option (for example, a separate search result for each color of a product)
- Content search results
- Developer toolbar
- Product quickview
The features above have been extracted to the plugins below. These plugins are maintained by the WebLinc Product Team.
- Workarea Share
- Workarea Browse Option
- Workarea Content Search
- Workarea Developer Toolbar
- WebLinc Product Quickview
First introduced in WebLinc 2.3, Minitest is the standard test framework in Workarea 3.0. Using Minitest allows applications to run Workarea platform tests without copying them into the application, and it allows applications to decorate tests like other Ruby classes.
Workarea version 3 provides the following commands to run tests within an application.
bin/rails workarea:test:coreto run tests from workarea-core (with decorators)
bin/rails workarea:test:adminto run tests from workarea-admin (with decorators)
bin/rails workarea:test:storefrontto run tests from workarea-storefront (with decorators)
bin/rails workarea:testto run tests from workarea-core, workarea-admin, and workarea-storefront (with decorators)
bin/rails workarea:test:decoratedto run decorated tests only
Workarea 3 moves all feature and request tests from RSpec to Minitest (and renames them system and integration tests, respectively) and also moves a variety of other tests from RSpec to Minitest. Other tests remain in RSpec, however, these tests will be moved to Minitest in future minor releases.
Workarea 3 moves all RSpec dependencies into a separate Workarea RSpec engine. This engine will provide continued support for RSpec testing during and after the migration of platform tests from RSpec to Minitest.
Existing applications are not expected to migrate existing specs to Minitest. RSpec testing will continue to be supported indefinitely. However, new applications should write Minitest tests exclusively, in order to benefit from test decoration.
Refer to Testing Concepts for further coverage of testing in Workarea 3.
Workers, Listeners & Publishers
Workarea version 3 removes WebLinc's system of listeners and publishers and adds Sidekiq extensions that provide the concept of a callbacks worker in addition to other changes to the workers APIs.
The Workers guide explains the version 3 workers APIs.
Workarea 3 makes a variety of changes to search, including those in the following list. The Search guide explains the version 3 search APIs in greater detail.
Elasticsearch::Persistencelibrary is removed in favor of using the Elasticsearch Ruby API directly
Weblinc::Search::Mapperare removed in favor of lighter abstractions
Elasticsearch::Indexprovide abstractions that more closely mimic the ODM abstractions used for MongoDB
Workarea::Search::Querymodule and the construction of Elasticsearch searches has been redesigned to leverage developers' knowledge of Ruby modules and code re-use
- The list of indexes used is changed to reduce the number of Elasticsearch queries and to provide greater flexibility (for example, a single index is used to search for searches, products, categories, and pages in the storefront)
- Elasticsearch mappings are stored as configuration in
- Personalized search is removed, and all search results pages are cached by URL
- Learning search is simplified and leverages data stored for analytics
Workarea v3 makes a variety of changes to shipping. Specifically, shipping rates are requested from an ActiveShipping carrier, and Workarea provides a default carrier that mimics the previous shipping implementation. This change allows for easier extension of shipping functionality.
The Shipping guide explains the version 3 shipping APIs in more detail.
Workarea version 3 splits navigation into two separate concerns: taxonomy and navigation. Taxons, which compose the site's taxonomy, are used to organize Navigables and other nodes into a tree structure. This structure provides the hierarchy needed for secondary navigation such as breadcrumbs.
The Navigation guide explains the APIs concerning taxonomy and navigation.
Workarea version 3 iterates on CMS functionality, primarily to allow faster creation of custom content block types. Block types are stored in memory and are created using a DSL. Developers no longer need to implement the admin UI for each block type. A block type is composed of fields, which are organized into fieldsets. A field defines the type of UI control that should be used to collect data, the default value of the field, and how the collected data should be typecast.
The Content guide explains the content APIs in more detail.
Sample Data (Seeds)
Workarea 3 renames
Workarea::Seeds and removes the
weblinc:sample_data Rake task in favor of Rails' own
db:seed task. New Workarea 3 applications implement
db:seed as follows:
# your_app/db/seeds.rb require 'workarea/seeds' Workarea::Seeds.run
Applications migrating to version 3 may want to copy this implementation.
Seed files live in the Rails
app directory and are therefore required automatically and may be decorated like other Ruby classes. Furthermore, Workarea 3 stores the list of seeds to be run in the
Workarea.config.seeds configuration to allow for easier extension.
CSS Grid System
Workarea version 3 redesigns the Admin UI, providing improved performance, discoverability, and extensibility. Some of the specific changes are summarized in the following list.
- Search is displayed more prominently and allows for searching by type of object (for example, searching for "products" allows direct navigation to the products index screen)
- A sitemap-like primary navigation organizes the Admin into sections, each with their own dashboard and subsections
- Hierarchical navigation is designed around the main heading of the page, with the link above the main heading going a level "up" the taxonomy, and links below the main heading going "down" a level deeper
- Auxiliary navigation that sometimes appears in the top right navigates between pages that are related but in a different parts of the taxonomy, such as returning to a product from its related inventory
- Redesigned index pages use a grid layout and allow selecting multiple products for bulk actions, such as edit and delete
- Objects such as products and categories now have show pages that present an overview of everything that can be managed for that object, as well as decomposing the administration of that object into smaller, more manageable pieces
- On show pages, cards bring forward comments and other features that were hidden behind context menus in previous versions
- The timeline for an object combines its history and upcoming changes into a single chronological view
- The current release is stored in session so that it "follows" the user through the Admin, while controls on most screens allow editing the current release before editing and before saving
- Creation workflows provide step-by-step interfaces to create and publish objects such as products, categories, and discounts that require more than a simple form to create a functioning whole (for example, products need variants that need prices)
- The content editing UI is redesigned, providing more context while editing, as well as improved previewing
- More useful data is present on dashboards, and insights are also available for categories, products, people, and search to help retailers make decisions
The admin toolbar that displays for administrators when browsing the Storefront is updated to match the Admin, providing the full Admin search and navigation directly within the Storefront. Administrators can navigate easily between Admin and Storefront views of the same object.
In addition to being redesigned, the Admin UI has been internationalized, allowing for translation into different and multiple locales. The Storefront and Admin UIs are now both internationalized.