Home / Home Page / Magento notes / Magento 2 scope and products

Magento 2 scope and products


Overview

Notes on some topics relating to Products and scope.

Applies to Magento 2.1.2.

Background

Some background details. What I think I understand :-)

Scope: Global - Site - Store - Store view

One way that a Magento installation organizes what users see is via the four nested container levels:

Container
Possible use
Global

Web sites
Business entity
Stores
Directed at particular audience interest
Store views
Separate by languages

Configuration: specific to a scope

Throughout Magento's configuration (not just speaking of products) there is configuration data associated with each of the container levels. In some cases, configuration settings can be set at a higher level (say global), and overridden ("customized") at a lower, more specific, level. Thus arises the idea that such settings have a particular "scope" of effect.

When presenting the value of such settings in the Admin UI, Magento needs to know which scope level's value to display, or to apply edits to. For this purpose, many configuration pages display a scope control: A dropdown hierarchical list of scopes at which you can set settings.

In principle, this scope control could be set to:

  • Global (All Store Views)  (At least, I think that's what All Store Views means.)
  • A particular Web site
  • A particular Store
  • A particular Store View

However, on most configuration pages, only some of these levels are offered. (Why? See also "Enigmatic scope choices" section below.)

In addition, next to the individual settings on the page, is a scope indicator, showing the lowest ("most custom") level at which that setting can be set. (See critique of this scheme below).

Among the settings that can apply at different scope levels are Products' attribute values, as described next.

Product attribute scope

Products have attributes (such as size or color). Various characteristics of each attribute (such as variable type, allowed values) are determined by an attribute specification (Stores > Attribute > Product ...). One characteristic is a setting which determines the lowest level of scope at which it can be set. This attribute scope setting can be set to:

  • global
  • website
  • store view.

As such, when presenting the Product configuration page and showing attributes and their values, Magento needs to know which scope level to display, and to set if you edit the value.

Oddly, the settings on the scope control don't align with the scope alternatives of product attributes. And therein lies some conceptual confusion discussed on this page.

Products' associations with Stores

When products are created, they belong to a Global-level pool of all products. However their "Product on Websites" attribute (settable in the Product configuration) limits them to availability on particular websites only. (Other settings, notably Categories, also need to be set appropriately to allow the products to actually appear on a particular Store.)

Though the limitation of products to particular stores is an idea superficially like "scoping the product to particular stores", it is separate from the scope idea as discussed further on this page. (But see note below on the value of "Product on Websites" that Magento pre-sets on the New Product page.)

Product attribute scope vs the scope control

Some confusing incongruities.

The puzzle pieces:

  • A product attributes be can set to have a lowest scope configuration level of
    • global
    • website
    • (NOT store!)
    • store view

Configuring an attribute's scope level lower than global implies that this attribute's value can be set at any level down to this lowest level. However, that seems not to be true exactly, based on the Product configuration page UI, which seems to constrain the settings to either global or the specified lower level. If an attribute's lowest level is "store view", then there's no way to set a website-level setting.

  • Somewhat incongruent with the attribute scope settings, the Product config page's scope control only offers these scopes:
    • All Store Views (global?)
    • Particular store view

So:

1. Why can't Product attributes lowest scope level be set to Store?

2. Even accepting that there are just three Product attribute scope level alternatives, we see that the there are only two Product scope control settings, and these don't match the three attribute scope alternatives.

Here's what I think happens on the Product configuration page, with different combinations of scope control setting, and attribute's lowest scope level.

Scope control:
All Store Views (global?)
Particular Store View
Product attribute (lowest) scope
(shown beside attribute slot)
UDV Not shown
UDV Checked
UDV Unchecked
[global]
shows and edits
global value
UDV not shown.
Shows global value
Edits global value
shows and edits global value
[website]
shows and edits
global value
shows website value,
can't edit
shows and edits website value
[store view]
shows and edits
global value
shows inherited [1] value,
can't edit
shows and edits store view value

Notes

UDV: Use Default Value. (I'm assuming this means "Use value set on enclosing container level", and not "use the attribute's default value as specified in the attribute's settings".)

[1] You might think that, where the attribute configuration permits setting a value at store view level, the inherited value could come from a value set at website level or global level. However, there seems no way to enter a value at website level. (If the attribute permits setting a value at store view level, then you can't use store view scope to set the value at website level.) If that surmise is correct, the inherited value would be the global value.

Incongruities

  • For an attribute with [website] lowest scope level, to actually edit the website-level setting you have to set scope control to a corresponding Store View.
  • For an attribute that has [store view] lowest scope level, it seems there's no way to edit a website-level value. (Note [1])
    • And implies that, between attribute scope settings and the Product page scope control, the attribute values can only be set at one or two levels. Not three or four as the scope hierarchy per se might initially suggest.) This seems arbitrary. Maybe there's a rationale, but it seems like it could just as easily be an unplanned side-effect of UI obtuseness.

Other scope-related enigmas

  • Stores > Configuration leads to a lengthy configuration page, ostensibly configuring Stores. However, on this page, the scope control can be set to "Default Config" (global?), particular Website, and particular Site View. So any level except a particular Store. Why?

Scope indicator critique

On various configuration pages, including Product config pages, next to each setting (attribute) there's a scope indicator. (Example: [website]).

But does the current implementation of this idea successfully convey the information the user needs?

At each attribute, your brain needs to know several things:

  • At what scope levels can this attribute be set?
  • At what scope level(s) is the attribute currently set?
  • Which level of setting is currently displayed?
  • At what scope level will it get set if I enter a value now?

Which of these do the attribute slots and their scope indicators convey?  I am fairly certain the scope indicators consistently display the first of this list: the lowest scope level at which this attribute can be set. But what data is actually showing at any one time? You may be able to figure it out using complicated reasoning factoring in the setting of the top-left Scope control, and whether or not a "Use Default Value" checkbox appears.  (The earlier section Product attribute scope vs scope control tries to tabulate all combinations.)

Perhaps needless to say, the understandability issues around the per-attribute scope indicator intersect with the issues of the non-congruent scope control choices versus attribute lowest-scope settings.


     



     RSS of this page

    Author: Graham Wideman   Version: 2.2   Last Edited By: Graham Wideman   Modified: 29 Nov 2016